А насколько пригоден/удобен Erlang для разработки компиляторов? По сравнению с OCaml или Haskell. Тут обсуждается Beep. Интересно, во чтобы обошлась разработка его компилятора на Erlang. Может у кого-то есть опыт создания такого или кто поделится интересными URL на эту тему? Вопрос изучается в целях самообразования.
Здравствуйте, frontsquat, Вы писали:
F>А насколько пригоден/удобен Erlang для разработки компиляторов? По сравнению с OCaml или Haskell. Тут обсуждается Beep. Интересно, во чтобы обошлась разработка его компилятора на Erlang. Может у кого-то есть опыт создания такого или кто поделится интересными URL на эту тему? Вопрос изучается в целях самообразования.
Компилятор или интерпретатор можно написать на любом языке. Эрланг тут не исключение. Сам язык поддерживает алгебраические типы и паттерн-матчинг, что упрощает разработку компиляторов на нем (как и на упомянутых OCaml и Haskell).
Другой вопрос, что компилятор будет дерьмовым. Не гоже писать компиляторы на динамически-типизируемых, интерпретируемых языках. Это будут тормоза еще те. Даже представление строк в этом языке мало пригодно для массовой обработки текста.
Ну, а сложность зависит в первую очередь от сложности языка для которого создается компилятор.
Скажем компилятор С можно написать на чем угодно и это будет довольно просто. А вот компилятор современного языка (даже явы) уже написать намного сложнее.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Компилятор или интерпретатор можно написать на любом языке. Эрланг тут не исключение. Сам язык поддерживает алгебраические типы и паттерн-матчинг, что упрощает разработку компиляторов на нем (как и на упомянутых OCaml и Haskell).
С этим согласен. Хотелось бы просто посмотреть на примеры реализации, может кто делал. Что-нибудь не очень сложное, как тот Beep.
VD>Другой вопрос, что компилятор будет дерьмовым. Не гоже писать компиляторы на динамически-типизируемых, интерпретируемых языках. Это будут тормоза еще те. Даже представление строк в этом языке мало пригодно для массовой обработки текста.
Компилятор Erlang написан на Erlang. Означает ли это, что компилятор Erlang дерьмовый?
Здравствуйте, VladD2, Вы писали:
VD>Другой вопрос, что компилятор будет дерьмовым. Не гоже писать компиляторы на динамически-типизируемых, интерпретируемых языках. Это будут тормоза еще те. Даже представление строк в этом языке мало пригодно для массовой обработки текста.
F>А насколько пригоден/удобен Erlang для разработки компиляторов? По сравнению с OCaml или Haskell. Тут обсуждается Beep. Интересно, во чтобы обошлась разработка его компилятора на Erlang. Может у кого-то есть опыт создания такого или кто поделится интересными URL на эту тему? Вопрос изучается в целях самообразования.
Там есть генератор парсеров, и недавно зарелизили генератор лексеров. Так что написать компилятор можно чуть проще, чем просто с нуля голыми руками.
Но по сравнению с OCaml или Haskell это будет намного сложнее, из-за того, что он 1) тормозной 2) с динамической типизацией (а окамл ловит многие ошибки в описании AST во время компиляции, представляю, как это весело будет в эрланге 3) лексер очень сырой. Ему лет пять уже, но до сих пор его была проблема даже найти и скачать — короче, ставить, собирать придется вручную, и вообще мороки будет изрядно, я гарантирую это.
И, что самое главное, там ровно ОДИН генератор парсеров, и ОДИН генератор лексеров.
Так что если есть возможность делать это на хаскелле или окамле — лучше сделайте это на хаскелле или окамле.
VD>>Другой вопрос, что компилятор будет дерьмовым. Не гоже писать компиляторы на динамически-типизируемых, интерпретируемых языках. Это будут тормоза еще те. Даже представление строк в этом языке мало пригодно для массовой обработки текста.
_>В Хаскеле, кстати, точно такое же
В хаскелле есть быстрые строки и парсек с ними умеет работать. И, я конечно, не знаю, какого рода язык пишется, но у меня по замерам парсинг парсером, который генерит ocamlyacc на два или три порядка быстрее всего остального — построения таблиц имен, всяческого анализа, кодогенерации и т.п.
А вот в эрланге да, строки медленные настолько, что, это становится заметно, когда вы пытаетесь их парсить.
VD>>Другой вопрос, что компилятор будет дерьмовым. Не гоже писать компиляторы на динамически-типизируемых, интерпретируемых языках. Это будут тормоза еще те. Даже представление строк в этом языке мало пригодно для массовой обработки текста. _>В Хаскеле, кстати, точно такое же
Позволю себе обоснованно не согласится.
См. так называемые "ленивые вычисления" и библиотеку Data.ByteString.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
F>А насколько пригоден/удобен Erlang для разработки компиляторов? По сравнению с OCaml или Haskell. Тут обсуждается Beep. Интересно, во чтобы обошлась разработка его компилятора на Erlang. Может у кого-то есть опыт создания такого или кто поделится интересными URL на эту тему? Вопрос изучается в целях самообразования.
Посмотри на сам компилятор Эрланга, если интересно самообразование.
AFAIK, на Эрланге ничего, кроме самого Эрланга не компилируют, сейчас по сети поискал. По сравнению с Хаскелем или ОКамлом, конечно.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, frontsquat, Вы писали:
F>С этим согласен. Хотелось бы просто посмотреть на примеры реализации, может кто делал. Что-нибудь не очень сложное, как тот Beep.
Писать компиляторы своего языка не себе лично я считаю делом чести. Языки не имеющие реализации компилятора на самом себе на мой взгляд нельзя считать полноценными.
Что же написания другого языка, то как я уже сказал с этим проблем быть не должно. Ну, будет в 10-20 раз медленнее чем мог бы быть и все.
Если задача потренироваться, то все ОК. Если же хочется создать нечто для людей, то я бы выбрал более подходящий инструмент.
Собственно рассуждать нужно здраво, я бы сказал цинично. Никаких преимуществ перед другими языками поддерживающими паттерн-матчинг Эрланг не дает. Он заведомо более медленны. Так зачем его применять? Если для развлечения, то что тогда вообще спрашивать?
F>Компилятор Erlang написан на Erlang. Означает ли это, что компилятор Erlang дерьмовый?
Начнем с того, что Эрлан по сути интерпретатор. Так что все что у его есть — это транслятор в его байтокод и что-то недоделанное оптимизирующая часть вычислений (компиляуя их). Самым критичным для интерпретируемого языка является его рантайм (VM). А он то как раз написан на С.
Учитывая, что многие считают приемлемым ждать часами пока скомпилируется их С++-код, можно полагать, что для кого-то будет приемлем компилятор работающий в 10 и более раз медленее чем мог.
Опять же нужно понимать, что Эрланг весма прост для компиляции (в байткод), является модульным, не поддерживает вывода типов и сложной системы типов. Это резко упрощает задачу.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, dmz, Вы писали:
dmz>В хаскелле есть быстрые строки и парсек с ними умеет работать. И, я конечно, не знаю, какого рода язык пишется, но у меня по замерам парсинг парсером, который генерит ocamlyacc на два или три порядка быстрее всего остального — построения таблиц имен, всяческого анализа, кодогенерации и т.п.
На счет всего остального ты явно загибаешь. Любой статически типизированный язык обладающий приличным компилятором не отстанет от ОКалмла более чем вдвое (а возможно и опередит его).
dmz>А вот в эрланге да, строки медленные настолько, что, это становится заметно, когда вы пытаетесь их парсить.
Ну, это (наверно) можно обойти написав собственную реализацию на С.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>На счет всего остального ты явно загибаешь. Любой статически типизированный язык обладающий приличным компилятором не отстанет от ОКалмла более чем вдвое (а возможно и опередит его).
Я, вообще-то, имел ввиду, что чтение и разбор файла делаются на два порядка быстрее, чем последующая обработка AST и генерация кода.
Наверное, для других языков соотношение будет где-то такое же.
Здравствуйте, thesz, Вы писали:
T>AFAIK, на Эрланге ничего, кроме самого Эрланга не компилируют, сейчас по сети поискал. По сравнению с Хаскелем или ОКамлом, конечно.
Ага, это я и сделал вначале. И так заело отсутствие результатов, что решил спросить здесь. В общем еще раз подтвердил свое предположение, спасибо всем за ответы.
Здравствуйте, dmz, Вы писали:
dmz>Я, вообще-то, имел ввиду, что чтение и разбор файла делаются на два порядка быстрее, чем последующая обработка AST и генерация кода.
Тут нельзя утверждать что-то в общем.
Скажем "чтение и разбор" С++-файла значительно более вычислительно-сложная задача чем генерация байткода эрланга.
И наоборот. Вывод типов и оптимизация в современном языке значительно сложнее чем парсинг простого языка (вроде Паскаля).
dmz>Наверное, для других языков соотношение будет где-то такое же.
Естественно. Все зависит от языка и задачи.
Вопрос же в том имеет ли смысл использовать тот или иной язык для задачи или нет. Я бы для создания компилятора выбрал бы какой нибудь наследник МЛ-я. На сегодня таких море: ОКамл/F#, Скала, Немерле, Хаскель. Все отлично подходя для данной задачи. Кроме того разумно было бы воспользоваться построителями парсеров.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Вопрос изучается в целях самообразования. 
