Метаязыки

>> Layout.new { |l| add GUI::Tree.new(categories)
> А это по русски что означает ?

Ахахаха. Вот-вот. Как? Ты еще не знаешь? Это HyperPyRyby, новый DSL язык. Для понимания, тебе нужно всего лишь изучить концепции "назад" (подмножество "монад" с обратной семантикой) и торсионно связанных списков. Книги: Автор ХХХХХХ Х.Х., Том 1, Том 2, Том 3. ;-)

Извините за сарказм. Можете меня в отместку пнуть #define'ом. ;-)

> Ладно, про Emacs значит забудем

А вот это зря. Хотя "на вкус и цвет"... ;)

> Ну вот, ты уже на пол пути... Ты до конца "проговори" семантику. А потом будет видно, что и как с этим делать. А то ты сначала хочешь выбрать между тракторными колёсами и танковыми катками, а только потом делать гоночный болид ;)

Да я то уже на этапе реализации почти :) Надо сказать что все было не так просто как кажется. Мне просто интересно как _вы_, как люди новые в этой предметной области, будете проектировать этот язык. Зря проговорился ... :)

Например, если в списке L был выбран объект A то в полях E1,E2,E3 должны отобразится свойства объекта A.p1, A.p2, A.p3. Ну и т.д.

E1.tie(L.selected_object.p1)

Где L - ObjectsList E1 - какой-то объект отображения.

Вообще как имхо нужно делать. Берёшь кучу примеров. Делаешь так как по твоему проще и выразительнее должно выглядеть, перебираешь разные варианта. Когда примеров накопиться достаточно - проектируешь язык.

> Мне просто интересно как _вы_, как люди новые в этой предметной области, будете проектировать этот язык. Зря проговорился ... :)

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

Давайте так. Я снимаю свое ограничение на описание гуя в терминах зависимости визуализируемых данных. Возвращаемся к исходной задачи. Т.е. модель данных (объектная, реляционная - пофигу). Эта модель по сути уже описывает некоторые закономерности предметной области. Задача разработать максимально высокоуровневый язык описания гуя для редактирования и ввода данных в соответствии с этой моделью. Гуй может быть произвольным. Одни элементы управления могут использоваться только для отображения, другие для выбора и редактирования, третьи для удаления данных. Элементы управления должны быть синхронизированы между собой.

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

> Только из-за своей низкоуровневой природы хрен ты на пишешь на C чтонить такое:

Я не знаю что делает " acts_as_tree :order => \"name\"", но я еще не видел ни одной реальной задачи, которую не смогли решить на Си, в том числе без препроцессоров. Если acts_as_tree что-то делает с деревом (любым), то вот на это дело библиотек море.

Что касается Си, то этот форум видел многое: и темплейты на чистом С (с использованием #define + #include + #undef) и подобие лямбды на Си (хотя это и не свойственно Си, и лично я не поддерживаю это).


> Ну и что? А предствь еслиб это еслиб всё что было написано на
> elispе было написано на C.

Это очень просто представить. *term + shell + vim. Строчек небось меньше чем в емаксе + разделение задач хорошее - unix way.

> Вообще как имхо нужно делать. Берёшь кучу примеров. Делаешь так как по твоему проще и выразительнее должно выглядеть, перебираешь разные варианта. Когда примеров накопиться достаточно - проектируешь язык.

Неа, мне так не нравится. Ты в одну кашу загоняешь и контролы, и события (если я ещё хоть что-то соображаю). ИМХО, мухи отдельно, котлеты отдельно. Подозреваю, графически это изобразить маловероятно, ибо контролы имеют "состояния", и события именно меняют эти состояния.

Знаешь, в N-й производной это напоминает SQL: контролы - таблицы, события - триггеры/процедуры :)

Ты сейчас про мой пример наверное? а не про то что цитировал? Там да нужно над чем подумать, события действительно лучше отделить... Просто тоже сейчас уже не сильно соображаю. Пора уже идти праздник отмечать:)

