5-й номер журнала «Практика функционального программирования»

> к специально для них созданному
ну ну

ты, похоже, снова начал бредить с умным видом

либо рассказывай подробно свою задачу и обоснованно клади аннотации на лопатки, либо прекрати бред

бред, это с умным искать заковырки в концепциях которых не понимаеш и языке который не знаеш

по задаче сам стори drools если интересно, а потом задавай осмысленные вопросы, а то будет потом - я потерял интерес к задаче

> Какую это существующую? Конечно, она существует, раз MOP есть. Что бы MOP был возможен нужна инфраструктура, которая сама по себе и не нужна.

type-of/class-of - для интроспекции, а без них нельзя и без MOP-а

Разве я такое говорил?

Ну, я подумал и выбрал технологию.

корпоративный гуи - delphi
корпоративный web - CL

тогда это твоя позиция ?

> а с наследованием нужно пробежаться по dispatch_table от самого специфичного класса до первого найденного предка — ах как сложно!

чего мелочится, можно сразу CL интерпритатор на плюсах забахать, только зачем ?

public private protected на доступ к членам и методам

public private protected как виды наследования

невозможность положить в массив или вектор то, что не реализует нужные нам методы, и невозможность после этого в рантайме поменять класс объекта так, что методы исчезнут

все это можно сделать, даже отдельной библиотекой, только ее еще никто не написал (по крайней мере я не видел) - значит это никому не нужно, концепции совсем другие и уж точно не хуже чем в C++

> type-of/class-of - для интроспекции, а без них нельзя и без MOP-а

Это и весь MOP? А RTTI и в С++ есть.

корпоративный гуи - delphi

корпоративный web - CL

тогда это твоя позиция ?

Хм, нет. Моя позиция в том, что надо думать и решать.

в С++ тоже можно реализовать мультиметоды и с помощью макросов и шаблонов сделать простой и удобной синтаксис, но только этого никто не написал - значит это никому не нужно; так можно обосновать ненужность чего угодно :)

> отлично - значит приватные/константные данные нужны, а в лиспе есть механизм для их «создания»?

есть, медитируй над MOP

изменения нужны ес-но

ну слава LOR-у

ну слава LOR-у

я разве это отрицал? о_О

есть, медитируй над MOP

тогда покажи аналог:

struct A
{
public: int mA;
protected: int mB;
}

struct B : public A {}
struct C : protected A ()
struct D : private A ()

> все это можно сделать, даже отдельной библиотекой, только ее еще никто не написал (по крайней мере я не видел) - значит это никому не нужно

вывод «значит» не обоснован, у это могут быть другие причины, например

1. такого рода библиотека придет в противоречие с динамической природой CLOS — из-за возможностью менять класс объекта в рантайме библиотека ничего не сможет гарантировать, в отличие от компилятора с++

2. такого рода библиотека потребует статической аннотации остальных библиотек; их и так в лиспе мало, и никто тратить время на аннотирование не будет

(defclass a ()
  ((ma :type fixnum)
   (mb :type fixnum :visability :protected))
  (:metaclass enclosed-class))

(defclass b (a) ()
  (:metaclass enclosed-class))

(defclass c (a) ()
  (:metaclass enclosed-class)
  (:class-visability :protected a))

; а теперь подсластим defmacro

(define-enclosed-class d (:private a) ())

а теперь покажи пожалуйста пример использования удобных мультиметодов на шаблонах

> Это и весь MOP? А RTTI и в С++ есть.
это все что нужно от рунтайм объета для интроспекции, остальной MOP в компилтайм

Хм, нет. Моя позиция в том, что надо думать и решать.

а разве ее кто то оспаривал ? просто разные люди по разному решают.

> 1. такого рода библиотека придет в противоречие с динамической природой CLOS — из-за возможностью менять класс объекта в рантайме библиотека ничего не сможет гарантировать, в отличие от компилятора с++

я могу это запретить когда надо

2. такого рода библиотека потребует статической аннотации остальных библиотек; их и так в лиспе мало, и никто тратить время на аннотирование не будет

она ничего не потребует

