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

VD>>Ну, а то что ты продемонстрировал никак не тянет на реальную типизацию паттернов.
WH>Просто ты не понял что это.

Короче, мне эти приперательства надоели. Предлагаю поступить следующим образом. Создай прототип своего типизатора паттернов (как более-менее обособленной задачи) в виде макроса Н1. Там вся нужная инфраструктура есть. Все остальное навернешь сверху. Я тебя могу проконсультировать по деталям типизации Н1. В общем, как с ПегГраммаром.

Будет, код — будет на что смотреть и что обсуждать.

Макры Н1 пашут во время типизации. Так что это позволяется вклиниться в процесс типизации. В них можно узнать все типы окружающих выражений.

Там ты покажешь во что все это выльется. Задача очень проса — получить в итоге аналог типизатора паттернов Н1, но в виде макроса. На входе будет код match-а, а на выходе должен быть класс Match_case:

  [Record]
  public class Match_case
  {
    public mutable patterns : list [Pattern * TExpr * list [LocalValue * TExpr]];
    public mutable body : TExpr;
    public mutable disable_warnings : bool;
  }

Вот на этом примере ты и покажешь все части (типизацию, понижение/переписывание, генерация сообщений об ошибках и т.п.).

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

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

VD>довольно наивны.
Их "наивность" происходит из того что ты ничего не понял.
Одно то, что ты путаешь тип паттерна с TAST паттерна говорит о том, как ты "пытаешься" понять.
Заметь, ты не сказал "зачем" ты сразу сказал "не нужно".

VD>Так что, в моем лице, видишь как раз видишь единственного читателя кто тебя пытается понять. И вместо того чтобы все время переходить на обсуждение моей личности тебе бы стоило бы поискать бревно в своем глазу.
А может ты вместо того чтобы кричать "не нужно" подумаешь зачем я ввел тип паттерна?
Почему я постоянно говорю, что типизация это часть синтаксического анализа?
...

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

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

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

VD>Короче, мне эти приперательства надоели. Предлагаю поступить следующим образом. Создай прототип своего типизатора паттернов (как более-менее обособленной задачи) в виде макроса Н1. Там вся нужная инфраструктура есть. Все остальное навернешь сверху. Я тебя могу проконсультировать по деталям типизации Н1. В общем, как с ПегГраммаром.

Писать то во что раскрывается мой ДСЛ руками я не буду. Ибо это всё равно, что тот код, который генерируется PegGrammar руками долбить.

VD>Макры Н1 пашут во время типизации. Так что это позволяется вклиниться в процесс типизации. В них можно узнать все типы окружающих выражений.
И это плохо.
Это смешение слоёв. Ребята смешали синтаксис и семантику. А ты вместо того чтобы исправить этот бардак настаиваешь на том чтобы я его повторил.
Это типа как вместо MVVM писать SQL запросы в обработчике события кнопки.
Вроде работает но по факту поддерживать невозможно.

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

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

VD>А, ну, да. Сделал магическую функцию которая виртуально делает все что надо и типа решил задачу.
И что в RewriteForeachBody магического?
Она генерирует код, который ждет, что будет локальная переменная item в которой лежит текущее значение.

VD>Я так и не увидел полноценного анализа реализации паттерна перечислитель. Только в нем будет штуки 3 сообщения об ошибке.
Тебе ещё сколько раз повторить, чтобы ты, наконец, понял, что его не будет, пока не будет поиска имен?

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

WH>Писать то во что раскрывается мой ДСЛ руками я не буду. Ибо это всё равно, что тот код, который генерируется PegGrammar руками долбить.

Пиши не руками. Вся сила макросов и т.п. в твоих руках.
Пустые слова надоели.

VD>>Макры Н1 пашут во время типизации. Так что это позволяется вклиниться в процесс типизации. В них можно узнать все типы окружающих выражений.
WH>И это плохо.
WH>Это смешение слоёв...

Да ты достало своей пропагандой. Отвлекись о нее. Для целей создания прототипа это то что нужно. Ты из своей макры сможешь достать АПИ типизации и построить на его базе свой ДСЛ (в сто раз проще нежели писать с нуля).

Просто смотри на на это как на прототип который принципиально пойдет в помойку.

