Здравствуйте, Gaperton, Вы писали:

G>Это десять. Я привел эту цитату в подтверждение того, что макросы применялись в мэйнстриме в 70-х. У вас по существу вопроса есть что сказать? Фрэнк Дрейк и его серебро мне малоинтересно.

Есть. Почему они так и остались почти во всех ассемблерах?
Почему ты сравниваешь примитивные текстуальные макросы ранних ассемблеров с Лисп-подобными макросистемами?
Почему в том же Лиспе макросы не были отвергнуты?
Почему появились Темлэйт Хаскель, ОКамлосвский препроцессор и многие другие полноценные маросистемы?

Здравствуйте, AndrewVK, Вы писали:

AVK>К LISP паттерн-матчинг в 70 году был, манипуляция AST в нем тоже была.

Гы. В Лиспе паттерн-матчинага, да и АСТ никогда небыло. АСТ ненужно так как код пишется в S-выражения, а паттерн-матчинг довольно неуклюже эмулируется на макросах.

Ну, да Лисп это первый язык в котором били макросы (полноценные) вообще. И именно потому что в нем нет синтаксиса (АСТ по вашему) или точнее код пишется напрямую в аналоге АСТ — этот язык не был воспринят не только индустрией, но и большей частью научного сообщества. Но 90-ых бытовало мнение, что Лисп — это эдакий ДСЛ для проблемной области искуственного интелекта.

Здравствуйте, Klapaucius, Вы писали:

K>Basic — статически типизированный язык.

Первый вроде был дикамикой. Если вообще его можно навзвать полноценным ЯП.

BZ>>препроцессор pl/1 имел синтаксис, аналогичный самому pl/1

K>Ну так что? Ключевой момент то в том, что это был препроцессор. Даже очень крутой препроцессор вроде Camlp4 все равно не является макросистемой, ведь он не может получить информацию о типах — для статически типизированного языка это имеет значение.

А можно где-то почитать описание препроцессора pl/1? Чем он манипулировал?

Здравствуйте, Gaperton, Вы писали:


G>Балшыт. Макросистема не обязана уметь получать информацию о типах.

Ага. Как не обязана манипулировать АСТ, поддерживать квази-цитирование и паттерн-матчинг. Вот толькоо без всего этого она ничего не стоит, так как сделать с ее помощью на практике ничего нельзя. Хотя нет... можно. Можно угробить код, что часто и случалось в С (про pl/1 не скажу, я не так чтобы стар или суперстар, чтобы помнить этот язык).

G> Дело в том, что ее вообще может не быть, этой информации, так же как и типов.

В статически типизированном языке? Ого?

G> К примеру, макросистема в любом чисто динамическом языке...

Хароший пример . Кстати, о Лиспе. Мне тут показывали как на Лиспе из макросов в рантайме типы вытаскивали и код на ходу генерили и исполняли. 10-и этажный наворот! И все потому, что язык динамический, а типы для решения задачи ой как хочется иметь.

G> без аннотаций типов этой информации получить не может в принципе.

О как? А не ты ли мне про вывод типов в ОКамле рассказывал?

Здравствуйте, Gaperton, Вы писали:

G>Большинство были как раз динамическими — а именно — все интерпретируемые бейсики проверяли типы в динамике.

Ну, как минимум Бэйски от МС вроде бы делали проверки при разборе текста.

Здравствуйте, AndrewVK, Вы писали:

AVK>Будет.

Блин, спор интелекутульнее не придумашь.