> а теперь покажи пожалуйста пример использования удобных мультиметодов на шаблонах

Александреску - Современное проектироваие на С++, 11-я глава, а также ес-но Loki

> (:class-visability :protected a)

class-vis_a_bility

не, ты мне дай полный пример, который скомилится допустим в sbcl

> Александреску - Современное проектироваие на С++, 11-я глава, а также ес-но Loki

этим детям рано читать александреску, они со своей дин. типизацией не поймут вообще о чем он там пишет — им надо предлагать только варианты типа dispatch_table[arg1(f)][arg2(f)]=f

>этим детям рано читать александреску, они со своей дин. типизацией не поймут вообще о чем он там пишет — им надо предлагать только варианты типа dispatch_table[arg1(f)][arg2(f)]=f

какой же жуткий батхёрт. защищённое наследование вообще не нужно.

> Александреску - Современное проектироваие на С++, 11-я глава, а также ес-но Loki

они неудобные и более того это не совсем полноценное решение,
удобно сделано тут http://www.op59.net/cmm/cmm-0.28/users.html или тут http://parasol.tamu.edu/people/peterp/omm/, но это реализации далеко не в виде библиотеки, слабо к Loki такой же синтаксис прикрутить без вспомогательных средств ?

> не, ты мне дай полный пример, который скомилится допустим в sbcl
твое мнение не стоит того чтоб набросать десяток килобайт кода, извини
хотя если вы решите задачу постом выше, я набросаю

> этим детям рано читать александреску, они со своей дин. типизацией не поймут вообще о чем он там пишет — им надо предлагать только варианты типа dispatch_table[arg1(f)][arg2(f)]=f

а почему тогда ты «детский» lisp осилить не в состоянии ?

ps
тебе в голову не приходила мысль что лисперы как правило знают далеко не только лисп.

!о пропустил

в коде анонимуса суть была в строках, неалгоритмически зависящих от типа боя, потому и он был длинный, и его переписывание на шаблоны тоже

я же не код анонимуса породировал а твой, а там вполне зависит

а твой сокращенный вариант пишется на плюсах тоже без проблем, как в виде шаблонов, так и динамически

пишется что-то, но сокращенным я бы это не стал называть

> твое мнение не стоит того чтоб набросать десяток килобайт кода, извини хотя если вы решите задачу постом выше, я набросаю

вот так честно надо было с самого начала и сказать: повторение функционала из 5 строчек на с++ требуют набрасывания десятка килобайт кода на лиспе

> я же не код анонимуса породировал а твой, а там вполне зависит

анонимус поставил задачу, я ее решал;

то, что ты смотрел только на мой код, а не на его — это твои проблемы, и да, мне пофиг, что ты там пОродировал

>функционала из 5 строчек на с++

с каких плюсы умеют функции как объекты первого класса?

>> функционала из 5 строчек на с++

с каких плюсы умеют функции как объекты первого класса?

я имел в виду «функциональности из 5 строчек на с++»

что же касается функций как объектов первого класса в с++, то там это почти достигнуто; хороший вопрос для обсуждения — все ли там достигнуто, что может быть достигнуто без потери эффективности

то есть можно ли без потери эффективность реализовать например вызов каррированной функции по указателю так же как и обычных функций, при условии, что доп. аргументы положены на стэк или куда-то; аналогичный вопрос с замыканиями

точнее

можно ли без потери эффективности не различать между собой указатели на обычную например 1-аргументную функцию и указатели на 2-аргументную функцию, для которой один аргумент уже хитро положен на стек или куда-то

> повторение функционала из 5 строчек на с++ требуют набрасывания десятка килобайт кода на лиспе
качни например исходники g++ и удивись скоко кода в компеляторе обеспечивают поддержку public/protected/private для приведенных целых _8_ строк, по сути мне нужно набросать тоже самое, так что десяток килобайт это отличная цифра

> то, что ты смотрел только на мой код, а не на его — это твои проблемы

ну будет так
(scissors paper :-> scissors «Scissors, Paper: Scissors wins.»)
не смертельно правдо ?

пОродировал и пр.