WH>Ребята смешали синтаксис и семантику.

Этим ты тоже достал. Твои воззрения на синтаксис и семантику воспринимаешь нормально только ты один.

Смешали типизацию и генерацию код — да, пожалуй. Ну, дык и покажи что будет, всли все сделать правильно.

WH> А ты вместо того чтобы исправить этот бардак настаиваешь на том чтобы я его повторил.

Там слишком много бардака чтобы все исправлять. А код работает корректно. Я в отличии тебя много чего делаю, а не только лясы точу. И мой план забит еще на пару месяцев.

WH>Это типа как вместо MVVM писать SQL запросы в обработчике события кнопки.

Возможно. Вот и докажи это делом — напиши прототип который все смогут пощупать.

WH>Вроде работает но по факту поддерживать невозможно.

Твой код тоже кроме тебя мало кто поддерживать может.

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

А кому нужны игрушки? Да и писать ты свой прототип с нуля будешь пару лет. Ты вот уже 4 месяца никак расширяемость не прикрутишь к парсеру. А тут задача явно по объемнее будет.

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

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

VD>>А, ну, да. Сделал магическую функцию которая виртуально делает все что надо и типа решил задачу.
WH>И что в RewriteForeachBody магического?

VarFromPattern или как она там у тебя называлась?

VD>>Я так и не увидел полноценного анализа реализации паттерна перечислитель. Только в нем будет штуки 3 сообщения об ошибке.
WH>Тебе ещё сколько раз повторить, чтобы ты, наконец, понял, что его не будет, пока не будет поиска имен?

Ну, значит и говорить пока не о чем.

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

VD>Да ты достало своей пропагандой. Отвлекись о нее. Для целей создания прототипа это то что нужно. Ты из своей макры сможешь достать АПИ типизации и построить на его базе свой ДСЛ (в сто раз проще нежели писать с нуля).
Я не могу использовать типизатор немерле.
Он просто не совместим с тем, что делаю я.
Я на борьбу с другим подходом потрачу больше времени, чем на реализацию самой идеи.

VD>Просто смотри на на это как на прототип который принципиально пойдет в помойку.
Дадада. И потом гляди на ту гору кода, которая получилась при борьбе с АПИ немерла ты скажешь "Я же говорил что твой подход фигня!".

VD>Этим ты тоже достал. Твои воззрения на синтаксис и семантику воспринимаешь нормально только ты один.
Не только.
Люди, которые копали вопрос действительно глубоко, все как один со мной согласны.
Не надо молиться на дракона. Он хармфул.

VD>Там слишком много бардака чтобы все исправлять. А код работает корректно. Я в отличии тебя много чего делаю, а не только лясы точу. И мой план забит еще на пару месяцев.
И разве это повод перенести бардак в новую версию, которая делается с нуля?

VD>Твой код тоже кроме тебя мало кто поддерживать может.
Да ладно. Хардкейс без проблем вставляет, что ему нужно.
И я на него не ругаюсь, ибо грамотно вставляет. За ним ничего подчищать не приходится.

VD>А кому нужны игрушки? Да и писать ты свой прототип с нуля будешь пару лет. Ты вот уже 4 месяца никак расширяемость не прикрутишь к парсеру. А тут задача явно по объемнее будет.
Я ее просто не пишу.
Мотивации нет. Совсем.
А так как этот прототип без расширяемости не взлетит то я и ее заодно сделаю.

VD>В макросе же ты мог бы получить готовый движок унифицации типов учитывающий подтипы и т.п.
Тоже мне рокетсайнс.

VD>Плюс весь парсинг за тебя уже сделан будет.
Немерловый парсер пусть идет лесом. Это ужОс-ужОс. Я с ним работать не хочу. Совсем.

VD>Ну, а главное, что результат твоей работы будет передаваться реальному компилятору и его можно будет опробовать на практике. Возможно даже заменить им тот код что есть сейчас.
Не взлетит. Другая философия.

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

VD>VarFromPattern или как она там у тебя называлась?
Тип паттерна (ага тот самый, которого типа нет ) это список пар имя и тип.
Что сложного в том чтобы превратить такие пары в переменные?

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

