Здравствуйте, Курилка, Вы писали:
VGn>>Слишком навороченный язык — имхо тоже зло.
К>Что есть критерий навороченности? Макросы ведь однозначно делают язык навороченней.
Макросы очень похожи на библиотеки. Точнее они ими и являются. Только библиотека расширяет набор доступных типов и фунций, а макрос набор достпных фич языка. Причем макрос, в отличии от фичи встроенной непосредственно в язык, лежит в своем пространстве имен и по игнорируется всеми кому он не нужен.
Другими словами макросы меняют язык локально. Это типа волшебной палочки позволяющей добавить в язык нужные средства для решения конкретного класса задач.
В прочем, грань между макросом и реальной фичей языка очень зыбка. В том же Немерле многие языковые фичи реализованы с помощью маросов или исползуют макросы. Для программиста-пользоватля — это язык. А для программиста-разработчика компилятора макросы — это (в том числе) средство радикально упростить разработку компилятора.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Являются ли макросы свидетельством недостаточной выра
Здравствуйте, deniok, Вы писали:
D>Безотносительно к системам типов: а почему для DSL-ей обязательно нужны макросы?
D>Вот в Хаскелле библиотека комбинаторов для парсинга Parsec вполне себе создаёт удобный DSL для соответствующих задач, позволяя легко собирать парсеры из более простых, и вообще использовать их как первоклассные объекты — помещать в списки, передавать и возвращать из функций, etc. И никакой особой магии с типами не требуется, монад (которые, кстати, пользователю библиотеки не видны) вполне достаточно.
Испоьзовать фунции высшего порядка и их комбинации сегодня можно даже в C#. Но вот для реальной жизни нужно порой изменять синтаксис и/или производить вычисления во время компиляции. ФВП этого делать не позволяют. Но несоменно, что если задача рашается без метапрограммирования (МП) и при этом получаетя приемлемый (по всем показателям) результат, то прибегать к МП нет никагого смысла. Причем не важно реализуется МП макросами или выкрутасами с системой типов Хасклея/С++.
К сожалению, на практике есть масса мест где программист хотел бы расширить возможности комплитора, повычислять что-то в компайлатайме или просто сгенерировать код по шаблону. Хаскель кое что из этого позволяет, но в большинстве случаев при этом используются выкрутасы с системой типов.
Но, самое смешное, что в Хаскеле (точнее его базовой реализации) есть прямой путь для решения этих проблем. ТемлэйтХаскель никто не оменял. И для решения проблем с помощью МП он подходит намного лучше чем просто Хаскель. Да что там говорить? Сам факт наличия этого расширения говорит о том, что кому-то оно было нужно. Не так ли?
Что же касается Парсека, то лично у мепня шарики от него завихиваются. Такое обильное использование монад до добра не доводят. По мне так эти монады ухреначивают код не хуже сишных макросов. В прочем, может это как с маслинам и анчеусами...
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Являются ли макросы свидетельством недостаточной выра
Здравствуйте, FR, Вы писали:
FR>В Смаллталке нет супер системы типов, нет и макросов, однако гибкость языка (+ метаклассы) позволяет легко решать те же задачи для которых используются макросы.
Ничего они не позволяют решать. В Смолтоке используется самая поганая система метапрограммирования из известных человечеству — генерация исходного текста и компиляция его на лету. Метаклассы лишь приятный бонус инкапсулирующий паттерны вроде абстракных фабрик. Свми по себе метаклассы метапрограммирования не предоставляют.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, the_dip, Вы писали:
_>>Раз так, то может приведете пример задачи, которую Вы не умеете решать без использования макросов?
VD>Любой DSL.
Ммм, значит DSL на хаскеле или скале "не считаются"?
Re[12]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, VladD2, Вы писали:
VD>В прочем, грань между макросом и реальной фичей языка очень зыбка. В том же Немерле многие языковые фичи реализованы с помощью маросов или исползуют макросы. Для программиста-пользоватля — это язык. А для программиста-разработчика компилятора макросы — это (в том числе) средство радикально упростить разработку компилятора.
Я согласен с тем что язык программирвания должен быть адекватен задаче.
Но в системах где язык строится под задачу мы имеем проблему обучения — освоение превращается в нетривиальную и постоянно меняющуюся задачу.
В результате получается что единтсвенным пользователем разлапистой системы макросов (нового ЯП фактически) становится сам автор этой системы.
Т.е. сама супергибкая система теряет смысл очень часто.
Я думаю что можно говорить о том что BISON/YACC + С есть некий супер-мета-язык.
Такой подход в котором мухи с котлетами отдельно подчас более честный что-ли.
Re[12]: Являются ли макросы свидетельством недостаточной выр
K>Даже такой элементарный пример позволяет, в общем-то проиллюстрировать. Чуть более сложный K>
K>r := b - A*x;
K>
K>мне уже расписывать лень. K>Каким еще способом можно добиться того, чтобы DSL не проигрывал в производительности коду a la FORTRAN? K>Лично мне очень интересно.
На C++ шаблонах такое пишется без проблем, используются ленивые вычиления, то есть выражение собирается в operator= скорость не уступает сишной.
Re[14]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, mkizub, Вы писали:
FR>>Вот на схеме без использования макросов http://okmij.org/ftp/Scheme/pure-oo-system.scm
M>А при чём тут schema? Про существование CLOS я знаю, что это можно сделать на схеме — тоже. M>Речь шла о хаскеле.
Вроде речь шла о том что можно реализовать без макросов, там это сделано при том:
; The present code implements a classless, delegation-based OO system, similar
; to those of Self or Javascript. This is a full-fledged OO system with
; encapsulation, object identity, inheritance and polymorphism. It is also
; a purely functional system: there is not a single assignment or
; other mutation in the code below.
Так что думаю на любой функциональный язык перепишется.
Re[6]: Являются ли макросы свидетельством недостаточной выра
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, FR, Вы писали:
FR>>В Смаллталке нет супер системы типов, нет и макросов, однако гибкость языка (+ метаклассы) позволяет легко решать те же задачи для которых используются макросы.
VD>Ничего они не позволяют решать. В Смолтоке используется самая поганая система метапрограммирования из известных человечеству — генерация исходного текста и компиляция его на лету. Метаклассы лишь приятный бонус инкапсулирующий паттерны вроде абстракных фабрик. Свми по себе метаклассы метапрограммирования не предоставляют.
Влад ты демонстрируешь сейчас абсолютного Блаба.
В том же смаллтаке очень многое (например управляющие инструкции) реализуется без метаклассов, чисто на блоках кода.
Re[19]: Являются ли макросы свидетельством недостаточной выр
Klapaucius,
K>>Вот Хаскель — продвинутый язык, и в нём можно во многих случаях сделать то, что в Лиспе делается исключительно на макросах. Но не всё. Так почему же Хаскелю не нужны макросы?
K>Ну... Те кто делал Template Haskell по всей видимости думали, что Haskell макросы нужны.
Да, думали...
The single biggest criticism that can be launched against Template Haskell is the lack of compelling applications. We have explored a handful of scenarios in which Template Haskell would be useful, the coolest, albiet unimplemented, being the universal algebraic-fold. But the list of possible applications that we have assembled doesn't warrant the technical effort that Template Haskell represents; nor do the examples that Simon Peyton Jones and Tim Sheard provide in their paper... And so the most interesting question is, perhaps, why the scope of Template Haskell's applicability seems to be so narrow.
(обращаю внимание на первое и последнее предложения)
Наиболее часто применение TH я встречал в виде хаков и триков для достижения убойного перфоманса. Например, известно, что на продолжениях можно получить офигенный прирост производительности — это один из легальных способов форсирования вычислений и избегания ленивости. Но писать в таком стиле довольно тяжело, поэтому TH здесь может оказаться полезен ("может", потому что эффект от прироста производительности и сахара запросто может быть нивелирован усложнением разработки из-за появившейся двухслойности).
L>>eClosure automata state = state : concatMap (\trans -> eClosure automata (trans state)) transitions
L>> where
L>> transitions = eTransitions automata state
L>>
K>А как приведённый код обработает циклы, сотосящие из epsilon-переходов?
Хреново.
Вместо операции ( здесь надо брать такую, что создаёт множество из единственного элемента и потом добавляет к нему множество, переданное вторым аргументом.
Или сразу в функции передавать состояния, которые уже есть. В общем то, проблемы большой нет.
K>Да я тоже не знаю. Просто чётко знаю, что парсер в получившейся сборке будет уже готовый, никакой генерации в рантайме не будет.
В этом смысле да — макросы как кодогенераторы (если нам нужен именно кодогенератор) в общем случае незаменимы.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[5]: Являются ли макросы свидетельством недостаточной выра
Здравствуйте, VladD2, Вы писали:
VD>Испоьзовать фунции высшего порядка и их комбинации сегодня можно даже в C#. Но вот для реальной жизни нужно порой изменять синтаксис и/или производить вычисления во время компиляции.
Изменение синтаксиса и вычисление во время компиляции — это да. Это область макросов, но при чём тут DSL?
VD>Причем не важно реализуется МП макросами или выкрутасами с системой типов Хасклея/С++.
Что такое выкрутасы с системой типов Хаскеля? Вот мы тут с konsoletyper про Parsec говорили. Это выкрутасы?
VD>К сожалению, на практике есть масса мест где программист хотел бы расширить возможности комплитора, повычислять что-то в компайлатайме или просто сгенерировать код по шаблону. Хаскель кое что из этого позволяет, но в большинстве случаев при этом используются выкрутасы с системой типов.
VD>Но, самое смешное, что в Хаскеле (точнее его базовой реализации) есть прямой путь для решения этих проблем. ТемлэйтХаскель никто не оменял.
Ну про базовую не верно. Я кроме GHC не знаю где ещё есть.
VD>И для решения проблем с помощью МП он подходит намного лучше чем просто Хаскель. Да что там говорить? Сам факт наличия этого расширения говорит о том, что кому-то оно было нужно. Не так ли?
Да. Оно нужно для того, для чего нужны макросы — компайл-тайм кодогенерация.
VD>Что же касается Парсека, то лично у мепня шарики от него завихиваются. Такое обильное использование монад до добра не доводят. По мне так эти монады ухреначивают код не хуже сишных макросов. В прочем, может это как с маслинам и анчеусами...
Где монады при использовании Парсека? Там вообще парсер сделали монадой только чтобы можно было в do писать. А так писал бы, ствавя вместо EBNF-ной запятой свой значок.
Вон konsoletyper написал код для парсинга JSON-а. Повтори на Парсеке — будет практически один в один.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[15]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, mkizub, Вы писали:
FR>>>Вот на схеме без использования макросов http://okmij.org/ftp/Scheme/pure-oo-system.scm
M>>А при чём тут schema? Про существование CLOS я знаю, что это можно сделать на схеме — тоже. M>>Речь шла о хаскеле.
FR>Вроде речь шла о том что можно реализовать без макросов, там это сделано при том: FR>
FR>; The present code implements a classless, delegation-based OO system, similar
FR>; to those of Self or Javascript. This is a full-fledged OO system with
FR>; encapsulation, object identity, inheritance and polymorphism. It is also
FR>; a purely functional system: there is not a single assignment or
FR>; other mutation in the code below.
FR>Так что думаю на любой функциональный язык перепишется.
Ну, это все-таки жесть В схеме можно и замыкания с деструктивными присваиваниями использовать — должно быть проще.
Re[10]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, the_dip, Вы писали:
_>>Раз так, то может приведете пример задачи, которую Вы не умеете решать без использования макросов?
VD>Любой DSL.
А лексо-яко-подобные тулзы никак нам в этом не помогут, да?
Re[6]: Являются ли макросы свидетельством недостаточной выра
Здравствуйте, VladD2, Вы писали:
FR>>В Смаллталке нет супер системы типов, нет и макросов, однако гибкость языка (+ метаклассы) позволяет легко решать те же задачи для которых используются макросы.
VD>Ничего они не позволяют решать. В Смолтоке используется самая поганая система метапрограммирования из известных человечеству — генерация исходного текста и компиляция его на лету. Метаклассы лишь приятный бонус инкапсулирующий паттерны вроде абстракных фабрик. Свми по себе метаклассы метапрограммирования не предоставляют.
FR>>Так что думаю на любой функциональный язык перепишется.
G>Ну, это все-таки жесть В схеме можно и замыкания с деструктивными присваиваниями использовать — должно быть проще.
Ты сходи по ссылке, нет там императивщины.
Re[6]: Являются ли макросы свидетельством недостаточной выра
Здравствуйте, Gaperton, Вы писали:
G>А лексо-яко-подобные тулзы никак нам в этом не помогут, да?
На макросах в подавляющем большинстве случаев гооораздо проще.
Вернее даже так: Я не представляю когда лексо-яки при создании ДСЛ будут лучше.
Может приведешь пример?
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[7]: Являются ли макросы свидетельством недостаточной выра
Здравствуйте, konsoletyper, Вы писали:
L>>Вон konsoletyper написал код для парсинга JSON-а. Повтори на Парсеке — будет практически один в один.
K>Это не я писал, вообще-то. Я писал код для раскраски C#. Там всё не совсем один-в-один. Типа, я ношусь с идеей отделения кода от спецификации.
В смысле? flex/yacc?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[16]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, Gaperton, Вы писали:
G>Ну, это все-таки жесть В схеме можно и замыкания с деструктивными присваиваниями использовать — должно быть проще.
IORef?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[8]: Являются ли макросы свидетельством недостаточной выра
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