так веселей, или предратся к чему нибудь ну очень хочется ?)

> можно ли без потери эффективности не различать между собой указатели на обычную например 1-аргументную функцию и указатели на 2-аргументную функцию, для которой один аргумент уже хитро положен на стек или куда-то

ты создаш куда больше проблем чем пытаешся решить :)

> так веселей, или предратся к чему нибудь ну очень хочется ?)

просто ну очень безграмотно ты пишешь, а неспособность осилить русский в рамках школьной программы о многом говорит.

> просто ну очень безграмотно ты пишешь, а неспособность осилить русский в рамках школьной программы о многом говорит.

местная писанина не о чем не говорит, а уже типичный переход на личности и постинг из под анонимуса говорят гораздо больше

> местная писанина не о чем не говорит, а уже типичный переход на личности и постинг из под анонимуса говорят гораздо больше

Я всю жизнь пишу из-под анонимуса. Кроме того, тут не ad hominem аргументов - только комментарий о твоей безграмотности, ничего больше.

> Я всю жизнь пишу из-под анонимуса.

это как минимум не удобно для собеседников, а как максимум позволяет не отвечать за слова

Кроме того, тут не ad hominem аргументов - только комментарий о твоей безграмотности, ничего больше.

ничего больше было бы, если твой комментарий ограничился фразой до запятой, а так ad personam в чистом виде
а без второй части твой пост лишен какой-либо смысловой нагрузки в рамках обсуждения

ps
я конечно отношусь весьма наплевательски как я пишу, особенно тут, однако ничего что количество моих описок/ошибок таки зависит от стиля моего ответа и адекватности аргументов собеседника ...

> ну будет так (scissors paper :-> scissors «Scissors, Paper: Scissors wins.»)

уже лучше; теперь можно ответить по сути

в плюсах, если у нас большая простыня из таких штук, это будет либо с макросами препроцессора

FACT( Scissors, Paper, Scissors, «Scissors, Paper: Scissors wins.»);

либо без макросов препроцессора более многословно, но не теряя статической проверки — и я это писать не буду, т.к. мое мнение — плюсам нужна ресинтаксификация с небольшим расширением семантики, в т.ч. под такие вот случаи

на самом деле где на плюсы можно (и нужно) наехать — это то, что частичный переход со статической типизации на динамическую (а это иногда полезно) вызывает слишком большие *текстуальные* изменения; вообще лисперы пока не представили достаточно грамотной критики плюсов хотя бы и с точки зрения динамической типизации

и не только со статической типизации на динамическую, но даже допустим в рамках перехода (рефакторинга) с виртуальных функций на какой-то ad hoc полиморфизм количество переписывания на десятичный порядок превосходит реальную разницу между программами (или их концепциями)

(лисп тут может служить некоторым источником идей, но никак не примером для подражания)

> вообще лисперы пока не представили достаточно грамотной критики плюсов хотя бы и с точки зрения динамической типизации

за исключением предложенной archimag-ом мысли «временное нарушение корректности программы для проверки идеи»

> в плюсах, если у нас большая простыня из таких штук, это будет либо с макросами препроцессора

FACT( Scissors, Paper, Scissors, «Scissors, Paper: Scissors wins.»);

препроцессор спасет только в травиальных случаях как этот

по плюсам: сколько бы не обсасывали их проблемы, лучше не станет

> вообще лисперы пока не представили достаточно грамотной критики плюсов хотя бы и с точки зрения динамической типизации

а зачем их критиковать ? сравнивать C++ с лиспом в контексте языков высокого уровня даже смысла нет, как навороченный ассемблер с классами он побыстрее SBCL, еще не стоить забывать о постоянном сужении ниши плюсов как бы не просто так

> по плюсам: сколько бы не обсасывали их проблемы, лучше не станет

Скажем так: у С++ нет проблем, которые бы не являлись продолжением его достоинств. Но так всегда, ибо серебряной пули нет.

Статической проверки типов, которая нравится www_linux_org_ru в C++, не то, что не возможна в Common Lisp, но труднореализуемая (ибо противоречит природе языка) и никто не будет заниматься этим реально на практике.

