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

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

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

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

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

ed (28.05.2010 18:57:48)

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

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

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

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

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

ed (28.05.2010 19:09:06)

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

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


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

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

ed (28.05.2010 19:20:50)

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

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

> корпоративный гуи - delphi
> корпоративный web - CL
> тогда это твоя позиция ?

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

archimag (28.05.2010 19:24:17)

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

lester (28.05.2010 19:25:59)

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

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

> изменения нужны ес-но
ну слава LOR-у

ed (28.05.2010 19:28:17)

> ну слава LOR-у

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

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

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

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

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

lester (28.05.2010 19:31:30)

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

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

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

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

www_linux_org_ru (28.05.2010 19:41:35)

(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) ())

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

ed (28.05.2010 20:09:15)

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

> Хм, нет. Моя позиция в том, что надо думать и решать.
а разве ее кто то оспаривал ? просто разные люди по разному решают.

ed (28.05.2010 20:12:22)

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

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

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

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

ed (28.05.2010 20:14:45)

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

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

lester (28.05.2010 20:20:12)

> (:class-visability :protected a)

> class-vis_a_bility

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

www_linux_org_ru (28.05.2010 20:29:30)

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

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

www_linux_org_ru (28.05.2010 20:31:07)

>этим детям рано читать александреску, они со своей дин. типизацией не поймут вообще о чем он там пишет — им надо предлагать только варианты типа 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 такой же синтаксис прикрутить без вспомогательных средств ?

ed (30.05.2010 14:54:39)

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

ed (30.05.2010 15:04:20)

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

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

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

ed (30.05.2010 15:12:29)

!о пропустил

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

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

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

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

ed (30.05.2010 15:21:57)

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

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

www_linux_org_ru (30.05.2010 22:48:25)

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

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

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

www_linux_org_ru (30.05.2010 22:55:32)

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

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

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

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

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

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

www_linux_org_ru (31.05.2010 0:48:00)

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

www_linux_org_ru (31.05.2010 0:54:55)

точнее

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

www_linux_org_ru (31.05.2010 1:03:57)

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

ed (31.05.2010 2:45:48)

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

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

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

ed (31.05.2010 3:01:40)

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

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

ed (31.05.2010 3:29:19)

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

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

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

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

ed (31.05.2010 13:27:05)

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

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

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

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

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

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

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

ed (31.05.2010 19:44:49)

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

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

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

FACT( Scissors, Paper, Scissors, "Scissors, Paper: Scissors wins.");

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

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

www_linux_org_ru (01.06.2010 8:09:03)

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

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

www_linux_org_ru (01.06.2010 8:21:40)

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

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

www_linux_org_ru (01.06.2010 8:36:37)

> в плюсах, если у нас большая простыня из таких штук, это будет либо с макросами препроцессора
> FACT( Scissors, Paper, Scissors, "Scissors, Paper: Scissors wins.");

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

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

ed (01.06.2010 12:55:27)

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

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

ed (01.06.2010 13:37:53)

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

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

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

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

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

archimag (01.06.2010 13:41:58)

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

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

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

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

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

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

archimag (01.06.2010 13:46:29)

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

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

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

ed (01.06.2010 14:10:43)

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

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

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

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

ed (01.06.2010 14:20:36)

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

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

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

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

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

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

archimag (01.06.2010 14:36:58)

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

> Так на чём основано ваше виденье?
перетерали уже, мое мнение не изменилось и ваше похоже тоже ...

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

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

ed (01.06.2010 17:10:59)

>> opponent::mWin[ "cat" ][ "mouse" ] = true;

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

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

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

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

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

antares0 (02.06.2010 8:27:01)

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

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

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

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

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

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

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

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

antares0 (02.06.2010 9:20:56)

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

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

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

antares0 (02.06.2010 9:36:16)

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

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

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

ed (02.06.2010 11:16:26)

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

ed (02.06.2010 11:56:53)

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

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

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

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

ed (02.06.2010 12:09:21)