Я, конечно, не копенгаген в этих ваших высоких материях. Сужу только на основании прочитанного из вашей дружественной беседы.
На сколько я понял, твой подход заключается в том, что должен быть базовый язык, для которого реализован типизатор и кодогенераторы под разные платформы. Плюс будут макросы, разворачивающиеся в этот базовый язык (и\или меняющие куски AST). Если кому-то захочется написать свой DSL или вообще свой отдельный язык, ему нужно просто написать макрос(ы)-транслятор(ы), преобразующие этот язык в AST базового языка. После этого он автоматом получит возможность компилировать программы, причем под различные платформы и т.п. Так?

Подход WH, на сколько я понял — это сделать настоящий парсер подмножества КЗ языков, покрывающее, по крайней мере, строготипизированные языки программирования. Обычный подход — это для КЗ языка программирования выделить КС-ный надъязык, реализовать для него парсер с построением AST и следующим этапом уже вручную пройтись по полученному AST, достраивая "семантические" связи, расставляя типы и выявляя ошибки, которые не смог отловить парсер. Под "семантикой" тут подразумевается как раз та часть языка, которая не покрывается грамматикой используемого в данном конкретном случае КС-ного надъязыка.
Если же делать "настоящий" парсер, разбирающий КЗ язык программирования, то в этом втором этапе надобность отпадает. Но в таком подходе типы выражений становятся сущностями этапа парсинга и они должны задаваться прямо как часть грамматики, что и пытается сделать WH (если я в чем-то не прав — скажите, плиз). Затея выглядит очень амбициозно. В таком подходе базовый язык, в который все транслируется, необязателен. Если и делать такой базовый язык, то он будет описан теми же средствами, что используются при определении макросов (а вообще, ими и исчерпываться). Отдельный типизатор тоже не нужен, т.к. сам он будет описан на том-же mercury-подобном языке и будет децентрализован и "размазан" по определениям макросов. Добавляя новый макрос и задавая правила его типизации мы тем самым разширяем "общий" типизатор этими правилами. Весь язык будет состоять из макросов, включающих в свое определение и правила типизации. Предлагать использовать существующий типизатор N1 для проверки концепции, заключающейся в том, чтобы не использовать внешний базовый язык и его типизатор несколько нелогично...

Вот

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

A>На сколько я понял, твой подход заключается в том, что должен быть базовый язык, для которого реализован типизатор и кодогенераторы под разные платформы. Плюс будут макросы, разворачивающиеся в этот базовый язык (и\или меняющие куски AST). Если кому-то захочется написать свой DSL или вообще свой отдельный язык, ему нужно просто написать макрос(ы)-транслятор(ы), преобразующие этот язык в AST базового языка. После этого он автоматом получит возможность компилировать программы, причем под различные платформы и т.п. Так?

Так.

A>Подход WH, на сколько я понял — это сделать настоящий парсер подмножества КЗ языков, покрывающее, по крайней мере, строготипизированные языки программирования. Обычный подход — это для КЗ языка программирования выделить КС-ный надъязык, реализовать для него парсер с построением AST и следующим этапом уже вручную пройтись по полученному AST, достраивая "семантические" связи, расставляя типы и выявляя ошибки, которые не смог отловить парсер. Под "семантикой" тут подразумевается как раз та часть языка, которая не покрывается грамматикой используемого в данном конкретном случае КС-ного надъязыка.

Не савсем. Рассказы про КС-парсеры — это скажем так — пиар.

На самом деле вся разница между нашими подходами заключается только в том допускается ли преобразование нетипизированного АСТ или нет. В планах WH точно так же есть КС-парсер который выдает на выходе нетипизированное АСТ.

WH предлагает сделать то что не сделано у других — кроме генерируемого (но расширяемого) парсера он предлагает сделать генерируемый и расширяемый типизатора. И вот тандем парсера и типизатора он и называет КЗ-парсером (точнее не называет, а подразумевает, так как в слух он это не произносил).

Собственно я целиком и полностью за то чтобы автоматизировать и стандартизировать то что все не прогрессивное человечество (на зло Вольфхануду) называет семантическим анализом. И с идеей создания DSL-я типизации и разрешения имен я тоже целиком и полностью согласен. Это снимает оставшиеся вопросы которые я и сам предъявлял к своей идее.