Грэхэм в своё время расположил CL на вершине пирамиды языков по мощности языковых средств и видимо с тех пор стало популярное мнение, что в CL возможно всё. Т.е. поскольку он на вершине, то он либо включает в себя все возможности других языков, либо их легко реализовать. Честно говоря, это совершенно не так. При этом, Common Lisp не является носителем передовых идей CS, при чем, так было с момента его создания (а не явилось результатом 20-летней стагнации).

Наиболее фундаментальные отличие Common Lisp от большинства других языков заключаются в модели разработки, в ощущениях разработчика при его использовании.

> сравнивать C++ с лиспом в контексте языков

высокого уровня даже смысла нет

Если говорить только об языковых средствах, то есть.

как навороченный ассемблер с классами

Не путай, С++ это не «С с классами».

не стоить забывать о постоянном сужении ниши плюсов

как бы не просто так

Хм, если бы она сужалась за счёт увеличения доли CL-приложений, то в этом аргументы возможно был бы смысл. А так выглядит не очень ;)
Да и сужении ниши плюсов, скажем так, не совсем очевидно.

> Скажем так: у С++ нет проблем, которые бы не являлись продолжением его достоинств. Но так всегда, ибо серебряной пули нет.

его достоинства выходят из моды, так же как когда-то ассемблеры и С++0x вряд ли это исправит

...

статический eDSL делается не сложно, а обсуждать твое субъективное виденье лиспа еще раз - нет желания, извини

> Если говорить только об языковых средствах, то есть.
а ничего что, как минимум, в одном месте они фиксированные, а в другом программируемые ?

Не путай, С++ это не «С с классами».

оба ассемблера, только один с некоторым элементами маскировки этого факта

Хм, если бы она сужалась за счёт увеличения доли CL-приложений, то в этом аргументы возможно был бы смысл. А так выглядит не очень ;)

проблемы плюсов и лисп не связанны

Да и сужении ниши плюсов, скажем так, не совсем очевидно.

начни свой отсчет с джавы

> статический eDSL делается не сложно

Угу, что ж не делают? Или Qi это не сложный вариант?

обсуждать твое субъективное виденье лиспа еще раз

Моё субъективное виденье основано на том, что у меня в /usr/share/common-lisp/sources/ почти 500 000 строк кода разных авторов и только в parenscript (да может в какой-то степени в iterate, и то, сомнительно что это eDSL) имеется в наличии eDSL. Так на чём основано ваше виденье?

его достоинства выходят из моды

Ну да, вот уже и в GCC можно юзать. Я тут недавно смотрел V8 и node.js - что-то у меня обратное впечатление. Применение C++ уменьшается в области бизнес-приложений, но он никогда для этой области и не предназначался, а использовался там сугубо по историческим причинам. А вот насчёт других областей у меня никакого ощущения снижения популярности C++ нет.

> Угу, что ж не делают? Или Qi это не сложный вариант?
это вывод из упомянутых 1.5 eDSL-лей ?) и Qi то причем здесь ?

Так на чём основано ваше виденье?

перетерали уже, мое мнение не изменилось и ваше похоже тоже ...

но он никогда для этой области и не предназначался

и для каких же областей предназначался C++, можно полный список ?

ps
совсем толсто, цель 1000 постов ?) я за

opponent::mWin[ «cat» ][ «mouse» ] = true;

вообще интересно, есть ли что-то в CLOS, что не достичь такого рода подходом (вместо true может стоять анонимная функция)

c помощью :before и :after можно довесить нужную логику, причем это может сделать не только разработчик библиотеки но и прикладник. С помощью :around и call-next-method можно вмешиваться в результаты поединков и бегать по иерархии (в сторону предков). Можно доопределить классы мышь-гигант и |неподготовленый ниньзя| и определять уже для них результаты поединка или перекладывать ответсвенность на методы опеределенные на родительских классах. Причем такая передача ответсвеноности может зависть не только от иерархии классов, но от других важных в тот момент вещей.

