Попробовал поискать другие трансляторы но ничего хорошего пока не нашел.
Тут http://json.org/ конечно есть очень хороший для пенисометрии материал, простенький транслятор с реализацией на куче языков, но сравнивать тяжело, так как уровень подержки и качество реализации очень разное.
Можно еще конечно взять http://en.wikipedia.org/wiki/ECMAScript у которого тоже немало реализаций, в том числе и на C++, D и ML. Но опять я нашел только разные версии языка (у digitalmars v3 на ML v4):
Здравствуйте, FR, Вы писали:
FR>Хотелось бы еще примеров реализации трансляторов, на которых действительно можно нормально сравнить что дает высокоуровневый язык в этой сфере.
Вопрос поставлен довольно странно, и критерий (мерять строками) тоже довольно странный.
Для написания нетривиального компилятора на С вам придется реализовать систему управления памятью(или прикрутить консервативный GC), и придумать как вы будете обходить деревья (у вас не будет паттерн-матчинга). После этого, код все равно будет ужасным и нечитаемым .
Ява куда более приятный кандидат — там есть GC и "visitor". Про scala, например, известно, что после перепысывания ее с Явы на себе самой, код уменьшился в 2 раза — с 48k строк до 23. Скала, для этих целей, вполне похожа на ML без вывода типов
Про Lua: у Lua практически нет компилятора — там применена самая примитивная схема однопроходной трансляции, т.е. AST не создается, оптимизаций никаких не делается — прямо из парсера эммитится байткод VM.
LuaML в строках, может и не короче, зато создает AST и решает задачу типобезопасного расширения Lua из Ocaml, и потом вы сравнивали объем облитературенных исходников LuaML с практически некомментированным кодом Lua.
Re[2]: Действительно ли ML языки хороши в компиляторописании
Здравствуйте, z00n, Вы писали:
Z>Здравствуйте, FR, Вы писали:
FR>>Хотелось бы еще примеров реализации трансляторов, на которых действительно можно нормально сравнить что дает высокоуровневый язык в этой сфере.
Z>Вопрос поставлен довольно странно, и критерий (мерять строками) тоже довольно странный. Z>Для написания нетривиального компилятора на С вам придется реализовать систему управления памятью(или прикрутить консервативный GC), и придумать как вы будете обходить деревья (у вас не будет паттерн-матчинга). После этого, код все равно будет ужасным и нечитаемым .
Ну консервативный GC вообще не проблема в той же реализации ECMAScript от DMD он 68 Kb всего занимает, правда там C++. Вообще это пока единственный нормальный доступный код для сравнения (правда рекламный ) но вот сравнить хотя бы С++ или D или C# с ML нет ничего.
Z>Ява куда более приятный кандидат — там есть GC и "visitor". Про scala, например, известно, что после перепысывания ее с Явы на себе самой, код уменьшился в 2 раза — с 48k строк до 23. Скала, для этих целей, вполне похожа на ML без вывода типов
А есть доступные исходники?
Кстати у меня есть опыт переписывания своей программы с C++ на опять же на C++ и тоже код уменьшился в полтора раза
Z>Про Lua: у Lua практически нет компилятора — там применена самая примитивная схема однопроходной трансляции, т.е. AST не создается, оптимизаций никаких не делается — прямо из парсера эммитится байткод VM. Z>LuaML в строках, может и не короче, зато создает AST и решает задачу типобезопасного расширения Lua из Ocaml, и потом вы сравнивали объем облитературенных исходников LuaML с практически некомментированным кодом Lua.
Это да комментариев я сразу не заметил.
Re: Действительно ли ML языки хороши в компиляторописании?
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>Вообще думал z00n даст ссылу, но раз он промолчал, то я: LCR>Scheme over Ocaml — имплементация схемы на окамле.
А с чем сравнивать то? Надо бы реализаций именно такого же варианта схемы на других языках.
Re[3]: Действительно ли ML языки хороши в компиляторописании
FR,
FR>А с чем сравнивать то? Надо бы реализаций именно такого же варианта схемы на других языках.
Ну скажем VSCM — на Си, тоже R4RS (правда Schoca реализует неполный R5RS).
Ещё есть, например, Gambit на C++, но этот компилятор намного круче, сильно оптимизирующий R6RS.
Можно ещё здесь реализации повыбирать, но тут вообще бездна
Ещё в качестве альтернативы предлагаю вот этот микробенчмарк, названный Jon Harrop Challenge Problem (дисклэймер по поводу микробенчмарков обычный). Задача состоит в том, чтобы упростить символическое алгебраическое выражение используя следующие правила переписывания:
rational n + rational m -> rational(n + m)
rational n * rational m -> rational(n * m)
symbol x -> symbol x
0+f -> f
f+0 -> f
0*f -> 0
f*0 -> 0
1*f -> f
f*1 -> f
a+(b+c) -> (a+b)+c
a*(b*c) -> (a*b)*c
Результаты здесь, сравниваются исходники на Qi, Lisp и Ocaml. Альтернативная реализация на Ocaml без использования полиморфных вариантов и ещё одна реализация на Лиспе.
Здравствуйте, z00n, Вы писали:
Z>Здравствуйте, FR, Вы писали:
FR>>Хотелось бы еще примеров реализации трансляторов, на которых действительно можно нормально сравнить что дает высокоуровневый язык в этой сфере.
Z>Вопрос поставлен довольно странно, и критерий (мерять строками) тоже довольно странный. Z>Для написания нетривиального компилятора на С вам придется реализовать систему управления памятью(или прикрутить консервативный GC), и придумать как вы будете обходить деревья (у вас не будет паттерн-матчинга). После этого, код все равно будет ужасным и нечитаемым .
прикручивание систему управления памятью задача специфичная не только для написания компайлеров. Кроме того, как же в языках без паттерн матчинга люди обходят деревья? Думаю, как-то справляются.
Z>Ява куда более приятный кандидат — там есть GC и "visitor". Про scala, например, известно, что после перепысывания ее с Явы на себе самой, код уменьшился в 2 раза — с 48k строк до 23. Скала, для этих целей, вполне похожа на ML без вывода типов
Визиторы есть везде
Z>Про Lua: у Lua практически нет компилятора — там применена самая примитивная схема однопроходной трансляции, т.е. AST не создается, оптимизаций никаких не делается — прямо из парсера эммитится байткод VM. Z>LuaML в строках, может и не короче, зато создает AST и решает задачу типобезопасного расширения Lua из Ocaml, и потом вы сравнивали объем облитературенных исходников LuaML с практически некомментированным кодом Lua.
Re[4]: Действительно ли ML языки хороши в компиляторописании
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>FR,
FR>>А с чем сравнивать то? Надо бы реализаций именно такого же варианта схемы на других языках.
LCR>Ну скажем VSCM — на Си, тоже R4RS (правда Schoca реализует неполный R5RS).
Уже можно сравнить, но не сильно впечатляет разница чуть боьше чем в два раза с си.
LCR>Ещё в качестве альтернативы предлагаю вот этот микробенчмарк, названный Jon Harrop Challenge Problem (дисклэймер по поводу микробенчмарков обычный). Задача состоит в том, чтобы упростить символическое алгебраическое выражение используя следующие правила переписывания:
Интересно
Есть подозрение что рефал порвет всех по краткости кода на этой задаче
(хотя perl наверно тоже)
Re[4]: Действительно ли ML языки хороши в компиляторописании
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>Ещё в качестве альтернативы предлагаю вот этот микробенчмарк, названный Jon Harrop Challenge Problem .
Отличная мысль. Аналогично, Одерски как-то хвастался перед явистами паттерн-матчингом на таком примере:
// SCALA!class Term
case class Num(n: int) extends Term
case class Var(name: String) extends Term
case class Mul(l: Term, r: Term) extends Term
case class Add(l: Term, r: Term) extends Term
// Now let's say we want to implement some simplification rules on such terms.
// Two useful simplifications apply the equalities:
// 0 * x = 0
// 1 * x = x
def simplify(term: Term) = term match {
case Mul(Num(0), x) => Num(0)
case Mul(Num(1), x) => x
case _ => term
}
Ему ответили, что мултиплай — диспатч на яве — это просто
public interface TermMD extends pec.compile.multipledispatch.MultipleDispatch { // The methods in this interface are Multiply Dispatched
Term binarySimplify( Term toTheLeft, Term toTheRight );
Term unarySimplify( Term toTheRight );
}
public interface Term extends TermMD { // The method in this interface is Singly Dispatched
Term simplify();
}
public abstract class TerminalTerm implements Term {
public final Term binarySimplify( Term toTheLeft, Term toTheRight ) { throw new AssertionError(); } // Method body replaced by PEC - with a multiple dispatch callpublic static final Term binarySimplify( final Term kind, final Term toTheLeft, final Term toTheRight ) { return kind; } // Default simplifier for unary terms - do nothingpublic final Term unarySimplify( Term toTheRight ) { throw new AssertionError(); } // Method body replaced by PEC - with a multiple dispatch callpublic static final Term unarySimplify( final Term kind, final Term toTheRight ) { return kind; } // Default simplifier for binary terms - do nothingpublic Term simplify() { return this; } // Nothing to simplify for a terminal!
}
public abstract class UnaryTerm extends TerminalTerm {
protected final Term toTheRight;
protected UnaryTerm( final Term toTheRight ) { this.toTheRight = toTheRight.simplify(); }
public Term simplify() { return unarySimplify( toTheRight ); }
}
public abstract class BinaryTerm extends UnaryTerm {
protected final Term toTheLeft;
protected BinaryTerm( final Term toTheLeft, final Term toTheRight ) {
super( toTheRight );
this.toTheLeft = toTheLeft.simplify();
}
public Term simplify() { return binarySimplify( toTheLeft, toTheRight ); }
}
public final class Zero extends TerminalTerm {}
public final class NaN extends TerminalTerm {}
public final class Var extends TerminalTerm {}
public final class Mult extends BinaryTerm {
public Mult( final Term toTheLeft, final Term toTheRight ) { super( toTheLeft, toTheRight ); }
public static final Term binarySimplify( final Mult m, final Zero z, final Term t ) { return z; } // 0 * x = 0public static final Term binarySimplify( final Mult m, final Term t, final Zero z ) { return z; } // x * 0 = 0public static final Term binarySimplify( final Mult m, final Zero z, final Zero z2 ) { return z; } // 0 * 0 = 0, needed to resolve conflictpublic static final Term binarySimplify( final Mult m, final NaN n, final Term t ) { return n; } // NaN * x = NaNpublic static final Term binarySimplify( final Mult m, final Term t, final NaN n ) { return n; } // x * NaN = NaNpublic static final Term binarySimplify( final Mult m, final NaN n, final NaN n2 ) { return n; } // NaN * NaN = NaN, needed to resolve conflictpublic static final Term binarySimplify( final Mult m, final NaN n, final Zero z ) { return n; } // NaN * 0 = NaN, needed to resolve conflictpublic static final Term binarySimplify( final Mult m, final Zero z, final NaN n ) { return n; } // 0 * NaN = NaN, needed to resolve conflict
}
К вопросу о практической применимости вот реальный код (на Scala) из моего собственного компилятора:
def optimize : Decision => Decision = {
// optimizes IfEq(_,_,Failure,Failure) outcase IfEq(_,_,t1,t2) if (t1==t2) => t1
// #{...} >= 0 --- always truecase IfEq(_, LVec(_,0),t1,_) => t1
case x => x
}
Re: Действительно ли ML языки хороши в компиляторописании?
И собственно я увидел огромное число применений Monad, фактически код на 80% состоит из нотации "=do..." .
Возникли сомнения (отвращение): зачем мне использовать Haskell для таких задач, если он вынуждает меня обертывать 80% компилятора\интерпретатора в монады и работать фактически императивно.
Собственно возможные ответы:
Да, не стоит использовать Haskell для таких (простых) задач. Примеры выше — это из пушки по воробьям.
Да, на Haskell вообще без монад в компиляторах только AST можно обрабатывать.
Да, Haskell это круто! Монады позволяют явно отделить императивный мир от функционального! (и?)
Для тех кто не знает что такое Форт(Forth) — это stack-based (Concatenative) язык программирования, того же времени, что и LISP. Форт породил такие языки как Cat, Joy, Factor (не считая огромное число вариаций Форта). Изюминка Форта в его врожденной метапрограммируемости.
Re[2]: Действительно ли ML языки хороши в компиляторописании
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, Didro, Вы писали:
D>>У меня сходный вопрос, только про Haskell.
D>>Захотелось реализовать Форт (Forth) на Haskell'e.
FR>Это же кощунство, форт можно реализовывать только на форте, в самом крайнем случае минимальный бустрап на ассемблере
Не, ну я же не хочу встроить Форт в контроллер и интерактивно с ним работать, тут понятно дело, не-до-Хаскелла.
Я хочу компилятор Форта, на выходе которого я бы получил код под конкретный контроллер. А в процессе разработки мог бы расширять компилятор новыми словами.
Кроме того, если даже и не брать в рассмотрение Форт (а скажем взять тот же калькулятор), то Монады все равно никуды не деваются. И как мне кажется это такая характерная черта Хаскеля — Монады плодятся как сумасшедшие, как только мы коснулись в программе внешеного мира (генерация\интерпретация кода), я прав?
Re[2]: Действительно ли ML языки хороши в компиляторописании
Здравствуйте, Didro, Вы писали:
D>И собственно я увидел огромное число применений Monad, фактически код на 80% состоит из нотации "=do..." . D>Возникли сомнения (отвращение): зачем мне использовать Haskell для таких задач, если он вынуждает меня обертывать 80% компилятора\интерпретатора в монады и работать фактически императивно.
Путаешь монады и императивность.
В первом примере такое обильное количество do из-за того, что парсер монадический.
do определяет что за чем следует в конструкции описываемого языка.
Здравствуйте, Didro, Вы писали:
D>Кроме того, если даже и не брать в рассмотрение Форт (а скажем взять тот же калькулятор), то Монады все равно никуды не деваются. И как мне кажется это такая характерная черта Хаскеля — Монады плодятся как сумасшедшие, как только мы коснулись в программе внешеного мира (генерация\интерпретация кода), я прав?
Нет, попытаюсь объяснить. Путаница идёт из-за непонимания разницы между IO и монадой. Монада — всего лишь интерфейс, под этот интерфейс в языке есть сахар — do-синтаксис.
IO-конкретная монада, относящаяся к внешнему миру. Да, как только мы её коснулись, то выйти из неё не можем, по одной простой причине — функции для работы с IO имеют тип "... -> IO a", функции "IO a -> b" нет (это не совсем верно, но для объяснений достаточно), соответственно, как только мы получили IO результат, будем ли мы его передавать в какую-нибудь функцию, на выходе обязательно будем иметь тот же IO a. Это касается характерная черта этой монады, которая не позволяет нам вынырнуть из мира с побочными эффектами в чистый.
Ни для генерации, ни для интерпретации IO не нужен. Для генерации можно использовать монадические парсеры, а можно писать разбор более явно. Монады всего лишь оборачивают вычисление и сокращают код, как, например, карринг.
Почитай про реализацию монадических парсеров, всё станет гораздо прозрачнее.
Здравствуйте, Didro, Вы писали:
D>Не, ну я же не хочу встроить Форт в контроллер и интерактивно с ним работать, тут понятно дело, не-до-Хаскелла. D>Я хочу компилятор Форта, на выходе которого я бы получил код под конкретный контроллер. А в процессе разработки мог бы расширять компилятор новыми словами.
Не понял, форт же один из самых расширяемых языков, он же легко сам на себе расширяется, и метапрограмирование там не уступает лиспу (и превосходит хаскель )
Re[5]: Действительно ли ML языки хороши в компиляторописании
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, Didro, Вы писали:
D>>Не, ну я же не хочу встроить Форт в контроллер и интерактивно с ним работать, тут понятно дело, не-до-Хаскелла. D>>Я хочу компилятор Форта, на выходе которого я бы получил код под конкретный контроллер. А в процессе разработки мог бы расширять компилятор новыми словами.
FR>Не понял, форт же один из самых расширяемых языков, он же легко сам на себе расширяется, и метапрограмирование там не уступает лиспу (и превосходит хаскель )
С выделенным согласен на 100%.
Я имел в виду, что Форт можно и на Haskell написать, если мы не планиурем потом эту реализацию Форта в микроконтроллеры запихивать. А если планируем, тогда да — Форт пишем на Форте + загрузчик на asm'e.
В моем же случае нужен компилятор Форта (т.е. мой Форт не будет работать на микроконтроллерах как некоторые Форты), поэтому написать его можно и на Haskell. В микроконтроллерах будет работать уже asm-код сгенерированный компилятором Форта, который я хотел написать на Haskell.
Re[6]: Действительно ли ML языки хороши в компиляторописании
Здравствуйте, Didro, Вы писали:
D> Я имел в виду, что Форт можно и на Haskell написать, если мы не планиурем потом эту реализацию Форта в микроконтроллеры запихивать. А если планируем, тогда да — Форт пишем на Форте + загрузчик на asm'e. D> В моем же случае нужен компилятор Форта (т.е. мой Форт не будет работать на микроконтроллерах как некоторые Форты), поэтому написать его можно и на Haskell. В микроконтроллерах будет работать уже asm-код сгенерированный компилятором Форта, который я хотел написать на Haskell.
Хозяин барин конечно
Но что мешает написать ядро на хаскеле (вместо ассеблера очень крутая замена ) а дальше уже поступать как прововерный фортист
Re[5]: Действительно ли ML языки хороши в компиляторописании
Про размеры коментариев (без них ML-версия минимум в 2 раза короче), разницу в функциональности и простоту задачи тебе тут уже сказали.
Я же хочу поделиться интересны наблюдением. Объемы программ направленных на решение сходных задач почему-то очень часто являются похжими. Это один из примеров. Другой пример полноценного компилируемого языка вроде D и Nemerle. Их объемы тоже похожи. Казалось бы напрашивается вывод, что пофигу на чем писать. Вот только это если не сравнивать качество решения. Ведь сложность компилторов может быть разная. Все же паттерн-матчинг, более мощьный вывод типов, макросы и т.п. они многого стоят. И будучи написанными на С++ увеличат компилятор еще не в один раз.
Так вот, конечно любую программу можно написать на любом ЯП... по определению. И ресурсом тут является исключительно человеческие возможности. Так что не странно, что объемы компиляторов или интерпретаторов сходны. Это показатель ограничения человеческих возможностей. Так что понято, что раота сделанная на более мощном языке (при прочих равных) получается более качественным, проще расширяется и поддерживается.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Действительно ли ML языки хороши в компиляторописании
Здравствуйте, VladD2, Вы писали:
VD>Я же хочу поделиться интересны наблюдением. Объемы программ направленных на решение сходных задач почему-то очень часто являются похжими. Это один из примеров. Другой пример полноценного компилируемого языка вроде D и Nemerle. Их объемы тоже похожи. Казалось бы напрашивается вывод, что пофигу на чем писать. Вот только это если не сравнивать качество решения. Ведь сложность компилторов может быть разная. Все же паттерн-матчинг, более мощьный вывод типов, макросы и т.п. они многого стоят. И будучи написанными на С++ увеличат компилятор еще не в один раз.
Все так. Но компилятор это достаточно сложный продукт, и поэтому фичи локально улучшающие кодирование, на конечное время очень большого влияния не окажут. Другое дело что используя более мощный язык используются и более мощные идеомы и паттерны. Но монстры типа автора D я думаю тоже пользуются не менее мощными идеомами, так как опыт в таких делах по моему важнее чем используемый инструмент.
VD>Так вот, конечно любую программу можно написать на любом ЯП... по определению. И ресурсом тут является исключительно человеческие возможности. Так что не странно, что объемы компиляторов или интерпретаторов сходны. Это показатель ограничения человеческих возможностей. Так что понято, что раота сделанная на более мощном языке (при прочих равных) получается более качественным, проще расширяется и поддерживается.
С этим вполне согласен, при прочих равных более мощный язык это хорошо.
.
) но вот сравнить хотя бы С++ или D или C# с ML нет ничего.
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