> Знаешь, в N-й производной это напоминает SQL: контролы - таблицы,
> события - триггеры/процедуры :)

Хе-хе. За час с небольшим можно было уже в QtDesigner/Glade накидать нужный интерфейс и забиндить сигналы к функциям. ;-)

*очерчевая круг носком ноги* ...хотя я и противник GUI, но быстрое решение знаю...

> Ты сейчас про мой пример наверное? а не про то что цитировал? Там да нужно над чем подумать, события действительно лучше отделить... Просто тоже сейчас уже не сильно соображаю. Пора уже идти праздник отмечать:)

Ну ты всё правильно понял... Так что не гони на соображалку :)

> Я не знаю что делает " acts_as_tree :order => \"name\"", но я еще не видел ни одной реальной задачи, которую не смогли решить на Си, в том числе без препроцессоров. Если acts_as_tree что-то делает с деревом (любым), то вот на это дело библиотек море.

Оно создаёт объект в этом классе все необходимые методы так чтобы каждая строка таблицы отображалась в объект. Связанный между собой древовидной связью. Причём получаем полный набор методов типа children, parent, root с добавлением удалением и многим другим. всё одной строчкой.

> Это очень просто представить. *term + shell + vim. Строчек небось меньше чем в емаксе + разделение задач хорошее - unix way.

Ну а вся функциональность IDE, навигация там интелекуальная интеграция с рельсовыми генераторами и многое другое ты на С будешь писать, или всётаки шел-скриптами и расширениями к виму на перле(или ещё чём). Имхо 2ое. Для емакса тоже самое тока вместо шел скриптов и расширений на переле - emacs lisp.

ЗЫ: Прочитай пожалуйста Art Of the Unix Programming многое скорее всего переосмыслишь.

> Хе-хе. За час с небольшим можно было уже в QtDesigner/Glade накидать нужный интерфейс и забиндить сигналы к функциям. ;-)

Хе-хе, сколько ты будешь "обучать" QtDesigner/Glade делать то-же самое на основании данных из потока, а не на твоём "мышевозении"? :)

Или ты хочешь сказать, что сейчас нормальные сайты в MS Word-е рисуют? :)

> Знаешь, в N-й производной это напоминает SQL: контролы - таблицы, события - триггеры/процедуры :)

Ну да. Напоминает :) По сути мой вариант для интерфейсов отображения представляет собой один большой оператор параметризованный SELECT разбитый на отдельные блоки. Я их называю фильтры. Фильтры пишутся очень просто. Как правило 1-2 строчки. Параметры этого оператора определяются состояниями отдельных элементов управления в которых можно что-либо выбирать. Изменение состояния отдельного элемента управления инициализирует все зависимые от него фильтры. Что-то типа make-а получается. Только наоборот

C операциями редактирования пока до конца не продумал

Вот ищу уязвимое место в этой идее :)

Кстати идея с SQL-для-гуя не новая по моему. Такая фигня еще в MS Access-е была. Правда реализация там хромала.

> и многое другое ты на С будешь писать, или ...

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

Раскрою мысль:
Есть Задача 1. Чтобы ее решить, ты придумываешь Задачу 2, которая решает Задачу 1. Но! Чтобы придумать Задачу 2, ты еще делаешь Задачу 3, которая помогает Задаче 2. Так вот, сейчас ты мне предложил решить Задачу 3. А я тебе отвечаю: я не хочу даже думать о Задаче 3, которая решает 2, которая решает 1. И думаю: неужели нельзя решить Задачу 1 без помощи "навигации там интелекуальной интеграции с рельсовыми генераторами"???

Меня яж в дрожь бросает. ;-)

> Прочитай пожалуйста Art Of the Unix Programming

Спасибо, моя настольная книга. Рядом томики Кнута. Извиняюсь за оффтопик, но единственное что мне не нравиться -- у меня нету печатных оригиналов. Где можно в Москве достать?

вот: http://www.books.ru/shop/books/251362 или ты имел ввиду английский оригинал?