A>Если же делать "настоящий" парсер, разбирающий КЗ язык программирования, то в этом втором этапе надобность отпадает. Но в таком подходе типы выражений становятся сущностями этапа парсинга и они должны задаваться прямо как часть грамматики, что и пытается сделать WH (если я в чем-то не прав — скажите, плиз). Затея выглядит очень амбициозно.

Да нет. Все в сто раз проще. Хотя затея и правда амбициозная. Другие нас не интересуют .
Про КЗ-языки — это WH тереотезировал. Просто по сути если типизация автоматизировна, то можно рассматривать это дело как КЗ-парсер. Так что это просто терминологический вопрос.

A>В таком подходе базовый язык, в который все транслируется, необязателен.

Базовый язык все равно будет. Вопрос только как его делать. Вручную или на базе все того же средства.

Идея лепить все с нуля для каждого языка — это заранее провальная идея.

A>Если и делать такой базовый язык, то он будет описан теми же средствами, что используются при определении макросов (а вообще, ими и исчерпываться).

Ну, дык, а почему нет то? Конечно его же средствами. Только он будет стандартизирован, полон, оттестирован и т.п. А уж то что я называю TAST — это вообще типизированный ассемблер. Его задача только быть моделью для генераторов кода.

A>Отдельный типизатор тоже не нужен, т.к. сам он будет описан на том-же mercury-подобном языке и будет децентрализован и "размазан" по определениям макросов.

Ну, в общем-то — да. Ели принять идею генерации кода типизацтора по ДСЛ (а она мне нравится), то код типизатора будет размазан по отдельным макрам.

Ну, да в этом ничего плохого нет. Я исходно планировал делать типизатор расширяемым. Если он будет расширяться незаметно, то это даже лучше.

A>Добавляя новый макрос и задавая правила его типизации мы тем самым разширяем "общий" типизатор этими правилами.

Ну, да. Как-то так. Если прокатит, конечно.

A>Весь язык будет состоять из макросов, включающих в свое определение и правила типизации.

Ну, вот если сюда добавить, а точнее оставить, возможность делать нетипизированные преобразования (и что важнее, частично типизированные). И если так же ввести понятие базового языка (возможно неодного), то получится очень близко к тому что хочу в итоге получить я.

И главное, что это никак не конфликтует с идеями которые высказал WH, но при этом устраняет пробелы которые были в концепции изначально выдвинутой мной.

A>Предлагать использовать существующий типизатор N1 для проверки концепции, заключающейся в том, чтобы не использовать внешний базовый язык и его типизатор несколько нелогично...

Это тебе так кажется, потому что ты, видимо, плохо знаком с его устройством.

Для проверки концепций достаточно создать маленький кусочек. Но чтобы его создать нужно сделать кучу побочной работы. Тот же "специализированный Меркури" включает в себя довольно много сложного кода большая часть которого есть в Н1. Это, в первую очередь, движок унификации который позволит унифицировать не просто термы (как в прологоподобных языках вроде Меркури), а типы с поддержкой подтипов. Это не маленький такой (и не самый простой) код. Только на его отдадку можно убить несколько месяцев. А на базе солвера из Н1 его можно создать очень быстро и просто. Он, конечно, будет далек от идеала по производительности, но для прототипа этого и не надо.

Если посмотреть на задачу абстрактно, то по сути тайпер будет в любом случае. Только в одном случае он размещен в одном классе и использует внешнее АСТ, а в другом его код размазан по "определению АСТ" (макросам) и описан на специальном ДСЛ-е.

Так вот если наш прототип должен продемонстрировать решение небольшой подзадачи (например, типизацию тех же паттернов), то для его реального тестирования нужно иметь реальную среду. Типизатор Н1 и будет этой средой. Просто его часть будет заменена на новый концепт.

А вот писать прототип с нуля — это очень опасное занятие. Энтузиазм имеет особенность уменьшаться обратно пропорционально размеру задачи. И запалу может просто не хватить. А амбициозные идеи они никому не нужны. Нужны амбициозные реализации.

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

VD>Не савсем. Рассказы про КС-парсеры — это скажем так — пиар.
Это скажем так факты, основанные на теории формальных языков из которых вся терминология и пошла.

