как быстро создать свой ЯП?

дело в том, что половина анонимусов драгонбук вместо букваря читала

дело в том, что половина анонимусов драгонбук вместо букваря читала

Вообще-то эта книга входит в программу обучения на большинстве программерских специальностей, так что ничего удивительного.

Это НЕ ADT.

define «ADT»

google: ADT

man jetbrains MPS. Вроде оно под это и заточено.

Там все хорошо, кроме слишком уж марсианской концепции нетекстового редактора.

Топик на ту же тему:
на чём реализовать DSL?

Ну и заодно — сжатый обзор всего упомянутого в той ветке
http://shmat-razum.blogspot.ru/2011/09/dsl.html

спасибо, интересная статья

прочитал твою хотелку — ты хочешь язык http://code.google.com/p/crack-language/crack[/urlpdf

мануал примеры

Сначала напиши интерпретатор языка на нем самом. Очень помогает. Можно выбрать любой.

или ещё вариант: Nimrod поглядь манул

ooc ooc docs ooc-lang

ого, да я не один извращенец :)

Это риторические вопросы, очевидно же что это сложно и мало кому нужно. То есть для проектов с сотнями человеко-лет какой-то рисерч, оптимизации, вся эта обвязка уже как-то встречается, но для языков которые в состоянии proof of concept и пишутся одним автором это как-то бессмысленно, вам не кажется? Хочется сделать как можно проще и быстрее

вообще спор ниачом. мало ли что хочется, вопрос, зачем так изгаляться?

одно дело, если бы ты привёл кучу пруфлинков типа : n% языков слеплено на коленке быстрее без AST чем m% c AST, при этом языки разрабатывались в k% раз быстрее без AST чем с ним.

на практике такого не наблюдаем. да, есть вроде бы где-то на горизонте Ometa из проекта FONC, в котором AST «как бы» нет. на самом деле, он там есть, только в смоллток-подобном виде, см. parsers running backwards и проч. вот в Ometa как раз и есть тот тезис, что в этом language workbench новые языки ad hoc разрабатывать должно быть проще.

да, есть ещё подход когда парсер пишется без лексера. тот же PEG, packrat или парсер-комбинаторы. c оптимизациями тут надо будет повозиться.

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

поэтому как правило никто так и не делает.

но ты пиши своё, да.

там на ooc даже есть операционка

да, есть ещё подход когда парсер пишется без лексера. тот же PEG, packrat или парсер-комбинаторы. c оптимизациями тут надо будет повозиться.

А чем тебе PEG-то не угодил? Оптимизируется он весьма легко. Посмотри на тот же PEG в Nemerle, он шарпик парсит быстрее чем Mono.

Даже Packrat может быть быстрым, если кое какие оптимизации применить (мемоизация только высокоуровневых узлов, но не токенов, inlining).

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

А чем тебе PEG-то не угодил? Оптимизируется он весьма легко. Посмотри на тот же PEG в Nemerle, он шарпик парсит быстрее чем Mono.

есть сомнения в оптимальности скорости его работы, в сравнении с ANTLR, например. нужны дополнительные усилия, например как в Rats! или в packrat (черезчур, обычно достаточно меньшей цепочки наиболее употребимых правил).

то есть, если сравнить ANTLR vs. PEG, то первый всегда будет быстрее.

другой вопрос в том, что грамматику на PEG можно наколбасить за полчаса с тестами, а на ANTLR за пару часов (если с нуля), с тестами в gUnit и потом долго читать доку или книжку по ANTLR чтобы понять, как реализовать очередной семантический предикат.

если кое какие оптимизации применить

да, именно. где-то в рассылке PEG или Ometa был пример более-менее реального парсера, чего-то вроде Delphi. с бенчмарками по разным реализациям PEG.

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

в случае с ANTLR это компенсируется возможностью втыкать свои синтаксические/семантические предикаты, которые ещё надо придумать, как написать.

есть сомнения в оптимальности скорости его работы, в сравнении с ANTLR, например.

ANTRL - тупейший LL(n). Обогнать его - вообще напрягаться не надо.

нужны дополнительные усилия, например как в Rats! или в packrat (черезчур, обычно достаточно меньшей цепочки наиболее употребимых правил).

Посмотри на Nemerle PEG - там ни разу не packrat, там вообще Pratt.

то есть, если сравнить ANTLR vs. PEG, то первый всегда будет быстрее.

Чушь.

в случае с ANTLR это компенсируется возможностью втыкать свои синтаксические/семантические предикаты, которые ещё надо придумать, как написать.

Не компенсируется. Никогда ты не сделаешь на Antlr, например, динамически расширяемую грамматику (как в Katahdin или Fortress).

Причем, PEG наиболее мощный из всех, позволяет описывать языки

да, ещё есть такое: tree based PEG, TBPEG, chilon::parser via язык nyah няшка

там построение AST ещё более автоматизировано.

то есть, если сравнить ANTLR vs. PEG, то первый всегда будет быстрее.

Чушь.

ну это я свои субъективные ощущения написал. а есть пример, более-менее нетривиального языка, когда по эквивалентной грамматике на PEG генерируется парсер, который работает значительно быстрее эквивалентного парсера на ANTLR?

ну это я свои субъективные ощущения написал. а есть пример, более-менее нетривиального языка, когда по эквивалентной грамматике на PEG генерируется парсер, который работает значительно быстрее эквивалентного парсера на ANTLR?

Ну я же уже два раза сказал - Nemerle PEG, грамматика сишарпика (вроде бы, достаточно нетривиален).

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

Тупой вопрос, а antlr умеет делать ast в виде какого-нить json? А то я хотел из питона генерировать код, а под питон нормальных парсеров не нашёл. Перепробовал всё что было в гугле, мне не понравилось. Или под руби, я думаю я и руби осилю.