> или ты имел ввиду английский оригинал?

Именно.

В том числе и Кнута. Вот уж интересно сколько будут стоить оригиналы его творений....

Пожалуйста:

http://www.ozon.ru/context/detail/id/1830453/

http://www.ozon.ru/context/detail/id/2566867/ - тока на заказ...

> http://www.ozon.ru/context/detail/id/1830453/

Все оказалось, как обычно, намного проще.. Спасибо.

> http://www.ozon.ru/context/detail/id/2566867/ - тока на заказ

Не подходит. Я думаю будет в разы дешевле "запрячь" туриста в англоязычную страну. ;-) Тем более все это баловство... но хочется.

Ты говорил, что "на половине пути" (или что-то вроде этого :)

Когда релиз? Лицензия? :)

2logIN (& others too ;))

Возможностью метапроганья в языке хочется решить ряд следующих проблем.
1) Расширения (см мои предыдущие посты). Имхо это важная проблема, и МП - наиболее подходящее средство для ее решения.
2) Совместимость. Если компилятор будет обеспечивать только базовый, минимальный набор средств, и сам язык будет идти в виде модулей, проблема совместимости компиляторов должна просто исчезнуть.
3) Использование наиболее подходящей идеологии для конкретной задачи. Проблема имхо тоже серьезная. Наиболее яркие примеры - использование императивного стиля в хаскелле (в shootout бОльшая часть прог на hs - сплошная императивщина (logIN про это писал, правда не о hs), да и во многих других проектах, чего уж там...), разработка новых языков для совмещения парадигм (Curry, Mercury, OCaml, .....), причем это создает другие проблемы - нарушает чистоту языка (фп), нарушает принцип "всё есть объект" (ооп), может создать путаницу, тк для решения одной задачи разные люди могут применить различные парадигмы, и т.д.
Хочется же, чтобы подключив модуль FP мы получили бы чистые функциональные средства, OOP и прочие модули - соответственно.

Конечно, препятствовать беспределу нужно, поэтому метапрограмминг неплохо бы запретить использовать везде кроме определения модулей (библиотеки != модули, хотя они могут их включать), императивную часть сделать как можно ближе к SPARK'у, ООП - из Self'а (хотя хочется объединить передачу сообщений в понимании smalltalk/self и в понимании erlang, если это возможно ;))...

На счет Си... Даже для простого грамотно сделанного проекта требуется очень высокая культура программирования от всех участников + строго оговоренные правила + хорошее понимание идеологии. Иначе о совместимости, повторном использовании кода и расширяемости можно просто забыть. И не вспоминать (не буду говорить про баги) =) Ибо есть большой печальный опыт, но счастливый с другими ЯП =) Так вот, всеже надо, чтобы правила проверял сам язык, идеология один раз выбиралась для одной задачи и не менялась и т.д.
И все-таки пару слов о багах ;) Есть ряд задач, в которых они недопустимы, в принципе - бортовое ПО (а оно сейчас у американских истрибителей занимает многие миллионы строк), банковские системы и т.п. Да и ненадо думать как ms, что обычным пользователям можно и потерпеть ;) Часто слышу здесь, что для решения проблемы достаточно просто не делать багоф =)) Однако и человек, со стажем хотьбы пешком в 50 лет может спотыкнуться на ровном месте, а если в проекте участвуют 100 человек, и не у всех такой опыт... Человеческий фактор еще никто не отменял. Тем кто думает что язык здесь не при чем - курить Erlang и SPARK/Ada ;)

Если где чего напутал - поправьте плиз ;)

>покажи мне настоящий, 1-в-1 (у проектов должна быть идентичная функциональность), проект на Си и на DSL

для 1/5 даже и DSL-и не нужны - сравни обьём кода cvs и darcs.

>разработчики GCC переписали парсер С++ в ручную на Си

Им пришлось - потому, что синтаксис C++ не укладывается в .... да он вообще никуда не укладывается AFAIR:-)