VD>На самом деле вся разница между нашими подходами заключается только в том допускается ли преобразование нетипизированного АСТ или нет. В планах WH точно так же есть КС-парсер который выдает на выходе нетипизированное АСТ.
Никакой он не КС.
С одной стороны он не поддерживает неоднозначные грамматики. Те слабее КС.
С другой стороны он поддерживает некоторое подмножество КЗ. Те сильнее КС.
А если его научить пользоваться таблицами имен то...

VD>WH предлагает сделать то что не сделано у других — кроме генерируемого (но расширяемого) парсера он предлагает сделать генерируемый и расширяемый типизатора. И вот тандем парсера и типизатора он и называет КЗ-парсером (точнее не называет, а подразумевает, так как в слух он это не произносил).
Я называю его синтаксическим анализатором.
Ибо если опираться на базовую терминологию это именно он и есть.
А дракона в печку.

VD>Базовый язык все равно будет. Вопрос только как его делать. Вручную или на базе все того же средства.
Один базовый язык на все случаи жизни не возможен теоритически.

VD>Идея лепить все с нуля для каждого языка — это заранее провальная идея.
А я ни разу не предлагал лепить с нуля.
Наоборот я с самого начала предлагал делать иерархию языков.

VD>Ну, вот если сюда добавить, а точнее оставить, возможность делать нетипизированные преобразования (и что важнее, частично типизированные).
Понеслась... это как запросы к базе в обработчике нажатия на кнопку.
Вроде работает.
На мелких примерах даже короче.
Но выливается в такой геморрой
А если одновременно использовать MVVM и пихать бизнес логику примо во вьюхи то будет полная феерия.
Именно такой абсурд ты предлагаешь.
Ибо мешать синтаксический анализ и кодогенерацию это тоже самое, что мешать вьюхи с бизнес логикой.

VD>И если так же ввести понятие базового языка (возможно неодного), то получится очень близко к тому что хочу в итоге получить я.
О как?!
Уже не одного.
Так ты же через базовый язык все собрался типизировать.
Или как?
И как ты собрался в таком случае некий ДСЛ транслировать в разные бызовые языки?

A>>Предлагать использовать существующий типизатор N1 для проверки концепции, заключающейся в том, чтобы не использовать внешний базовый язык и его типизатор несколько нелогично...
VD>Это тебе так кажется, потому что ты, видимо, плохо знаком с его устройством.
Это ты ни слова не понял из того что я сказал.

VD>Это не маленький такой (и не самый простой) код. Только на его отдадку можно убить несколько месяцев. А на базе солвера из Н1 его можно создать очень быстро и просто. Он, конечно, будет далек от идеала по производительности, но для прототипа этого и не надо.
Это по тому, что он написан руками.
А я собрался его генерировать.
Тут точно как с парсером.
Писать его руками озвереешь. А PegGrammar все сделает на раз.

Кстати заметь: artelk все понял правильно. Так что тут дело в тебе.

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

A>Подход WH, на сколько я понял — это сделать настоящий парсер подмножества КЗ языков,
Синтаксический анализатор.

A>покрывающее, по крайней мере, строготипизированные языки программирования.
Что такое строготипизированные языки программирования я так и не понял.
Это слишком мутный термин.

A>Обычный подход — это для КЗ языка программирования выделить КС-ный надъязык, реализовать для него парсер с построением AST и следующим этапом уже вручную пройтись по полученному AST, достраивая "семантические" связи, расставляя типы и выявляя ошибки, которые не смог отловить парсер. Под "семантикой" тут подразумевается как раз та часть языка, которая не покрывается грамматикой используемого в данном конкретном случае КС-ного надъязыка.
Использовать слово "семантика" в данном случае не верно.
Ибо семантика языка задает смысл каждой строки языка.
А это все проверки на то принадлежит ли строка языку. Те синтаксис.
Но Влад верит, что КС грамматика задает сам язык. То, что она задает не язык, а надмножество языка он не понимает.

Остальное правильно.

