Здравствуйте, konsoletyper, Вы писали:
K>Здравствуйте, Gaperton, Вы писали:
G>>валяйте, давайте сюда пример, и я покажу, как его сделать без макросов и паттернов. Мне хватит паттерн-матчинга, атомов, и первоклассных функций.
K>Ну, можно чего попроще. Лексер написать. Кстати, сначала ты скажи, сколько у тебя это времени заняло, а потом я отвечу и мы сравним.
Я воспользуюсь flex, или любой подобной тулзой. По ним хотя-бы документация есть, и мой код все поймут, а в велисипеде на макросах еще рабираться надо будет стороннему программеру. Недостатка в генераторах лексеров и парсеров нет ни для какого языка. Буквально для любого языка есть выбор.
G>>ага. И каждый ваш новоопределенный макрос — каждый, делает этот язык все более навороченным — причем, без контроля и толковых спецификаций. Что может быть и ускорит разработку, когда вы работаете в одиночку, но приведет к катастрофе, если над проектом работает большая группа. Сразу напишете неподдерживаемый код, который потом в помойку пойдет через пару лет.
K>Введение в язык средств абстракции вроде функций, модулей, объектов так же чревато тем, что кто-то понапишет кривых библиотек (вспомним, как было с C++ и строками). И ничего, вроде как-то пишут вполне поддерживаемый код, не отказываясь от этих абстракций.
Странно, пишешь вроде просто и понятно, но такое впечатление — что люди либо не читают, либо не понимают. Проблема не в наличии абстракций вроде функций, модулей, и объектов. Проблема в том, что твои собственные расширения языка никто не знает, и знать, что характерно, не хочет. А по нормальным языкам есть толковая документация и (даже!) учебники. Которые детально разжевывают для непонятливых предназначение абстракций. Ничего кроме нечленораздельного мата у инженера, который потом за тобой баги будет править, твои расширения в большинстве случаев вызывать не будут — потому что на саппорте надо багу бытро править и уметь быстро разбираться в коде (желательно, нешифрованном макросами коде написанном на всем известном языке).
Ты будешь по учебнику писать к каждой своей программе? А если у вас 20 человек пишут один программный комплекс, и каждый шибко умный — макросы пишет, — что тогда? Каждый будет учебники писать? Почему никто не задумывается о том, как процесс разработки реальных систем в больши командах на языках с макросредствами пойдет, и чем кончится, интересно? Это шибко сложно, представить, какой кавардак начнется? Вы знаете, что менеджер сделает первым делом в таком проекте? Он, если у него чувство самосохранения и остатки здравого смысла есть — первым делом строго ограничит применение макросов — они будут запрещены к применению вне рамок очень компактного ядра системы — фреймворка, если он, тот фреймворк, вообще у вас в задаче будет. Потому что он далеко не всегда вообще нужен. И пишут его редко, и допущены к его правке всего несколько человек.
Re[12]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, Gaperton, Вы писали:
L>>Можно подробнее о выделенном? Почему этого можно добиться только макросами?
G>В выражении a = b + c + d, где переменные — матрицы, надо, чтобы все это свернулось в единственный двойной цикл с этой формулой внутри. На плюсах это делается без макросов — через темплейтное метапрограммирование, и выглядит страшно. На макросах, мне думается, реализация выглядела бы проще. Хотя — честно скажу, пока на макросах реализации не видел. Все только говорят, говорят о великих и ужасных макросах — и все .
Круто. А можно поглядеть на С++ реализацию?
На GHC можно через GHC Rewrite Rules свернуть. Т.е. пишем a + b + c, где a, b, c — матрицы, а оно сворачивается в sum3 a b c. Но это именно для этой задачи: сложение трёх элементов. Для произвольного количества сходу придумать не могу.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[13]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, lomeo, Вы писали:
L>Я не понял, если честно. L>х у нас заранее создан с нужной длиной? L>p, s — это матрица или вектора? alpha и omega — скаляры? L>в чём прикол? почему нельзя просто перемножить и сложить? промежуточные структуры? L>Можно сам макрос подсмотреть?
Здравствуйте, lomeo, Вы писали:
L>Здравствуйте, Gaperton, Вы писали:
L>>>Можно подробнее о выделенном? Почему этого можно добиться только макросами?
G>>В выражении a = b + c + d, где переменные — матрицы, надо, чтобы все это свернулось в единственный двойной цикл с этой формулой внутри. На плюсах это делается без макросов — через темплейтное метапрограммирование, и выглядит страшно. На макросах, мне думается, реализация выглядела бы проще. Хотя — честно скажу, пока на макросах реализации не видел. Все только говорят, говорят о великих и ужасных макросах — и все .
L>Круто. А можно поглядеть на С++ реализацию?
Гуру из нашей С++ конфы говорят, что есть в библиотеке Blitz++, а вообще решение искать надо по словам expression templates. Сразу предупреждаю — это очень злой С++. Но если попривыкнуть — то там, в сущности, все понятно .
Re[13]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, lomeo, Вы писали:
L>Круто. А можно поглядеть на С++ реализацию?
L>На GHC можно через GHC Rewrite Rules свернуть. Т.е. пишем a + b + c, где a, b, c — матрицы, а оно сворачивается в sum3 a b c. Но это именно для этой задачи: сложение трёх элементов. Для произвольного количества сходу придумать не могу.
Здравствуйте, mkizub, Вы писали:
M>Здравствуйте, FR, Вы писали:
G>>>>разумеется не надо. Для того, чтобы паттерны были не нужны, их не надо встраивать в язык. Надо язык выразительный иметь. G>>>>валяйте, давайте сюда пример, и я покажу, как его сделать без макросов и паттернов. Мне хватит паттерн-матчинга, атомов, и первоклассных функций.
M>>>Реализуйте паттерн ОО, плиз.
FR>>Вот на схеме без использования макросов http://okmij.org/ftp/Scheme/pure-oo-system.scm
M>А при чём тут schema? Про существование CLOS я знаю, что это можно сделать на схеме — тоже. M>Речь шла о хаскеле.
С чего это вы взяли, коллега, что речь шла о Хаскеле? Слова "Хаскель" я не произносил. Я сказал — "первоклассные функции, атомы, и сопоставление с образцом". Имея в виду, кстати, Эрланг (в котором объекты, кстати, изначально присутствуют, в точности как в Smalltalk 72 — они делаются процессами). Но в схеме все перечисленное тоже есть.
Re[19]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, lomeo, Вы писали:
L>Я к тому, что в ФП функция рассматривает несколько по другому нежели в "обычных языках". Это первоклассная сущность.
Ага. Я на Nemerle писал, и это ощутил по полной. Ещё и универе мне математику преподают — там всякого навидался.
L>То же самое и со всем остальным. Поняв, что парсер (или, например, конечный автомат) это всего лишь функция, можно получить много полезных результатов в языке, где функция — первоклассный объект.
Поняв, что функция — частный случай отношения, можно сделать ещё больше.
Я уже писал генератор парсера на Nemerle. Генератор парсера — это функция, отображающая некоторое подмножество конекстно-свободных грамматик на множество детерминированных автоматов с МП. В принципе, у меня были идеи, как написать всё это дело на чистом языке. Но это неудобно. Некоторые вещи вообще императивно реализуются проще — например, часто встречающаяся задача отыскать элементы множества, заданного индуктивно. Я так и не придумал хорошей реализации в терминах чистой функции, за исключением грубой эмуляции очереди и множества, просто в чистом случае му ничего не модифцируем, а таскаем очередь и множество в параметрах функции.
Но вот в чём беда. На том же Хаскелле я в принципе могу написать генератор парсера, который бы выдавал код, вроде Yacc. Но как сделать, чтобы всё это было бесшовно. Разве что на замыканиях, но это же медленно. Кроме того, хотелось бы, чтобы парсер конструировался не в рантайме.
K>>Ну, самые простые вещи понять можно без ТК, на интуитивном уровне. Но вот я видел такие выверты, что тут без ТК, ИМХО, не обошлось.
L>Глубоко же ты копал. А где, если не секрет?
Копал не глубоко. Просто по всяким книжкам и статьям по Хаскелю пытался разобраться, но понял только в пределах простейших вещей в IO. В той же самой статье приводятся примеры, которых я не понял. Например, когда на монадах основаны Maybe, списки и т.д. Говорят, что вроде это способствует лучшей модульности. Я вот и пытаюсь понять, как.
... << RSDN@Home 1.2.0 alpha rev. 672>>
Re[15]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, Gaperton, Вы писали:
M>>А при чём тут schema? Про существование CLOS я знаю, что это можно сделать на схеме — тоже. M>>Речь шла о хаскеле.
G>С чего это вы взяли, коллега, что речь шла о Хаскеле? Слова "Хаскель" я не произносил. Я сказал — "первоклассные функции, атомы, и сопоставление с образцом". Имея в виду, кстати, Эрланг (в 1
якотором объекты, кстати, изначально присутствуют, в точности как в Smalltalk 72 — они делаются процессами). Но в схеме все перечисленное тоже есть.
С того, что речь в этой ветке идёт о хаскеле, с его крутой системой типов. Которая может и заменяет макросы (в чём я соменваюсь), а вот с ОО не дружит принципиально.
Но если вы о схеме речь завели — то лисп со схемой — это макросо-ориентированные языки по самые гланды. Там это на макросах сделано, а не на системе типов.
Здравствуйте, deniok, Вы писали:
D>Кстати здорово — задача оптимизации решается прямым указанием оптимизатору! Rewrite Rules rulez
Не думаю, что это здорово. оптимизации надо оставлять оптимизатору, выражение a+b+c очень уж конкретное.
Так никаких рулесов не напасёшься, да и сами реализации этих оптимизаций писать придётся.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[13]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, Gaperton, Вы писали:
G>Я воспользуюсь flex, или любой подобной тулзой. По ним хотя-бы документация есть, и мой код все поймут, а в велисипеде на макросах еще рабираться надо будет стороннему программеру. Недостатка в генераторах лексеров и парсеров нет ни для какого языка. Буквально для любого языка есть выбор.
А чего в макросе, генерящем лексер, велосипедного? Если этим всерьёз заняться, написать документацию — будет не хуже любого flex. Тем более, что ничего сверхъестественного там нет — тот же самый EBNF, что и во всяких там ANTLR, синтаксис один-в-один. Да и разбираться в том же ANTLR тоже нужно, как и с макросом. Только, ИМХО, lex-образные утилиты таскать за собой менее удобно, чем ту же самую спеку писать тут же, рядом с кодом, который всё это обрабатывает. Заодно у макросов есть достоинство — любые ошибки в спецификации тут же подчёркиваются IDE.
G>>>ага. И каждый ваш новоопределенный макрос — каждый, делает этот язык все более навороченным — причем, без контроля и толковых спецификаций. Что может быть и ускорит разработку, когда вы работаете в одиночку, но приведет к катастрофе, если над проектом работает большая группа. Сразу напишете неподдерживаемый код, который потом в помойку пойдет через пару лет.
K>>Введение в язык средств абстракции вроде функций, модулей, объектов так же чревато тем, что кто-то понапишет кривых библиотек (вспомним, как было с C++ и строками). И ничего, вроде как-то пишут вполне поддерживаемый код, не отказываясь от этих абстракций.
G>Странно, пишешь вроде просто и понятно, но такое впечатление — что люди либо не читают, либо не понимают. Проблема не в наличии абстракций вроде функций, модулей, и объектов. Проблема в том, что твои собственные расширения языка никто не знает, и знать, что характерно, не хочет.
Нет, я читал внимательно. Но знаешь, в некоторой степени, функции и классы — тоже расширение языков, пусть и примитивное. Мои собственные библиотеки тоже знать никто не знает и знать не хочет (хотя это мы ещё посмотрим ). Чем в этом смысле библиотека макросов отличается от библиотеки функций?
G> А по нормальным языкам есть толковая документация и (даже!) учебники.
Зато для этих языков некоторые Васи Пупкины такие библиотеки пишут, что плеваться хочется.
G>Которые детально разжевывают для непонятливых предназначение абстракций.
В книгах по .NET Framework (точнее, по его отдельным частям ) тоже детально разжёвываются предназначения абстракций. И это не мешает людям писать кривые библиотеки, котрыми больше никто не пользуется. Хотя в случае с C# ситуация лучше, чем была с C++.
G>Ничего кроме нечленораздельного мата у инженера, который потом за тобой баги будет править, твои расширения в большинстве случаев вызывать не будут — потому что на саппорте надо багу бытро править и уметь быстро разбираться в коде (желательно, нешифрованном макросами коде написанном на всем известном языке).
Я могу так же взять C#, как всем известный язык. Но начать юзать для него вместо .NET Framework библиотеки, написанные неизвестно кем (хотя бы даже свои). И знаешь, инженер, который будет править баги, будет материться не меньше.
G>Ты будешь по учебнику писать к каждой своей программе? А если у вас 20 человек пишут один программный комплекс, и каждый шибко умный — макросы пишет, — что тогда? Каждый будет учебники писать? Почему никто не задумывается о том, как процесс разработки реальных систем в больши командах на языках с макросредствами пойдет, и чем кончится, интересно?
Это уже проблемы команды. Если у них нет толкового архитектора, нет нормального менеджмента, то они всё равно плохо кончат.
G> Это шибко сложно, представить, какой кавардак начнется? Вы знаете, что менеджер сделает первым делом в таком проекте? Он, если у него чувство самосохранения и остатки здравого смысла есть — первым делом строго ограничит применение макросов — они будут запрещены к применению вне рамок очень компактного ядра системы — фреймворка, если он, тот фреймворк, вообще у вас в задаче будет.
Ага, правильно менеджер сделает.
G> Потому что он далеко не всегда вообще нужен. И пишут его редко, и допущены к его правке всего несколько человек.
Но так это же не отменяет полезности макросов. А в команде, которая решила юзать язык с макросами, можно просто ввести долю тоталитаризма.
... << RSDN@Home 1.2.0 alpha rev. 672>>
Re[20]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, konsoletyper, Вы писали:
K>Я уже писал генератор парсера на Nemerle. Генератор парсера — это функция, отображающая некоторое подмножество конекстно-свободных грамматик на множество детерминированных автоматов с МП. В принципе, у меня были идеи, как написать всё это дело на чистом языке. Но это неудобно.
Ну у нас не идёт спор чистый vs грязный
Мы пока о макрах.
K>Некоторые вещи вообще императивно реализуются проще — например, часто встречающаяся задача отыскать элементы множества, заданного индуктивно. Я так и не придумал хорошей реализации в терминах чистой функции, за исключением грубой эмуляции очереди и множества, просто в чистом случае му ничего не модифцируем, а таскаем очередь и множество в параметрах функции.
Не понял. Что значит отыскать элементы множества, заданного индуктивно?
K>Но вот в чём беда. На том же Хаскелле я в принципе могу написать генератор парсера, который бы выдавал код, вроде Yacc. Но как сделать, чтобы всё это было бесшовно.
Не понимаю. Обсуждаемый Parsec не генерит код. Это такой DSL, который используется прямо в коде. Это бесшовно?
K>Разве что на замыканиях, но это же медленно. Кроме того, хотелось бы, чтобы парсер конструировался не в рантайме.
Тоже не понимаю, в чём проблема.
Замыканий в Haskell-е нет, в том смысле, что переменные неизменны. Т.е. это простые лямбды. Ты про них?
Конструирование парсера в рантайме происходит ровно один раз.
L>>Глубоко же ты копал. А где, если не секрет?
K>Копал не глубоко. Просто по всяким книжкам и статьям по Хаскелю пытался разобраться, но понял только в пределах простейших вещей в IO. В той же самой статье приводятся примеры, которых я не понял. Например, когда на монадах основаны Maybe, списки и т.д. Говорят, что вроде это способствует лучшей модульности. Я вот и пытаюсь понять, как.
Модульности в том смысле, что имеют один интерфейс. Это используется, например, в монад-трансформерах. При композиции монад мы не знаем какую монаду оборачиваем, да нам это и неважно, пока мы работаем на верхнем уровне. Таким образом, мы можем объединить монады в одну (по принципу декоратора) и получить монаду которая и ошибки обрабатывает, и лог пишет, и состояние хранит и т.д. Хотя за каждое поведение отвечает одна единственная составляющая этой монады, таким образом всё не перемешано в одном месте. Может это имелось в виду?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[21]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, lomeo, Вы писали:
L>Ну у нас не идёт спор чистый vs грязный L>Мы пока о макрах.
Мы о macros vs. functions?
K>>Некоторые вещи вообще императивно реализуются проще — например, часто встречающаяся задача отыскать элементы множества, заданного индуктивно. Я так и не придумал хорошей реализации в терминах чистой функции, за исключением грубой эмуляции очереди и множества, просто в чистом случае му ничего не модифцируем, а таскаем очередь и множество в параметрах функции.
L>Не понял. Что значит отыскать элементы множества, заданного индуктивно?
Типа, конечное множество задаётся индуктивно. Необходимо перечислить все его элементы. Например, epsilon-замыкание некоторого состояния ДКА. Или множества FIRST и FOLLOW для символа грамматики.
K>>Но вот в чём беда. На том же Хаскелле я в принципе могу написать генератор парсера, который бы выдавал код, вроде Yacc. Но как сделать, чтобы всё это было бесшовно.
L>Не понимаю. Обсуждаемый Parsec не генерит код. Это такой DSL, который используется прямо в коде. Это бесшовно?
Это бесшовно. Но я так не напишу.
L>Тоже не понимаю, в чём проблема. L>Замыканий в Haskell-е нет, в том смысле, что переменные неизменны. Т.е. это простые лямбды. Ты про них?
Вроде замыкание — это когда переменная вытягивается из контекста. Причём тут изменяемые перменные? Просто замыкания компилятся в не самый хороший и быстрый код.
L>Конструирование парсера в рантайме происходит ровно один раз.
В рантайме? А в compile-time? Тут уж без макросов не обойтись.
... << RSDN@Home 1.2.0 alpha rev. 672>>
Re[22]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, konsoletyper, Вы писали:
K>Мы о macros vs. functions?
В общем да.
L>>Не понял. Что значит отыскать элементы множества, заданного индуктивно?
K>Типа, конечное множество задаётся индуктивно. Необходимо перечислить все его элементы. Например, epsilon-замыкание некоторого состояния ДКА. Или множества FIRST и FOLLOW для символа грамматики.
А детерминированные автоматы бывают с эпсилон переходами? Не знаю просто.
Почему нельзя получить не знаю. Достаточно в представлении автомата иметь возможность получить все эпсилон-переходы.
Дальше просто.
eClosure automata state = state : concatMap (\trans -> eClosure automata (trans state)) transitions
where
transitions = eTransitions automata state
Если ты про то определение множества, что я дал, то я там оговорил, что оно не для перечисления элементов.
Однако вот это множество чисто и вполне годится и для этой роли.
L>>Тоже не понимаю, в чём проблема. L>>Замыканий в Haskell-е нет, в том смысле, что переменные неизменны. Т.е. это простые лямбды. Ты про них?
K>Вроде замыкание — это когда переменная вытягивается из контекста. Причём тут изменяемые перменные? Просто замыкания компилятся в не самый хороший и быстрый код.
Может быть. Это же ФВП в конце концов.
L>>Конструирование парсера в рантайме происходит ровно один раз.
K>В рантайме? А в compile-time? Тут уж без макросов не обойтись.
Ну я не знаю во что синлайнится мой код Это просто разные подходы.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[14]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, Gaperton, Вы писали:
L>>Круто. А можно поглядеть на С++ реализацию?
G>Гуру из нашей С++ конфы говорят, что есть в библиотеке Blitz++, а вообще решение искать надо по словам expression templates. Сразу предупреждаю — это очень злой С++. Но если попривыкнуть — то там, в сущности, все понятно .
Пока разобрался до момента инлайна, как врублюсь — отпишу.
Кажется это можно сделать на Хаскеле с помощью простых ФВП и потом deforestation.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[23]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, lomeo, Вы писали:
K>>Мы о macros vs. functions?
L>В общем да.
Тогда я не о чистоте а о функциях. В том смысле, что генерация парсера — тоже функция.
K>>Типа, конечное множество задаётся индуктивно. Необходимо перечислить все его элементы. Например, epsilon-замыкание некоторого состояния ДКА. Или множества FIRST и FOLLOW для символа грамматики.
L>А детерминированные автоматы бывают с эпсилон переходами? Не знаю просто.
О, конечно нет. Это очепятка. Имелся в виду НКА.
L>Почему нельзя получить не знаю. Достаточно в представлении автомата иметь возможность получить все эпсилон-переходы. L>Дальше просто.
L>
L>eClosure automata state = state : concatMap (\trans -> eClosure automata (trans state)) transitions
L> where
L> transitions = eTransitions automata state
L>
L>Если ты про то определение множества, что я дал, то я там оговорил, что оно не для перечисления элементов. L>Однако вот это множество чисто и вполне годится и для этой роли.
Не, я вообще про другое. Просто хотелось описать задачу, которую не сумел нормально решить в терминах чистого ФП.
А как приведённый код обработает циклы, сотосящие из epsilon-переходов?
L>Ну я не знаю во что синлайнится мой код Это просто разные подходы.
Да я тоже не знаю. Просто чётко знаю, что парсер в получившейся сборке будет уже готовый, никакой генерации в рантайме не будет.
... << RSDN@Home 1.2.0 alpha rev. 672>>
Re[15]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, lomeo, Вы писали:
L>Здравствуйте, deniok, Вы писали:
D>>Кстати здорово — задача оптимизации решается прямым указанием оптимизатору! Rewrite Rules rulez
L>Не думаю, что это здорово. оптимизации надо оставлять оптимизатору, выражение a+b+c очень уж конкретное. L>Так никаких рулесов не напасёшься, да и сами реализации этих оптимизаций писать придётся.
Ну почему бы не прооптимизировать конкретный модуль, если видно, как?
Кстати твой a+b+c=... вроде незаконен,
The left hand side of a rule must consist of a top-level variable applied to arbitrary expressions.
Очевидно надо так (+) a ((+) b c)=...
Для более общего случая можно замутить что-то вроде:
Пусть у нас есть FastVectors, линейные операции типа сложения над ними определяем через аналог zipWith
a `op` b = zipWithFV op a b
Делаем хинт (ох опасный, но, ладно, только для этой библиотеки )
forall a b c op1 op2. op1 a (op2 b c) = (op1 .## op2) a b c
Ну, естественно, zipWithFV3 должен быть определен, то есть для произвольного числа слагаемых оптимизация не проканает.
Ну и ещё надо надеятся на то, что ((+) .## (+)) a b c, раскроется в эффективную реализацию сложения a+b+c, что скорее всего так — композиции композиций по наблюдениям порождают быстрый код.
Re[16]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, mkizub, Вы писали:
M>С того, что речь в этой ветке идёт о хаскеле, с его крутой системой типов. Которая может и заменяет макросы (в чём я соменваюсь), а вот с ОО не дружит принципиально.
В этой подветке, которую начал я, я про Хаскель с его крутой системой типов речи не вел.
M>Но если вы о схеме речь завели — то лисп со схемой — это макросо-ориентированные языки по самые гланды. Там это на макросах сделано, а не на системе типов.
Вам ясно сказали, черным по белому, что в схеме ОО делается без макросов. На замыканиях оно делается в схеме.
Re[14]: Являются ли макросы свидетельством недостаточной выр
[]
K>Я могу так же взять C#, как всем известный язык. Но начать юзать для него вместо .NET Framework библиотеки, написанные неизвестно кем (хотя бы даже свои). И знаешь, инженер, который будет править баги, будет материться не меньше.
Зато отладка макросов это очень неприятное занятие.
[]
Re[20]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, konsoletyper, Вы писали:
K>Я уже писал генератор парсера на Nemerle. Генератор парсера — это функция, отображающая некоторое подмножество конекстно-свободных грамматик на множество детерминированных автоматов с МП. В принципе, у меня были идеи, как написать всё это дело на чистом языке. Но это неудобно. Некоторые вещи вообще императивно реализуются проще — например, часто встречающаяся задача отыскать элементы множества, заданного индуктивно. Я так и не придумал хорошей реализации в терминах чистой функции, за исключением грубой эмуляции очереди и множества, просто в чистом случае му ничего не модифцируем, а таскаем очередь и множество в параметрах функции.
Перечисление элементов множества, определенного индуктивно, реализуется элементарно:
Проблема не в наличии абстракций вроде функций, модулей, и объектов. Проблема в том, что твои собственные расширения языка никто не знает, и знать, что характерно, не хочет. А по нормальным языкам есть толковая документация и (даже!) учебники. Которые детально разжевывают для непонятливых предназначение абстракций. Ничего кроме нечленораздельного мата у инженера, который потом за тобой баги будет править, твои расширения в большинстве случаев вызывать не будут — потому что на саппорте надо багу бытро править и уметь быстро разбираться в коде (желательно, нешифрованном макросами коде написанном на всем известном языке). 
Все только говорят, говорят о великих и ужасных макросах — и все 
). Чем в этом смысле библиотека макросов отличается от библиотеки функций?