Все это называется standart-method-combination, а есть и другии где решение будет зависить от мнения всех челенов данной ветви классовой иерархии или первого отказавшегося. Ну и конечно |моя собственная method-combination|.

Если же двинутся дальше в MOP то можно контролировать изменения класса, например для db-классов можно контролировать соответсвие схеме БД и в случае разногласий запросить помощи у програмиста предоставив возможные варианты решения в виде рестартов. Програмист в свою очередь либо сам разрулит, либо раскрасит и с рюшечками передаст оператору, либо напишет обработчик возможно даже с помощью метода потому как сигнал тоже экземпляр своего класса. На этом круг вращения данных через CLOS замыкается и мы можем начать сначала.

Скромно умолчав про метаклассы на которых определена внутреня механика классов, скажем что мы конечно можем спустится на уровень нижев в мир defun-ов, векторов, струкур и символов (заметьте символов не строк. Почему «cat» с++-примере строка? мы ведь ее по символам не раскладваем и не конкатенируем) но будем делать это когда нам нужно будет это делать.

>public private protected на доступ к членам и методам

public private protected как виды наследования

В лиспе(CL конечно же) за пространство имен и доступность отвечает пакетно-символьная система, а пакет - единица инкапсуляции (замыкания и прочие анонимные вещи опустим они к классам параллельны). Сам по себе класс такими вещами не заведует и определяет их только относительно пакета. Например хотим мы что бы некоторые слоты не светились в пространсво имен, тогда обзываем этот слот #:private-slot536 (обратите внимание #: в начале) - это так называемый внепакетный символ. К слоту с таким именем можно обратится только имея экземпляр этого символа. Хотя это конечно все для параноиков, но принцип должен быть понятен. Обычно же пакет представляет единое пространство имен для нескольких классов и методов и экспортирует наружу то что составлет внешний нитерфейс.

Вопрос прибивания private, protected к слотам класса это уже вопрос личных пожеланий не относящихся к вопросу. В принципе если кому интересно могу набросать и такое но уже не сегодня.

невозможность положить в массив или вектор то, что не реализует нужные нам методы

Ну тут ненавистники могут сказать ага! и попрыгуть, несмотря на clhs, (который почти стандарт) массивы классами не типизируются по крайней мере в sbcl-е. Что вобсчем учитывая назначение массивов и не приципиально. Есть конечно структуры обертывающие векторы но это не совсем решение.

невозможность после этого в рантайме поменять класс объекта так, что методы исчезнут

а методы не исчезнут они определяюся НА классах а не в них, за исключение методов определяемых при инициализации класоов (accessor-ы например).

Про возмомость контроля изменения класса (основываясь в том числе ина его метаклассе) я уже говорил.

>> статический eDSL делается не сложно

Угу, что ж не делают? Или Qi это не сложный вариант?

Оставив на совести ed что он имел ввиду под статическим eDSL, отмечу что во-первых Qi не DSL за отсутсвием своей предметной области, во-вторых, не embed потому как конструкция из лиспа он тоже почти не использует, в-третих он использует лисп только как хост-систему.

> Оставив на совести ed что он имел ввиду под статическим eDSL

я говорил о компилтайм верифицируемом eDSL-е, генерирующем гарантировано type-безопасный код, без рунтайм проверок внутренних данных, при необходимости только внешних

а несложно так как в самом простом варианте мы можем включить в eDSL избыточную (не больше чем например в C++) информацию о типах/видах (или как оно там будет называться в рамках нашей предметной области).

> Ну тут ненавистники могут сказать ага! и попрыгуть
пусть лучше не дергаются :) мы им (cons (make-array ...) 'type) синтаксическим сахаром обмажем в случае чего :)

мы им (cons (make-array ...) 'type) синтаксическим сахаром обмажем в случае чего :)

лисперы часто обмазываются несвежим дерьмом^Wсинтаксическим сахаром и дрочат в присядку

> лисперы часто обмазываются несвежим дерьмом^Wсинтаксическим сахаром и дрочат в присядку

глупый, это наверно с тобой php-ники сделали сказав что это обряд посвящения в лисперы, не играй с ними больше, они врут