WH>Ибо семантика языка задает смысл каждой строки языка.
WH>А это все проверки на то принадлежит ли строка языку. Те синтаксис.
WH>Но Влад верит, что КС грамматика задает сам язык. То, что она задает не язык, а надмножество языка он не понимает.
Какая разница как все называть, если реализация от этого не изменится.
Да и если все ошибки которые выдает компилятор на синтаксические конструкции, называть синтаксическими, и ответом на вопрос принадлежит ли строка языку.
Тогда получится что язык C# и его компилятор недетерминированны (или почти) — т.е. ошибка может выскочить а может и не выскочить, как повезет.
Сомневаюсь что кто-то может ответить на вопрос(не исполняя части кода) — "Выскочит ли ошибка компиляции на таком коде" ?

const int Original = 4;
const double             
    N2 = 0.1,
    N3 = 3.5;
const int N = (int)(( (Original+N2)*N3 - N2*N3) / N3);        
                
int Func()
{
    if (N == Original)
       return 0;
}

А если с таким значением? : const int Original = 2;
Здесь можно это выражение редуцировать в аналитическом виде , а почему бы и нет? Получается N==Original
Если вычислять численно, то результат зависит от погрешностей в арифметическом процессоре (от деталей его реализации)

Так это комиилятор C# синтаксическую ошибку, либо выдает либо не выдает(как повезет), или уже семантическую?

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

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

A>>Подход WH, на сколько я понял — это сделать настоящий парсер подмножества КЗ языков,
WH>Синтаксический анализатор.
Википедия говорит, что это синонимы...

A>>покрывающее, по крайней мере, строготипизированные языки программирования.
WH>Что такое строготипизированные языки программирования я так и не понял.
WH>Это слишком мутный термин.
А если убрать это слово, станет ли предложение верным?
Есть ли какие-нибудь органичения на то, какие языки можно выразить этим подходом?
Можно ли будет, например, сделать C++, OCaml, Scala, J и что-нибудь с зависимыми типами?

A>>Обычный подход — это для КЗ языка программирования выделить КС-ный надъязык, реализовать для него парсер с построением AST и следующим этапом уже вручную пройтись по полученному AST, достраивая "семантические" связи, расставляя типы и выявляя ошибки, которые не смог отловить парсер. Под "семантикой" тут подразумевается как раз та часть языка, которая не покрывается грамматикой используемого в данном конкретном случае КС-ного надъязыка.
WH>Использовать слово "семантика" в данном случае не верно.
WH>Ибо семантика языка задает смысл каждой строки языка.
"Смысл" — еще менее формализованное понятие. Имхо, все что сложнее терминалов — уже некоторым образом семантика. Например, идентификатор состоит из символов, т.е. семантикой этого набора символов является то, то он является идентификатором (более высокоуровневой конструкцией). Т.е. семантика — понятие относительное, в том смысле, что оно определяется относительно уровня абстракции, с которым мы в данный момент работаем. Все что ниже этого уровня можно обозначить как "дано", а выше — более высокоуровневые абстракции и связи между элементами нижнего уровня — семантика.
1. Лексеру (если он есть) на вход подаются символы, на выходе получаем токены — первый слой абстракции со своей семантикой.
2. Парсеру (если он КС) подаются токены, на выходе получаем AST — второй слой.
3. Далее рукопашный код, который сужает объем KC языка до спецификации целевого языка — третий слой со своими абстракциями (типами, перегрузками и т.п.)
4. Потом кодогенератор как отдельный слой...
Другое дело, что первые три слоя не всегда удачно разделяются (без хаков и прямых модификаций того, что приходит из нижних уровней). Если ты предлагаешь другую, более удачную декомпозицию на слои с инкапсуляцией рутинных вещей в красивый DLS — это очень интересно!

WH>Ибо семантика языка задает смысл каждой строки языка.
Ну да, на каждом уровне происходит трансформация "предложений" "языка" нижнего уровня в язык верхнего, тем самым "обеспечивая" их семантикой.

WH>А это все проверки на то принадлежит ли строка языку. Те синтаксис.
WH>Но Влад верит, что КС грамматика задает сам язык. То, что она задает не язык, а надмножество языка он не понимает.
Надмножество языка — тоже язык. Думаю, он просто опасается, что первые три уровня смешаются в одну большую кучу неподдерживаемого кода. Или что DSL для ее разруливания будет слишком сложным для простых смертных. Похожие мотивы и у тебя, когда ты борешься с распространенным пониманием термина "семантика" — чтобы никому даже в голову не приходило смешивать этот уровень с кодогенерацией, так?