Старые antlr умели биндинги к питону, а вот antlr4 уже нет :(

Питон - говняный язык для написания трансляторов. Очень говняный. И руби тоже полное говно. На языки без pattern matching даже не смотри.

Паттерн матчинг нужен для парсера. А вот как только есть AST я не понимаю как паттерн матчинг может помочь.

Паттерн матчинг нужен для парсера.

Чё?!? Для парсера он как раз на хер не нужен.

А вот как только есть AST я не понимаю как паттерн матчинг может помочь.

Тогда ты вообще ничего не понимаешь про компиляцию. Тебе же дали много хороших ссылок, почитай хотя бы по диагонали!

Pattern matching необходим для того, чтобы описывать преобразования этого самого AST. Компилятор - это последовательность очень простых преобразований, от AST исходного языка и до целевого языка (который может быть и плоской последовательностью инструкций, и AST языка высокого уровня).

Тебе же дали много хороших ссылок, почитай хотя бы по диагонали!

я уже неделю по диагонали читаю, кол-во вкладок сейчас 34 и продолжает множится...

Отсортируй их по размеру. Изучи сначала самые маленькие и простые компиляторы.

Я пока вот в это вникаю: http://llvm.org/docs/tutorial/OCamlLangImpl1.html

Хороший выбор (хотя, лексер и парсер сложноваты). Вот и посмотри, как там pattern matching для кодогенерации используется:

http://llvm.org/docs/tutorial/OCamlLangImpl3.html

Тупой вопрос, а antlr умеет делать ast в виде какого-нить json?

он умеет отдавать ast в виде S-выражений простым вызовом AST.toStringTree(). получается немного некрасиво отформатированный дамп, который можно загрузить в REPL лиспа, посмотреть, что он ругается на нереализованные формы, реализовать макросами формы, и получить такой тоже интерпретатор/компилятор с небольшими усилиями.

а если делать например свой pretty printing, обходя дерево ручками можно нарисовать форматирование, печатать в JSON и т.п. что угодно

antlr3 питон поддерживал: target вообще поддерживаются такие: targets ещё

Кстати, да, я задумался и понял что не знаю как парсить Питоно-подобные языки. То есть мне Питон вообще умеренно интересен, больше скрипта на 30 строчек на нем ниасиливаю.

Почитал прессу, исходники Питона, подумал и поосозновал. Там не очень все просто, у него из-за «скобочек» отступами не совсем контекстно-свободная грамматика, и чтоб ее сделать такой, в лексере делают псевдо-токены INDENT и DEDENT. Подумал еще, положил клавиатуру на коленку и набыдлокодил пример:

https://github.com/vmxdev/nap

Пример ничего особо полезного не делает, просто парсит и отбивает ошибки (иногда) если их находит.

Умеет парсить что-то типа такого:

class a(b):
    pass
    def __constructor__(int p1, float p2) returns string as:
        pass

class c(d, e, f):
    x = y
    z = 42
    def __constructor__(int p1, float p2) returns string as:
        pass
    class subclass():
        d = 88
        def subclass_func() returns void as:
            pass

def g() returns int as:
  pass

Ну, я там сделал три «действия» (Semantic Actions), они просто выводят названия функций и классов, когда парсер их, э-э, парсит. Хотя, конечно, в этих действиях нужно генерировать AST :) но я все по-простому написал, и натурально на коленке, вообще без никаких затей. Если бы не INDENT/DEDENT, код лексера был бы раза в два короче. А если на OCaml или Lisp, вообще в десять строк.

То есть скорее всего если бы мне нужно было напрограммировать такой язык, выбрал бы какой-то существующий транслятор Питона и его ковырял, но тебе же для фана, хочется с нуля? :)

Спасибо за интерес, обязательно разберусь. А что из этого написано руками, а что автосгенерировано?

но тебе же для фана, хочется с нуля? :)

да :)

Кстати, да, я задумался и понял что не знаю как парсить Питоно-подобные языки.

PEG-ом они парсятся элементарно.

Там не очень все просто, у него из-за «скобочек» отступами не совсем контекстно-свободная грамматика, и чтоб ее сделать такой, в лексере делают псевдо-токены INDENT и DEDENT.

Не нужны токены. Не нужны лексеры. Хватит уже носиться со всяким говном из драконьей книги.

ЗЫ: https://github.com/chrisseaton/katahdin/blob/master/library/python.kat

Да то же самое же практически?

Вот отступы: https://github.com/chrisseaton/katahdin/blob/master/library/indentation.kat

Стек отступов, считает вручную пробелы. Там даже еще креативнее, он отматывает «указатель» назад до начала текущей строки, а потом начинает считать пробелы

А что из этого написано руками, а что автосгенерировано?

Все что там есть - руками :)

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

Для того чтоб изменить грамматику нужно:

изменить grammar.lem, там что-то типа EBNF, большими буквами «терминальные токены» - ключевые слова, операторы и т.п. (то что приходит из лексера)

добавить «действие» после правила в {} - это, если на пальцах, м-м, callback, когда парсер парсит это правило, он вызывает это «действие». На всякий случай для легко возбудимых анонов - я знаю слова FSM, shift, reduce и как оно вообще работает

и добавить «терминальный токен», если нужно, в лексер, lexer.l, функция scan. Терминальный токен может задаваться регулярным выражением

всё, понял что на чём написано, сорри за беспокойство. Надо было с readme начать.

Посмотри на racket. Позиционируется как платформа для написания своих языков: Algol и Prolog на нем, например, есть искаробки.

Тред не читай, сразу отвечай

Кстати, https://www.coursera.org/course/compilers - вчера начался, есть self studying.

спасибо большое, посмотрю :).