Здравствуйте, cl-user, Вы писали:
CU>"Имя, сестра, имя!"
У тебя просто неконструктивная позиция. Тебе не интересно следующее поколение средств мета-программирования, что-бы ты об этом не декларировал. Не вижу смысла в дальнейшем обсуждении.
AF>еще можно использовать profiler API, чтобы модифицировать IL код перед выполнением JIT-a
Маловато будет, тут по большей части просто процессоры IL, Феникс вообще пока умер. Есть еще RAILS — но они тоже как-то присмерти.
FR>>"Интерпретор" у форта как ты наверно знаешь, имеет некторые особенности которые позволяют ему по скорости мало уступать тупым плохо оптимизирующим компиляторам (а явовские в мобилках именно такие), правда эти же особенности мешают построить хороший оптимизирующий компилятор. Но компиляторы у форта есть и посоревноватся с той же явой вполне могут.
M>Этого не может быть, потому, что этого не может быть никогда.
Угу пока не ознокомишся как форт система работает.
M>Любой, самый тупой из тупых компиляторов разворачивает байткод в последовательность комманд процессора, экономя на каждой комманде чтение опкода и джамп на хэндлер. У ARM эти две операции совмещены, но джамп занимает больше такта. У MIPS их надо делать отдельно, но он выполняет ещё одну инструкцию, в течении джампа. Итого — минимальная прибыль от компилятора, даже если он тупо работает со стеком и не занимается регистрами — 2-3 такта на инстукцию. Если он ещё регистры использует (даже без оптимизации) — то это ещё раза в 2 ускорение.
"Интерпретатор" прямого шитого кода в форте состоит всего из нескольких ассемблерных команд, суть его работы в том что выбирает адрес слова и делает косвенный call. То есть добавляется на один косвенный вызов больше чем при непосредственном вызове подпрограммы. Компиляторы просто заменяют этот косвенный вызов на прямой call и инлайнят низкоуровневые слова.
M>Фсё, я тему быстродействия больше в этом топике не обсуждаю. Если есть что-то конкретное в виде бенчмарков — можно обсудить в новом топике.
Дя бенчмарков я форт слишком давно в руках не держал.
Re[51]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, mkizub, Вы писали:
CU>>"Имя, сестра, имя!"
M>У тебя просто неконструктивная позиция. Тебе не интересно следующее поколение средств мета-программирования, что-бы ты об этом не декларировал. Не вижу смысла в дальнейшем обсуждении.
Из чего это следует? Хотя в одном ты прав — МП само по себе и "в собственном соку" меня не интересует, а как одно из "в одном флаконе" (наряду с ФП, СП, ПП, ООП, ДП и проч.) — очень даже.
Я и не собирался ничего обсуждать. Я хотел что-то увидеть, "уделывающее" лисп по МП, не не такое как N Ан нет — не существует.
Re[52]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, cl-user, Вы писали:
CU> МП само по себе и "в собственном соку" меня не интересует, а как одно из "в одном флаконе" (наряду с ФП, СП, ПП, ООП, ДП и проч.) — очень даже.
SOP является языко-независимой (нейтральной) концепцией и ортогональной остальным парадигмам. Вот то, что ты пишешь — это оно и есть.
CU>Я хотел что-то увидеть, "уделывающее" лисп по МП, не не такое как N Ан нет — не существует.
Опять ты путаешь слова. Оно есть, существует, но ты его не увидел. Нечем, видимо, было увидеть.
Никто, в здравом уме и памяти не станет считать себя умелым канатоходцем просто от того, что ему рассказали или он книжку прочитал — как ходить по канату.
Так же и парадигмы программирования, вроде ООП/ФП/логической/императивной и пр. — это не просто слова, которые достаточно прочитать. Это такой способ думать. И его надо осваивать так-же, как учиться ходить на канате. А пока ты это не попробовал (а ты даже для себя не сформулировал что ты ищешь) — ты не поймёшь, что такого особенного в SOP.
Здравствуйте, mkizub, Вы писали:
CU>> МП само по себе и "в собственном соку" меня не интересует, а как одно из "в одном флаконе" (наряду с ФП, СП, ПП, ООП, ДП и проч.) — очень даже.
M>SOP является языко-независимой (нейтральной) концепцией и ортогональной остальным парадигмам. Вот то, что ты пишешь — это оно и есть.
CU>>Я хотел что-то увидеть, "уделывающее" лисп по МП, не не такое как N Ан нет — не существует.
M>Опять ты путаешь слова. Оно есть, существует, но ты его не увидел. Нечем, видимо, было увидеть.
Просто нечего увидеть. Недопарадигма без документации и спецификации. И недопрограмма "сама в себе", ограниченная VM, прямо сейчас ничего не дающая. DOC-файл, наполненный маркетологическим бредом и не содержащий ни малейшей структурной информации. Что увидеть?! В сад!
M>Никто, в здравом уме и памяти не станет считать себя умелым канатоходцем просто от того, что ему рассказали или он книжку прочитал — как ходить по канату.
Но языком физики достаточно легко описать трудности/возможные решения. А на словах "возьми шест и маши" конечно ничего не опишешь!
M>Так же и парадигмы программирования, вроде ООП/ФП/логической/императивной и пр. — это не просто слова, которые достаточно прочитать. Это такой способ думать.
Бред сивой кобылы. (сорри) Все парадигмы ("настоящие") элементарно описываются обычным человеческим языком. "Неформализуемую" информацию оставьте сектантам.
M>И его надо осваивать так-же, как учиться ходить на канате. А пока ты это не попробовал (а ты даже для себя не сформулировал что ты ищешь) — ты не поймёшь, что такого особенного в SOP.
Опять бред. Не "попробовав" ФП/ООП трудно оценить эффективность парадигмы для определённых задач, но понять сами парадигмы по документации — элементарно.
P.S. А не против именно SOP — но я не увидел именно документации. А сопли "а вот раньше... большинство программистов... было невозможно... а теперь элементарно..." — оставьте маркетологам.
P.P.S. Можете банить — не считаю необходимым вести спор "в техническом русле" с оппонентами, шарахающимися тех. информации как чёрт ладана.
P.P.P.S. Все остальным — ещё раз "сорри"
Re[15]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, lomeo, Вы писали:
L>Мне кажется именно это решение возможно на чистых ФВП и ПМ:...
Это где угодно можно делать. Толкьо это не эффектвно и не гибко.
Макрос генерирует специализированный (оптимизированный) код для частных случаев. Так он обрабатывает ситуации в ктолрых речь идет о массивах и генерирует for-ы, обрабатывает ситуацию когда коллекция реализует интерфейс IDisposable и вызывает при этом Dispose(), генерирует оптимальный код для списков и (что очень важно) разворачивает генераторы последовательностей в циклы. В итоге получается гибкое и оптимальное с точки зрения производительности решение. Причем синтаксически оно такое как хочется, а не такое как получается (как в твоих примерах).
В итоге мы имеем два решения. Одно для матиматиков (оно в Немерле тоже достпно). Второе для повседневной жизни. Быстрое, удобное и практичное.
L>Аналогично (строку не буду собирать)
А зря, кстати. Строка тоже собирается макросом. Он тоже явно боеле выразителен чем то что можешь предложить Хаскель.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[18]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, lomeo, Вы писали:
L>К сожалению, побился indent, а как тут файл залить можно?
Входишь в своей профайл и там есть сслочка на твои файлы. Ну, а там кнопочка "Загрузить".
L>Поставить можно GHC: L>http://haskell.org/ghc/download.html L>Качаешь, ставишь.
ОК.
L>Настраиваешь пути
Ну, это как всегда у ученых и юнисойдов. Ни дня без траха.
L>Э-э-э.. Что то я туплю с утра. Что увидеть?
Код целиком.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, lomeo, Вы писали:
L>Но ведь изначально вопрос стоял так: являются ли макросы неким маркером, сигналящем о недостаточной выразительности языка в той области, в которой они в этом языке применяются.
Дык... Вот мой пример и демонстрирует несостоятельность такой постановки вопроса.
В том же дотнете (а занчит в любом поддерживающем его языке) подобные задачи можно решать с помощью рефлексии. Вот только я в реальной жизни выбрал генерацию кода в компайлатме на макросах. И сделал это не просто так. Дело в том, что я выбрал оптимальное (для моей задачи) решение. Мне ну нужны лишние вычисления в рантайме. Я не верю в нулевой оверхэд любой рантайм подсистемы использующей информацию о типах. К тому же делая выбор в пользу рантайма мы неменуемо откладываем мноиге проверки до рантайма. А это уже значит, что мы получаем менее надежное решение. Например, мое решение во время компиляции информировало программиста о том, что перменные типа Location обязательно должны быть изменямыми (объявлены с идентефикатором mutable). Если бы этого не было, то ошибка выявлялась бы толко в рантайме и только кода мой код начал бы модифицировать конкретное поле.
В общем, это разные решения хотя и решающие одну и ту же задачу. У них разные характеристики.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[19]: Являются ли макросы свидетельством недостаточной выр
L>>Поставить можно GHC: L>>http://haskell.org/ghc/download.html L>>Качаешь, ставишь.
VD>ОК.
L>>Настраиваешь пути
VD>Ну, это как всегда у ученых и юнисойдов. Ни дня без траха.
VD>>Она мне нитересна, конечно. Но это только один вопрос. А их несколько. Вот в начале этого собщения мы говорим о логике постраителя парсера. Это мне тоже очень интересно. Потом интересна отладка. Да и просто поглядеть на то во что выльется грамматика интересно.
а ни во что она не выльется. это просто разбор рекурсивным спуском с автоматизацией всех спомогательных операций (переход к другой алтернативе, вывод сообщения об ошибке и т.п.). в общем-то типичное применение монад — предоставление некоторого сервиса с использованием "невидимой информации", передаваемой от операции к операции
кстати, был ещё и парсер, основанный на arrows. благодаря сойствам Arrow этот парсер действительнор генерил LR-таблицы разбора; насколько я понимаю, их подход дейстивтельно соответствовал BNF-описанию грамматики в виде eDSL с последующей генерацией кода, даром что это была библиотека:
Sometimes it's useful to restrict what you can do. Duponcheel and
Swierstra wrote a parser library as an Arrow; because it forced you to
decide the parsing structure ahead of time, their library had enough
information to build LR-type parsing tables, and thus to do yacc-style
error correction. (Nobody found it useful enough to use, but it still
makes a nice demonstration of why plain Arrow is sometimes better.)
кстати, вот здесь — haskell.org/haskellwiki/Blog_articles/Monads собрано 42 введение в монады. не может быть, чтобы среди них не нашлось ни одного, которого тебе удастся наконец понять
что касается generic programming. SYB, который вы здесь обсуждаете — лишь один из возможных подходов. я их в своё время насчитал десяток, а ведь я в этой области совсем не специалист. из них три поставляются с самим GHC — SYB, Template Haskell, [1]. В [2] даётся краткое описание всех подходов
теперь о том, каким образом *библиотека* может в *compile-time* сгенерить код, специализированный для данного конкретного типа. на самом деле ты знаешь ответ темплейты в C++ устроены похоже на type classes в хаскеле. когда ты даёшь темплейту аргумент определённого типа, он генерит код именно для данного конкретного типа. в хаскеле type inference позволяет вообще не писать типов данных и тем не менее гшенерить типо-специфичный код
далее, для каждого контейнерного типа пишется (или генерится) несколько стандартных процедур обхода — перечисление элементов (fold), генерация (unfold) и т.д. generic-процедуры программируются через эти операции, проверки, которые можнор разрешить в compile-time, превращаются в константные выражения, в результате темплейто-подобная кодогенерация плюс стандартная оптимизация генерит эффективную type-specific процедуру
впрочем, это только один из возможных подходов. он используется в syb4 Олега Киселёва [3]. syb0 проихзводит поверки в run-time, т.е. он аналогичен использованию RTTI в ООП языках. другие же подходы (GH, [1]) просто используют специаольный язык для описания generic процедур. это можно считать специализированным языком, позволяющим компилятору сгенерить type-speciifc код как в макросистемах или RTTI-based код. отличие от макросистем в том, что во всех случаях пользователь думает в терминах одноуровневого языка, а не двух отдельных систем — прецпроцессинга и собственно выполнения
Здравствуйте, BulatZiganshin, Вы писали:
BZ>для мартышек там есть автоматический инсталлятор
BZ>(не обижайся, Влад, сам таким пользуюсь)
Я и не обижаюсь. Просто неверная классификация. Только венец природы — половозрелый человек, может додуматься не делать лишней работы. А как раз мартышка с удовольствием полезет на дерево...
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, BulatZiganshin, Вы писали:
VD>>>Она мне нитересна, конечно. Но это только один вопрос. А их несколько. Вот в начале этого собщения мы говорим о логике постраителя парсера. Это мне тоже очень интересно. Потом интересна отладка. Да и просто поглядеть на то во что выльется грамматика интересно.
BZ>а ни во что она не выльется. это просто разбор рекурсивным спуском с автоматизацией всех спомогательных операций (переход к другой алтернативе, вывод сообщения об ошибке и т.п.).
Ясно. Ну, тогда это твое сообщение можно считать хорошим ответом на вопрос прозвучавший в этой теме ("Являются ли макросы свидетельством недостаточной выр...").
Макросы позволяют решать некоторые задачи (хорошим примером является построитель парсеров):
1. В компайлатайме.
2. С меньшими временными затратами в рантайме.
3. Обеспечивает большую гибкость (мы вольны вибирать алгоритмы и синтаксис не заморачиваясь на базовые фичи языка, ведь мы генерируем код).
4. Раньше выявлять ошибки.
В итоге тут просто нечго сравнивать. Несомненно если в задача с приемлемы качеством решается некой универсальной фунцией gmap, то лучше воспользоваться ею чем создавать специализированное решение на макросах. И наличие такой фунции, так же, несоменное пиремущество. Вот только это не доказательство крутости языка. Это доказательство прозорливости тех кто писал эту фунцию. Ее так же можно реализовать и с помощью макросов.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[23]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, lomeo, Вы писали:
L>Вообще должны, но поддерживаются не везде, насколько я знаю. GHC, например, поддерживает, но при выводе в stdout обрезает символ до последних 8 бит
Иначе и быть не может, так как большинство консолей воспринимает только 8 бит. Просто должен быть АПИ по управлению кодировками.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, BulatZiganshin, Вы писали:
BZ>кстати, был ещё и парсер, основанный на arrows. благодаря сойствам Arrow этот парсер действительнор генерил LR-таблицы разбора; насколько я понимаю, их подход дейстивтельно соответствовал BNF-описанию грамматики в виде eDSL с последующей генерацией кода, даром что это была библиотека: BZ>Sometimes it's useful to restrict what you can do. Duponcheel and BZ>Swierstra wrote a parser library as an Arrow; because it forced you to BZ>decide the parsing structure ahead of time, their library had enough BZ>information to build LR-type parsing tables, and thus to do yacc-style BZ>error correction. (Nobody found it useful enough to use, but it still BZ>makes a nice demonstration of why plain Arrow is sometimes better.)
Здорово. Можно по продрбнее (на пальцах)?
Конкретно:
1. Что такое Arrow?
2. Как генерируется код? Т.е. какие средства МП используются?
BZ>кстати, вот здесь — haskell.org/haskellwiki/Blog_articles/Monads собрано 42 введение в монады. не может быть, чтобы среди них не нашлось ни одного, которого тебе удастся наконец понять
Пугает как раз то что их 42. Видимо это и есть то священное значение этого числа .
BZ>что касается generic programming. SYB, который вы здесь обсуждаете — лишь один из возможных подходов. я их в своё время насчитал десяток, а ведь я в этой области совсем не специалист. из них три поставляются с самим GHC — SYB, Template Haskell, [1]. В [2] даётся краткое описание всех подходов
Ты меня извини, но Template Haskell — это как раз в чистом виде макросы. Почти аналогичные Немерловым. Template Haskell было одним из прототипов Немерла.
BZ>теперь о том, каким образом *библиотека* может в *compile-time* сгенерить код, специализированный для данного конкретного типа. на самом деле ты знаешь ответ темплейты в C++ устроены похоже на type classes в хаскеле. когда ты даёшь темплейту аргумент определённого типа, он генерит код именно для данного конкретного типа. в хаскеле type inference позволяет вообще не писать типов данных и тем не менее гшенерить типо-специфичный код
BZ>далее, для каждого контейнерного типа пишется (или генерится) несколько стандартных процедур обхода — перечисление элементов (fold), генерация (unfold) и т.д. generic-процедуры программируются через эти операции, проверки, которые можнор разрешить в compile-time, превращаются в константные выражения, в результате темплейто-подобная кодогенерация плюс стандартная оптимизация генерит эффективную type-specific процедуру
Это не верная трактовка. Шаблоны С++ не генерируют код, а обобщают его... при условии, что не используется один забавный казус — не используется способность шаблонов производить компайлтайм-вычисления появившаяся в следствии введения в шаблоны С++ возможности ручной специализации шаблона и том факте, что копилятор воспринимает ручную специализцию как признак остановки рекурсивного раскрытия шаблона.
Если мы просто создадим некий обобщенный код и создадим две специализции некой фунции, то это не будет генерацией. Того же самого можно добиться друними формами полиморфизма. Генерация же подразумевает порождение кода на базе условий и проверку этих условий во время компиляции. Заметь — это не тоже самое, что выбор специализации.
BZ>впрочем, это только один из возможных подходов. он используется в syb4 Олега Киселёва [3]. syb0 проихзводит поверки в run-time, т.е. он аналогичен использованию RTTI в ООП языках. другие же подходы (GH, [1]) просто используют специаольный язык для описания generic процедур. это можно считать специализированным языком, позволяющим компилятору сгенерить type-speciifc код как в макросистемах или RTTI-based код. отличие от макросистем в том, что во всех случаях пользователь думает в терминах одноуровневого языка, а не двух отдельных систем — прецпроцессинга и собственно выполнения
Вот уже дудки. Или мы генерируем код и думаем в терминах двух программ: метапрограммы и конечной программы (код которой и генерируется). Или у нас "одноуровневый язык". Если под "одноуровневостью" понимается исползование того же языка, то макросы пишутся на точтно таком же языке. Просто там есть пара примитивов позволяющих явно отделить генерирующий код и генерируемый.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[17]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, Gaperton, Вы писали:
G>Короче, макросы и раные там навороченные шаблоны конечно крутая штука для шифрования исходного кода и чесания левой пяткой за правым ухом, только на практике не нужная. Думаете, почему в большинстве современных языков нет макросов? В 70-х годах вот были популярны развитые макросистемы. Сейчас — нет, потому что нафиг не нужны. Рынок, так сказать, голосует.
Единственный язык в кором в 70-ые были полноценные макросы (а не уроды как в С) — это Лисп. В нем макросы есть и по сей день. Так что доказательство основывается на ложных предпосылках. Вообще очень много ложных выводов о макросах делается по схеме: "в С макросы ужасны... значит все макросы ужасны... значит маросы зло!"
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[21]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, Gaperton, Вы писали:
G>Только сразу предупреждаю — если ты макросами перформанс наигрываешь, то без профайлера я не смогу сказать, нужно оно или нет.
На этом предлагаю тему и закрыть, так как ты сам признал как минимум, что в некторых случаях они все же нужны .
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[23]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, Gaperton, Вы писали:
G>1) У тебя там применяются атрибуты. Добавление кастомных атрибутов никак не меняет синтаксис языка, и не увеличивает indirection level языковых конструкций.
Ах вот даже так? Ну, тогда хочу отрыть одну забавную тайну. Один из видов макросво в том же Немерле — это метаатрибуты. Они точно так же не меняют синтаксис языка. Другой — это простые макросы. И они не меняют синтаксис (выглядят как вызов фунции).
Так что такие макросы допустимы?
Или, не уж то, рантайм-кодогенерация которую использует IT для реализации приведенной задачи, или стоэтажные навороты на монадах Хаскеля (с неминуемвм оверхэдом) лучше? Почему не применить прямые решения для решения задачи?
Вот в C# 3.0 VB.NET и 9.0 в язык ввели DSEL под хитрым потентованным названием. Не уж то это лучше нежели ввести в язык макросы и реализовать все это на них?
G> Применение их изолировано, и локализовано. Поэтому, моя аргументация к атрибутам не относится — кастомные атрибуты являются доброй, хорошей магией. От нее вреда практически нет. По своим свойствам, влияющим на процесс разработки и поддержки — это совсем не то же самое, что злые макросы. Это безопасная штука, и мы всеми руками голосуем за кастомные атрибуты.
То есть ты голосуешь за атрибуты и против лучшего средства задания семантики для них? Зашибись!
В C# самой большой проблемой является то, что атрибуты пассивны. Нужно писать какие-то рантайм-решения котоые будут их читать и что-то делать. Та же сериализация в ХМЛ, которая к слову, была довольно удобна, дико тормозила из-за того, что при загрузке генерировала по атрибутам работчий код. Если бы она это не делала, то тормозила бы уже сериализация. В МС не придумал ничего умнее как создать ехе-шник который студия вызвает после компиляции чтобы он сгенерировал по полученным сборкам код сериализации. При этом сама реализация этого ехе-шника крайне запутана и сложна. Тоже самое на макросах пишется за пару дней и работает во время компиляции прямо в компиляторе.
G>Впрочем, добавлять их кому попало все равно надо запретить, и любую модификацию прогонять через процесс формальных инспекций с привлечением тимлидов и ведущих спецов как инспекторов, как в той ветке в управлении проектами написано — ты ее читал. Плюс, требовать адекватной документации по атрибутам — и ее тоже инспектировать.
Ага. Как в прочем кому попало не стоит доверять проектирование архитектуры ПО и т.п. Только к котегориям зла и добра это не дложно относиться.
G>2) Удобный биндинг к БД — это даже более ходовая и популярная задача, чем создание парсеров. И для ее решения, так же как ex/yacc, вполне оправдано сделать внешний макропроцессор, совсем не обязательно иметь поддержку макросов в языке.
А зачем? Да и на результаты посмотри? Лучши датабиндер до появления LINQ от MS был Кибернэйт. Но это же полная задница с точки зрения как удобства работы (описания во внешем ХМЛ), так и с точки зрения надежности (большая часть проверок в рантайме), да и быстродействие сильно хромает. LINQ тупо интегрируют в ЯП.
Ну, а ты сейчас боришся с универсальными средствами позволяющими решать не только эти, но и массу других сложных задач. Причем только на том основании, что масса задач решается и без макросов. Да кто бы спорил?!
G> Насколько я понимаю, в твоем тулките, на который ты ссылаешься, так и сделано — макросисиема там не применяется. Этой же цели, кажется, служит явский hybernate? Опять, обошлись без макросистемы. Что имеем в сухом остатке? Индустрия подверждает мой тезис о макросах, не так ли?
Ага. Вот и спроси у IT зачем от занимается отладчиком для Nemerle, а не осваивает Кибернэйм или не допиливает свое решение.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[25]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, Gaperton, Вы писали:
G>Ну мало ли, как именно аттрибуты программятся на Немерле. Атрибуты — не меняют синтаксис, и они не вредны, в отличии от макросов, меняющих синтаксис. Вещи это по убойной силе радикально разные, давай их терминологически разделим.
Ну, так спор только о синтаксических макросах?
Это уже ральная сдвижка в позиции.
G>...так объясните еще раз — зачем нужны меняющие синтаксис макросы?
Могу специально по просьбам "телезрителей" добавить в компилятор Немреля ключик запрещающий использование пользовательских синтаксических макросов. Без них макросы не сильно уменьшат свою мощь.
G>Что пользователю не все равно — так это встречать недокументированные языковые расширения самоделкиных, сделанные на каждый чих. Это — плохо. Это — убивает maintainability. А для редких случаев вполне сгодятся тулы вроде яка с лексом.
Я вот смотрю на практику и хоть убей не вижу неоправданных языковых расширений. Возможно пока что языком пользуются только размные люди. Но тода лучше говорить о средствах предотвращающий доступ к программирования для уродов и ламеров:? А?
G>Индустрия имела макросы в далеких 70-х. И отказалась от них вместе с ассемблерами и языками-монстрами вроде PL/1 — с появлением простых и понятных языков высокого уровня.
Это не те макросы. Те были только в Лиспе. В нем они есть и по сей день.
ЗЫ
И вообще, забавно наблюдать как человек всего год-два пропагандировавший ОКамлоский препроцессор вдруг стал таким рьяным борцом с макросами.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
темплейты в C++ устроены похоже на type classes в хаскеле. когда ты даёшь темплейту аргумент определённого типа, он генерит код именно для данного конкретного типа. в хаскеле type inference позволяет вообще не писать типов данных и тем не менее гшенерить типо-специфичный код