Кстати, а нельзя ли саму кодогенерацию посадить на тот же движек? У макросов есть rewrite часть, которая трансформирует элемент более высокоуровневого языка в термины более низкоуровневого. А чем MSIL или машинный код не языки?! Если позволить макросу иметь несколько rewrite частей и выбирать нужную в зависимости от текущей платформы, текущего "базового" языка или какого-то промежуточного, то будем иметь дополнительную гибкость повторного использования кода. Нужно только как-то предотвратить перескакивание через языки — чтобы не позволить писать на Nemerle вперемежку с MSIL. Еще могут быть неоднозначности по какому пути идти от самого верхнего уровня к MSIL.

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

S_S>Какая разница как все называть, если реализация от этого не изменится.
Проблема в том что меняется.

S_S>Тогда получится что язык C# и его компилятор недетерминированны (или почти) — т.е. ошибка может выскочить а может и не выскочить, как повезет.
Я еще не видел ни одного языка синтаксис, которого был бы основан на генераторе случайных чисел.

S_S>Так это комиилятор C# синтаксическую ошибку, либо выдает либо не выдает(как повезет), или уже семантическую?
Семантических ошибок не бывает.
Ибо семантика задана для всех строк принадлежащих языку.

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

A>Википедия говорит, что это синонимы...
Мало ли что она говорит.

A>Есть ли какие-нибудь органичения на то, какие языки можно выразить этим подходом?
Думаю что любые.

A>Можно ли будет, например, сделать C++,
В первых версях нет. Ибо для С++ нужны дополнительные навороты (интеграция парсера с поиском имен), которые я буду делать потом.
Примеры ужоса:

a<b>c;
a*b;

Не заная что из себя представляют имена вменяемый АСТ не построить.

A>OCaml, Scala, J и что-нибудь с зависимыми типами?
Нивапрос.

A>"Смысл" — еще менее формализованное понятие. Имхо, все что сложнее терминалов — уже некоторым образом семантика.
Например в ПЕГе нет никаких терминалов. Так что вся твоя терминология строится на деталях реализации.
А должно быть наоборот.

A>1. Лексеру (если он есть) на вход подаются символы, на выходе получаем токены — первый слой абстракции со своей семантикой.
A>2. Парсеру (если он КС) подаются токены, на выходе получаем AST — второй слой.
A>3. Далее рукопашный код, который сужает объем KC языка до спецификации целевого языка — третий слой со своими абстракциями (типами, перегрузками и т.п.)
Вот это все синтаксический анализ.

A>Другое дело, что первые три слоя не всегда удачно разделяются (без хаков и прямых модификаций того, что приходит из нижних уровней).
А знаешь почему?
По тому, что это не три слоя, а один!

A>Ну да, на каждом уровне происходит трансформация "предложений" "языка" нижнего уровня в язык верхнего, тем самым "обеспечивая" их семантикой.
Это происходит на этапе кодогенерации. Те после того как синтаксический анализ завершён.

A>Надмножество языка — тоже язык.
Да. Но это другой язык.

A>Думаю, он просто опасается, что первые три уровня смешаются в одну большую кучу неподдерживаемого кода.
Нет. Он просто не понимает, что если в языке есть требования "объявить перед использованием" то язык КЗ.
Доказано математически.

A>Или что DSL для ее разруливания будет слишком сложным для простых смертных. Похожие мотивы и у тебя, когда ты борешься с распространенным пониманием термина "семантика" — чтобы никому даже в голову не приходило смешивать этот уровень с кодогенерацией, так?
Нет.
Это всего лишь одно из пагубных следствий противоречивой терминологии.
Мне эта терминология не понравилась сразу. Меня сразу смутила зависимость терминологии от деталей реализации.
Но аргументы против появились только через некоторое время.

A>Кстати, а нельзя ли саму кодогенерацию посадить на тот же движек? У макросов есть rewrite часть, которая трансформирует элемент более высокоуровневого языка в термины более низкоуровневого. А чем MSIL или машинный код не языки?!
Правильно соображаешь.
Вот только Влад это не понимает.