AVK> Вот, к примеру, сиквел (возьмем SQL'92 для определенности) — динамически типизированный язык (это не значит что в нем типов нет!). Но совсем небольшой коррекции семантики и соответствующего компилятора хватает, чтобы сделать его статически типизированным. Сам язык при этом практически не меняется.

С каких пор SQL динамически типизированный? В SQL-92 определеятся синтаксис объявления типизированных таблиц, а команды SELECT, UPDATE и т.п. работают уже с типизированными данными. Все известные мне СУБД вводя расширения SQL так же заставляли декларировать типы. Ну, а то что какой-нить там сервер позволяет складывать теплое с мягким (скажем, строки с целыми), так это особенности типобезопасности, точнее ее отсуствия. Динамические привдения типов есть во многих статически типизированных языках. В том числе С++ и C#.

Здравствуйте, Gaperton, Вы писали:

K>>Вот только все "индустриальные" Бэйсики, которые позиционировались как языки общего назначения были компиляторами.

G>Ага щаз. "Индустриальные" бейсики по началу все были интерпретаторами без исключения. Компиляторы из бейсиков стали делать уже сильно позже — и эти языки бейсиками можно уже с натяжкой было назвать — это уже сильно расширенные диалекты. И то, современные "индустриальные" бейсики днамические, например Visual Basic, не путать со скриптом VBScript и встраиваемым Visual Basic for applications.

Компилируемость действительно не в кассу. Кстати Visual Basic до версии 5.0 был чистым интерпретатором. А VBA и сейчас интерпретатор. Но вот типы в Visual Basic били еще в 1.0. И задавались символами. К 4.0 появился синтаксис "DIM имя as тип". Более того и сейчас если не указывать опции вроде стрикт в васике можно объявлять переменные типа Object (нанее Variant) работа с которыми по сути ведется с помощью интерпретации (компилятор генерирует вызовы универсальных фуцний вроде VARIANT_Add().

Вот только у меня один вопрос. Причем тут макросы? У вас тема уехала, господа, любезные.

Здравствуйте, Gaperton, Вы писали:

G>Это не "эрудиция", это плохая память, коллега . Все-таки, в 31 год тяжело вспомнить детали угребищного языка, на котором писал много, но в школе. Я с тех пор настолько много чему научился, что мне не стыдно забыть $ перед строковой переменной, а смешно .

+1

G>Однако, что такое динамическая и статическая типизация я помню хорошо. Отличие между ними, мой хорошо эрудированный и плохо знающий матчасть коллега, состоит не в полиморфизме, а в том, в какой момент проверяются типы. До выполнения (статически) или во время выполнения (динамически). Все бейсики, как интерпретируемые языки, кроме некоторых исключений-компиляторов, проверяли типы в динамике... И это соврешенно не важно, что переменная $String не полиморфна. Это уже второй вопрос — ответ на который также прост — нет в бейсике составных данных и сложных структур данных — как в фортране, потому и от полиморфных переменных толку немного.

Вообще-то важно. Иначе дейсвтительно написав интерпретатор С++ или Хаскеля можно заявить, что язык динамический.

Здравствуйте, Klapaucius, Вы писали:

Орля! Спор выродился. Начался флэйм. Завязывайте вы с Васиком. Он точно до добра не доведет.

Здравствуйте, Klapaucius, Вы писали:

K>Честно говоря, принимая во внимание лисповский синтаксис и общую идеологию code is data is code, я вообще с трудом представляю, зачем в LISP нужно (квази)цитирование, как я его понимаю. И термин этот вместе с LISP вообще очень редко встречается. Но я не поленился и поискал статьи по этой теме на CiteSeer. Да, статьи по квазицитированию в LISP есть. Самая старая, что я нашел — 1999 года.

Квазицитирование в Лиспе есть. Когда родилось — не знаю, но родилось именно в нем.

Там вообще клевое цитирование одна ковычка цитирует а другая делает обратное преобразование.

А вот что касается АСТ, то там его нет. Точнее только оно и есть. Нет синтаксиса. S-выражения — это и есть АСТ, так что там не только цитирование в АСТ делалось, но и само программирвоание тоже. От чего язык и ненавдят все те, кто не любит разглядывать 3D-объекты в вэйфрэйме или скажем дома в виде артматуры.

Здравствуйте, lomeo, Вы писали:

L>Хотя к предмету спора это и имеет мало отношения.

К предмету не имеет, но информация полезная... как раз в контексте.

Здравствуйте, Gaperton, Вы писали:

G>Есть еще кое-что общее у текстовых препроцессоров и преобразований над AST, кроме названия. Сходство, которое вы, коллега, умудрились каким-то непостижимым мне образом в своем рассуждании пропустить, состоит в том, что и то и другое делает ровно одно и тоже — выполняет некоторую трансформацию кода, расширяя синтаксис и семантику базового языка.

Ага. Но с очень разными последствиями. Более того. Того же добиваются и любые другие системы метапрограммирования. Даже Яки. Да и не только системы МП. Многие выкрутасы Хаскеля по стути меняют семантику языка. Язык волшебным образом начинат мимикрировать под процессор БД или генератор парсеров. Остается вопрос... плохо ли это? Полхо ли, то что задача описывается очевидным для не обрзом, а не на эзоповом языке?


G> Делается это преобразованием над AST, вылавливанием и заменой регекспов, или как-то по другому — совершенно не важно ни для кого, кроме как разработчика макросов. А я не проблемы разработчика макросов обсуждаю — они меня мало волнуют, я обсуждаю проблемы пользователя макросов. Это второй тонкий и не очевидный момент, который, видимо, надо подробно растолковать.

Куда девалась аргументация? Чем аргументировано то, что пользоватяля не волнует тип макросов? Я вот всегда боялся С-ишных макросов не потому, что они меняют код. Именно это мне и было нужно от макросов. Это же их суть! Я боялся их потому, что в них, ну очень просто совршить ошибку которую потом, ну, очень сложно найти. Еще я недолюбливал макросы С за то, что они не позволяют мне оперировать понятиями языка, а заставляют работать с текстом. Но это исходная фича вызвающая пробшемы. А проблемы были исключительно в ошибках. В прочем была еще недостаточная гибкость, как раз проистекающая из текстуальности и отсуствия полноценных языковых конструкций вроде циклов.

K>>Короче говоря, Gaperton валит с больной головы если и не на здоровую, то, по крайней мере, на неизвестно какую.
G>Да ладно, скажите просто и честно: "я не понимаю, что и о чем пишет Гапретон, проблемы, которые он поднимает мне не понятны и не близки". Так вы, по крайней мере, избежали бы перехода на личности, плюс — точно передали бы суть дела.

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

G>Отчего же. Учитывая, что новые макросистемы делают в конечном счете то же самое, что и старые, совсем не трудно представить, какие грабли ждут энергичных "первооткрывателей" технологий 70-х годов, закрывающих глаза на здравый смысл и на опыт индустрии.

Дык не тоже самое. И как раз главно, что нет большинства тех самых граблей которые были присущи текстуальным макросистемам. Более того появилась возможность отладки макросов и фармальной проверки. Пока что проверяется только синтаксис. Но и это огромный шаг вперед. Семантика, кстати, тоже проверяется... Во время компиляции. И за счет того, что код генерирвется в виде АСТ не сложно его превратить в текст и при сообщениях об ошибках указывать на этот текст.

К сожалению, на сегодня нет ни одной доделанной системы такого типа. Именно этим и объясняются фобии подобного рода.

Здравствуйте, VladD2, Вы писали:

от тебя больше 10 сооющений и все датированы 23:58. помогают навыки профессиональной машинистки?

VD>А можно где-то почитать описание препроцессора pl/1? Чем он манипулировал?

текстовым представлением программы. помесь макросов С со средствами управления самого pl/1. вот пример, генерящий 10 строк кода:

%do i=1 to 10 do
a(i)=0
%end

почитать об этом можно в книге 78-го года: "макросредлства pl/1 представляют собой случайный набор возможностей с наложенными на них произвольными ограничениями" "...извинить его разработчиков может только то что они были чуть ли не первыми 1964 год)"

G>>Однако, что такое динамическая и статическая типизация я помню хорошо. Отличие между ними, мой хорошо эрудированный и плохо знающий матчасть коллега, состоит не в полиморфизме, а в том, в какой момент проверяются типы. До выполнения (статически) или во время выполнения (динамически).

это вопрос реализации. были интерпретаторы даже для С, с другой стороны есть lint-подобные системы для динамичсеких языков. правильное же определение — в статических языках тип переменной определяется текстом программы, в динамических — процессом исполнения. кстати ООП — это динамическая типизация, даже когда она привнесена в статические языки

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, BulatZiganshin, Вы писали:

VD>>>>Она мне нитересна, конечно. Но это только один вопрос. А их несколько. Вот в начале этого собщения мы говорим о логике постраителя парсера. Это мне тоже очень интересно. Потом интересна отладка. Да и просто поглядеть на то во что выльется грамматика интересно.

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

VD>Ясно. Ну, тогда это твое сообщение можно считать хорошим ответом на вопрос прозвучавший в этой теме ("Являются ли макросы свидетельством недостаточной выр...").

VD>Макросы позволяют решать некоторые задачи (хорошим примером является построитель парсеров):
VD>1. В компайлатайме.
VD>2. С меньшими временными затратами в рантайме.
VD>3. Обеспечивает большую гибкость (мы вольны вибирать алгоритмы и синтаксис не заморачиваясь на базовые фичи языка, ведь мы генерируем код).
VD>4. Раньше выявлять ошибки.

VD>В итоге тут просто нечго сравнивать. Несомненно если в задача с приемлемы качеством решается некой универсальной фунцией gmap, то лучше воспользоваться ею чем создавать специализированное решение на макросах. И наличие такой фунции, так же, несоменное пиремущество. Вот только это не доказательство крутости языка. Это доказательство прозорливости тех кто писал эту фунцию. Ее так же можно реализовать и с помощью макросов.

разумеется, одно другому не мешает. макросы — более универсальны, generic programming — лишь одно из их применений. речь у нас шла только о том, что некоторые задачи, которые в языках уровня C* можно решить только макросами, в хаскеле могут быть решены на языковом уровне

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

VD>Здорово. Можно по продрбнее (на пальцах)?
VD>Конкретно:
VD>1. Что такое Arrow?
VD>2. Как генерируется код? Т.е. какие средства МП используются?

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

BZ>>кстати, вот здесь — haskell.org/haskellwiki/Blog_articles/Monads

BZ>>что касается generic programming. SYB, который вы здесь обсуждаете — лишь один из возможных подходов. я их в своё время насчитал десяток, а ведь я в этой области совсем не специалист. из них три поставляются с самим GHC — SYB, Template Haskell, [1]. В [2] даётся краткое описание всех подходов

VD>Ты меня извини, но Template Haskell — это как раз в чистом виде макросы. Почти аналогичные Немерловым. Template Haskell было одним из прототипов Немерла.

да. я хочу сказать, что generic программирование в хаскеле — очень уважаемая тема, и средств для его реализации придумано немеряно — на препроцессорах, type classes, расширения языка, rtti. в общем, поручик Ржевский был бааальшой выдумщик

BZ>>теперь о том, каким образом *библиотека* может в *compile-time* сгенерить код, специализированный для данного конкретного типа
VD>Если мы просто создадим некий обобщенный код и создадим две специализции некой фунции, то это не будет генерацией. Того же самого можно добиться друними формами полиморфизма. Генерация же подразумевает порождение кода на базе условий и проверку этих условий во время компиляции. Заметь — это не тоже самое, что выбор специализации.

фишка в том, что условия, записанные в коде, могут проверяться на этапе компиляции :

if TRUE=FALSE then print "Vlad прав"

поэтому макросы, явно срабатывающие на этапе компиляции, в определённой степени заменимы на код, содержащийся в templates/type classes. имхо, на хаскеле эти границы выше, чем на C* ввиду вывода типов и наличия higher-order funcs, поэтому то, что представляется нереальным для C++ (generic programming с помощью templates), в хаскеле всё же возможно

вот тебе для примера код, печатающий тип значения:

class Type a where
  typeof :: a -> String
instance Type String where
  typeof _ = "String"
instance Type Int where
  typeof _ = "Int"
instance (Type a) => Type [a] where
  typeof x = "["++typeof (head x)++"]"
instance (Type a, Type b) => Type (a,b) where
  typeof (x,y) = "("++typeof x++","++typeof y++")"
main = print$ typeof ("",("",[""]))

кстати, описываемый в [1] подход вообще весьма примечателен — фишка в том, что любой Algebraic Data Type можно построить из базовых примененим всего двух операций — выбора из двух альтернатив и декартова произведения. соответственно, если мы определим процедуру в терминах этих двух операций (и представим реализацию base cases), то её можно будет применить к любому типу! к примеру, сериализация:

{a :+: b} a = putBit 0 >> put a
{a :+: b} b = putBit 1 >> put b
{a :*: b} = put a >> put b



BZ>>впрочем, это только один из возможных подходов. он используется в syb4 Олега Киселёва [3]. syb0 проихзводит поверки в run-time, т.е. он аналогичен использованию RTTI в ООП языках. другие же подходы (GH, [1]) просто используют специаольный язык для описания generic процедур. это можно считать специализированным языком, позволяющим компилятору сгенерить type-speciifc код как в макросистемах или RTTI-based код. отличие от макросистем в том, что во всех случаях пользователь думает в терминах одноуровневого языка, а не двух отдельных систем — прецпроцессинга и собственно выполнения

VD>Вот уже дудки. Или мы генерируем код и думаем в терминах двух программ: метапрограммы и конечной программы (код которой и генерируется). Или у нас "одноуровневый язык". Если под "одноуровневостью" понимается исползование того же языка, то макросы пишутся на точтно таком же языке. Просто там есть пара примитивов позволяющих явно отделить генерирующий код и генерируемый.

VD>>А вот извороты вроде Хаскелевских всегда будут сопровождаться коментариями вроде (ну, вот все замечательно только А кривовато, а Б медленновато, а С зависит от компилятора и направления ветра). Реализация разны магических фунций вроде gmap опять же отличное поле для макросов. В итоге мы получим и там, и там фунцию gmap, которую внешне нельзя будет отличить. Но в одном случае ее смогут создать только создатели компилятора, а в друго любой смертный. Думаю не надо объяснять почему путь макросов лучше?

L>gmap может создать любой смертный. Средствами по мне более простыми нежели макросы.

с интеллектом в 1000 миллиОлегов как раз syb4.hs, ссылку на который я давал — это реализаций generic программирования в compile time , которую не сможет понять ни один смертный

BZ>>>впрочем, это только один из возможных подходов. он используется в syb4 Олега Киселёва [3]. syb0 проихзводит поверки в run-time, т.е. он аналогичен использованию RTTI в ООП языках. другие же подходы (GH, [1]) просто используют специаольный язык для описания generic процедур. это можно считать специализированным языком, позволяющим компилятору сгенерить type-speciifc код как в макросистемах или RTTI-based код. отличие от макросистем в том, что во всех случаях пользователь думает в терминах одноуровневого языка, а не двух отдельных систем — прецпроцессинга и собственно выполнения

VD>>Вот уже дудки. Или мы генерируем код и думаем в терминах двух программ: метапрограммы и конечной программы (код которой и генерируется). Или у нас "одноуровневый язык". Если под "одноуровневостью" понимается исползование того же языка, то макросы пишутся на точтно таком же языке. Просто там есть пара примитивов позволяющих явно отделить генерирующий код и генерируемый.

блин, хотел ответить и на это, но уже запечатал конверт

так вот, описание констант или темплейтов в C++ тоже можно считать средставми макроподстановки и генерации кода. тем не менее это средства, которые сингтегрированы в сам язык, и никто их не отделяет от "обычной" порграммы. точно также и средства generic программирования — интерес состоит как раз в том, чтобы они являлись естественной составной частью языка наравне с остальными средствами, а не отдельным преобразованием, которое застваляет пользователя и разработчика держать в голове два уровня программы и отслеживать ошибки, которые можно понять только на уровне странслированного кода, а ля:

#define e 2.78 // основание натуральных логарифмов

в приведённом мною примере никакой метапрограммы нет. просто код написан так, что значение функции известно уже на этапе компиляции. в generic programming тем или иным путём производится обход структуры данных — никакиъ "метапорграмм"

Здравствуйте, BulatZiganshin, Вы писали:

BZ>от тебя больше 10 сооющений и все датированы 23:58. помогают навыки профессиональной машинистки?