A>Если позволить макросу иметь несколько rewrite частей и выбирать нужную в зависимости от текущей платформы, текущего "базового" языка или какого-то промежуточного, то будем иметь дополнительную гибкость повторного использования кода. Нужно только как-то предотвратить перескакивание через языки — чтобы не позволить писать на Nemerle вперемежку с MSIL. Еще могут быть неоднозначности по какому пути идти от самого верхнего уровня к MSIL.
Об этом я тоже думаю.

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

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

A>>Википедия говорит, что это синонимы...
WH>Мало ли что она говорит.
Хорошо, а чем тогда они отличаются?

A>>Есть ли какие-нибудь органичения на то, какие языки можно выразить этим подходом?
WH>Думаю что любые.
Крута

A>>"Смысл" — еще менее формализованное понятие. Имхо, все что сложнее терминалов — уже некоторым образом семантика.
WH>Например в ПЕГе нет никаких терминалов. Так что вся твоя терминология строится на деталях реализации.
Вроде как есть.

A>>1. Лексеру (если он есть) на вход подаются символы, на выходе получаем токены — первый слой абстракции со своей семантикой.
A>>2. Парсеру (если он КС) подаются токены, на выходе получаем AST — второй слой.
A>>3. Далее рукопашный код, который сужает объем KC языка до спецификации целевого языка — третий слой со своими абстракциями (типами, перегрузками и т.п.)
WH>Вот это все синтаксический анализ.
Ок.

A>>Другое дело, что первые три слоя не всегда удачно разделяются (без хаков и прямых модификаций того, что приходит из нижних уровней).
WH>А знаешь почему?
WH>По тому, что это не три слоя, а один!
Строго-научно да. Но, с точки зрения практики, такое разбиение все равно целесообразно проводить и оно чаще всего приводило к заметному упрощению кода, не так ли? Хотя бы потому, что первые два слоя относительно легко посадить на геренатор парсера, а с третьим в этом смысле сложнее. Вот паттерны проектирования, например, далеко не точная наука. Однако это не значит, что реализацию не нужно разбивать на множество простых и слабосвязанных частей, если это не обоснованно строго-научно.

A>>Ну да, на каждом уровне происходит трансформация "предложений" "языка" нижнего уровня в язык верхнего, тем самым "обеспечивая" их семантикой.
WH>Это происходит на этапе кодогенерации. Те после того как синтаксический анализ завершён.
Если язык удобно представить в виде "матрешки" (например: наднадъязык, надъязык и собственно язык), то семантика будет появляться при каждом переходе от внешнего языка к более детальному внутреннему, имхо.
Не понятно, почему ты считаешь кодогенерацию семантикой. Вроде это как раз тупое переписывание высокоуровневых элементов в другой, более низкоуровневый язык. Тут семантика как раз пропадает...
Или же оптимизация это семантика?

A>>Если позволить макросу иметь несколько rewrite частей и выбирать нужную в зависимости от текущей платформы, текущего "базового" языка или какого-то промежуточного, то будем иметь дополнительную гибкость повторного использования кода. Нужно только как-то предотвратить перескакивание через языки — чтобы не позволить писать на Nemerle вперемежку с MSIL. Еще могут быть неоднозначности по какому пути идти от самого верхнего уровня к MSIL.
WH>Об этом я тоже думаю.

Родилось такое:

syntax "if" of Nemerle
//многа ДСЛя
typing
//многа ДСЛя

//отдельно
rewrite "if" of Nemerle to Nemerle
{
  //тут только код на Nemerle и\или на языке, который в него транслируется
  match(...)
   ...
}

syntax "match" of Nemerle
//многа ядреного ДСЛя
typing
//многа ядреного ДСЛя

//отдельно
rewrite "match" of Nemerle to MSIL
{
  //тут только код на MSIL и\или на языке, который в него транслируется
}

//где-то совсем в другом месте - там, где требуется генерация в нэйтив
rewrite "match" of Nemerle to x86_assembler
{
  //тут только код на x86_assembler и\или на языке, который в него транслируется
}

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

WH>>Например в ПЕГе нет никаких терминалов. Так что вся твоя терминология строится на деталях реализации.
A>Вроде как есть.

Если мы строим PEG для разбора Unicode текста, то терминальны у нас — Unicode символы.

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

WH>Семантических ошибок не бывает.
WH>Ибо семантика задана для всех строк принадлежащих языку.