Re[3]: Действительно ли 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 call
    public static final Term binarySimplify( final Term kind, final Term toTheLeft, final Term toTheRight ) { return kind; } // Default simplifier for unary terms - do nothing
    public final Term unarySimplify( Term toTheRight ) { throw new AssertionError(); } // Method body replaced by PEC - with a multiple dispatch call
    public static final Term unarySimplify( final Term kind, final Term toTheRight ) {  return kind; } // Default simplifier for binary terms - do nothing
    public 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 = 0
    public static final Term binarySimplify( final Mult m, final Term t, final Zero z ) { return z; } // x * 0 = 0
    public static final Term binarySimplify( final Mult m, final Zero z, final Zero z2 ) { return z; } // 0 * 0 = 0, needed to resolve conflict
    public static final Term binarySimplify( final Mult m, final NaN n, final Term t ) { return n; } // NaN * x = NaN
    public static final Term binarySimplify( final Mult m, final Term t, final NaN n ) { return n; } // x * NaN = NaN
    public static final Term binarySimplify( final Mult m, final NaN n, final NaN n2 ) { return n; } // NaN * NaN = NaN, needed to resolve conflict
    public static final Term binarySimplify( final Mult m, final NaN n, final Zero z ) { return n; } // NaN * 0 = NaN, needed to resolve conflict
    public 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) out
      case IfEq(_,_,t1,t2) if (t1==t2) => t1
      // #{...} >= 0 --- always true
      case IfEq(_, LVec(_,0),t1,_) => t1
      case x => x
    }

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

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

Вопрос поставлен довольно странно, и критерий (мерять строками) тоже довольно странный.
Для написания нетривиального компилятора на С вам придется реализовать систему управления памятью(или прикрутить консервативный GC), и придумать как вы будете обходить деревья (у вас не будет паттерн-матчинга). После этого, код все равно будет ужасным и нечитаемым

.
Ява куда более приятный кандидат — там есть GC и "visitor". Про scala, например, известно, что после перепысывания ее с Явы на себе самой, код уменьшился в 2 раза — с 48k строк до 23. Скала, для этих целей, вполне похожа на ML без вывода типов

Про Lua: у Lua практически нет компилятора — там применена самая примитивная схема однопроходной трансляции, т.е. AST не создается, оптимизаций никаких не делается — прямо из парсера эммитится байткод VM.
LuaML в строках, может и не короче, зато создает AST и решает задачу типобезопасного расширения Lua из Ocaml, и потом вы сравнивали объем облитературенных исходников LuaML с практически некомментированным кодом Lua.

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 без использования полиморфных вариантов и ещё одна реализация на Лиспе.

Соответствующее обсуждение на comp.lang.lisp

Здравствуйте, Константин Л., Вы писали:

КЛ>Здравствуйте, FR, Вы писали:

FR>>Наткнулся на древнюю статейку с ответом на мой вопрос Why ML/OCaml are good for writing compilers. Только все равно ситуация за почти десять лет никуда ни сдвинулась как писали компиляторы в основном на си так и пишут.

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

Скорее ситуация такая, "мы даже пробовать эту фигню не будем, у нас свое (моча) отличное"

У меня тут случился очередной приступ заинтересованности ML подобными языками. И в процессе наткнулся на реализацию Lua 2.5 на Ocaml'e, читая здесь решил посмотреть насколько лучше Ocaml чем си, но все оказалось наборот:

С (*.с *.h) 194 kb ( http://www.lua.org/ftp/lua-2.5.tar.gz )
Ocaml (*.nw) 222 kb ( http://www.cminusminus.org/rsync/dist/lua-ml-20071123.tar.gz )

Попробовал поискать другие трансляторы но ничего хорошего пока не нашел.
Тут http://json.org/ конечно есть очень хороший для пенисометрии материал, простенький транслятор с реализацией на куче языков, но сравнивать тяжело, так как уровень подержки и качество реализации очень разное.

Можно еще конечно взять http://en.wikipedia.org/wiki/ECMAScript у которого тоже немало реализаций, в том числе и на C++, D и ML. Но опять я нашел только разные версии языка (у digitalmars v3 на ML v4):

http://www.digitalmars.com/dscript/cppscript.html
http://www.digitalmars.com/dscript/index.html
http://www.ecmascript.org

Я не знаю насколько четвертая версия сложнее третей, но по объему ML версия больше D'шной в четыре раза.

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

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

FR>

FR>... This reflects that fact that both implementations are converging on the same low-level representation of the program in order to express more optimizations, i.e. OCaml's expressiveness must be sacrificed in order to reach competitive performance.

И правда, интересный вывод. Сколько еще придётся sacrefise что бы догнать по скорости.

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

Тут есть некоторое ы. Чем лучше формализована задача, тем лучше подходит функциональные языки. Хороший пример реализация XQuery — Galax(реализован на CAML). Он разрабатывался параллельно XQuery на основе его текущей формальной семантики и данная семантика проверялась на нем. То есть гибкость при реализации/изменения формализмов очень высокая. Но по отзывам, реализации на С++ раза в 2 быстрее.(что тоже неудивительно).

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

D>Кроме того, если даже и не брать в рассмотрение Форт (а скажем взять тот же калькулятор), то Монады все равно никуды не деваются. И как мне кажется это такая характерная черта Хаскеля — Монады плодятся как сумасшедшие, как только мы коснулись в программе внешеного мира (генерация\интерпретация кода), я прав?

Нет, попытаюсь объяснить. Путаница идёт из-за непонимания разницы между IO и монадой. Монада — всего лишь интерфейс, под этот интерфейс в языке есть сахар — do-синтаксис.

IO-конкретная монада, относящаяся к внешнему миру. Да, как только мы её коснулись, то выйти из неё не можем, по одной простой причине — функции для работы с IO имеют тип "... -> IO a", функции "IO a -> b" нет (это не совсем верно, но для объяснений достаточно), соответственно, как только мы получили IO результат, будем ли мы его передавать в какую-нибудь функцию, на выходе обязательно будем иметь тот же IO a. Это касается характерная черта этой монады, которая не позволяет нам вынырнуть из мира с побочными эффектами в чистый.

Ни для генерации, ни для интерпретации IO не нужен. Для генерации можно использовать монадические парсеры, а можно писать разбор более явно. Монады всего лишь оборачивают вычисление и сокращают код, как, например, карринг.

Почитай про реализацию монадических парсеров, всё станет гораздо прозрачнее.

Вот например это: G.Hutton, E.Meijer. Monadic Parser Combinators

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

FR,

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

Вообще думал z00n даст ссылу, но раз он промолчал, то я:
Scheme over Ocaml — имплементация схемы на окамле.

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

FR>Это именно по компиляторам или вообще?
FR>И какова методика исследования?
По компиляторам, методика очень ad-hoc — ищем: label:compiler label:java

Наткнулся на древнюю статейку с ответом на мой вопрос Why ML/OCaml are good for writing compilers. Только все равно ситуация за почти десять лет никуда ни сдвинулась как писали компиляторы в основном на си так и пишут.

Здравствуйте, 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.

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

D>И собственно я увидел огромное число применений Monad, фактически код на 80% состоит из нотации "=do..." .
D>Возникли сомнения (отвращение): зачем мне использовать Haskell для таких задач, если он вынуждает меня обертывать 80% компилятора\интерпретатора в монады и работать фактически императивно.

Путаешь монады и императивность.
В первом примере такое обильное количество do из-за того, что парсер монадический.
do определяет что за чем следует в конструкции описываемого языка.

wBeginWhile = do string "begin"
                 manyTill fWord (string "while")
                                 manyTill fWord (string "repeat")

Всего лишь аналог

wBeginWhile ::= "begin" fWord* "while" fWord* "repeat"

не более и не менее императивно/декларативно.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

D> Я имел в виду, что Форт можно и на Haskell написать, если мы не планиурем потом эту реализацию Форта в микроконтроллеры запихивать. А если планируем, тогда да — Форт пишем на Форте + загрузчик на asm'e.
D> В моем же случае нужен компилятор Форта (т.е. мой Форт не будет работать на микроконтроллерах как некоторые Форты), поэтому написать его можно и на Haskell. В микроконтроллерах будет работать уже asm-код сгенерированный компилятором Форта, который я хотел написать на Haskell.

Хозяин барин конечно

Но что мешает написать ядро на хаскеле (вместо ассеблера

очень крутая замена

) а дальше уже поступать как прововерный фортист

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

FR>Все так. Но компилятор это достаточно сложный продукт, и поэтому фичи локально улучшающие кодирование, на конечное время очень большого влияния не окажут. Другое дело что используя более мощный язык используются и более мощные идеомы и паттерны. Но монстры типа автора D я думаю тоже пользуются не менее мощными идеомами, так как опыт в таких делах по моему важнее чем используемый инструмент.

Опыт безусловно важная вещь, как и таналнт. Но я и сказал "при прочих равных". То есть будь у опытного и талантлиого человека более мощьный инструмент, то и достиг бы он большего. А вот объем кода возможно остался бы прежним.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

FR>Наткнулся на древнюю статейку с ответом на мой вопрос Why ML/OCaml are good for writing compilers. Только все равно ситуация за почти десять лет никуда ни сдвинулась как писали компиляторы в основном на си так и пишут.

Сейчас пишут в основном на Java.
Мое беглое исследование Google Code(т.е. в основном свежих проектов) дало следующие результаты:
Java ~25%
C ~15%
Pascal ~8%
Ruby ~7%
C# ~5%
Все остальные языки: Haskell, Ocaml, Scala, C++, Python, Lisp etc. в пределах 5%

.

Ну консервативный 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.

Это да комментариев я сразу не заметил.

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

LCR>Вообще думал z00n даст ссылу, но раз он промолчал, то я:
LCR>Scheme over Ocaml — имплементация схемы на окамле.

А с чем сравнивать то? Надо бы реализаций именно такого же варианта схемы на других языках.

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

LCR>FR,

FR>>А с чем сравнивать то? Надо бы реализаций именно такого же варианта схемы на других языках.

LCR>Ну скажем VSCM — на Си, тоже R4RS (правда Schoca реализует неполный R5RS).

Уже можно сравнить, но не сильно впечатляет разница чуть боьше чем в два раза с си.

LCR>Ещё в качестве альтернативы предлагаю вот этот микробенчмарк, названный Jon Harrop Challenge Problem (дисклэймер по поводу микробенчмарков обычный). Задача состоит в том, чтобы упростить символическое алгебраическое выражение используя следующие правила переписывания:

Интересно

Есть подозрение что рефал порвет всех по краткости кода на этой задаче

(хотя perl наверно тоже)

У меня сходный вопрос, только про Haskell.

Захотелось реализовать Форт (Forth) на Haskell'e.

Да, Форт не имеет грамматики
Да, Форт компилируемо-интерпретируемый
Да, Форт в строках занимает совсем немного на любом языке

Посмотрел реализации:

http://paste.lisp.org/display/4515
http://perlcabal.org/~nothingmuch/harrorth/doc/ (кстати отличный tutorial в форме дневника программирующего Форт на Haskell)
Обратил ещё внимание на реализацию интерпретатора калькулятора на Haskell с критикой:
http://www.rsdn.ru/forum/message/2735657.1.aspx

И собственно я увидел огромное число применений Monad, фактически код на 80% состоит из нотации "=do..." .
Возникли сомнения (отвращение): зачем мне использовать Haskell для таких задач, если он вынуждает меня обертывать 80% компилятора\интерпретатора в монады и работать фактически императивно.

Собственно возможные ответы:

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

Для тех кто не знает что такое Форт(Forth) — это stack-based (Concatenative) язык программирования, того же времени, что и LISP. Форт породил такие языки как Cat, Joy, Factor (не считая огромное число вариаций Форта). Изюминка Форта в его врожденной метапрограммируемости.

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

D>У меня сходный вопрос, только про Haskell.

D>Захотелось реализовать Форт (Forth) на Haskell'e.

Это же кощунство, форт можно реализовывать только на форте, в самом крайнем случае минимальный бустрап на ассемблере

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

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

D>>У меня сходный вопрос, только про Haskell.

D>>Захотелось реализовать Форт (Forth) на Haskell'e.

FR>Это же кощунство, форт можно реализовывать только на форте, в самом крайнем случае минимальный бустрап на ассемблере

Не, ну я же не хочу встроить Форт в контроллер и интерактивно с ним работать, тут понятно дело, не-до-Хаскелла.

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

Кроме того, если даже и не брать в рассмотрение Форт (а скажем взять тот же калькулятор), то Монады все равно никуды не деваются. И как мне кажется это такая характерная черта Хаскеля — Монады плодятся как сумасшедшие, как только мы коснулись в программе внешеного мира (генерация\интерпретация кода), я прав?

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

D>Не, ну я же не хочу встроить Форт в контроллер и интерактивно с ним работать, тут понятно дело, не-до-Хаскелла.

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

Не понял, форт же один из самых расширяемых языков, он же легко сам на себе расширяется, и метапрограмирование там не уступает лиспу (и превосходит хаскель

)

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

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

D>>Не, ну я же не хочу встроить Форт в контроллер и интерактивно с ним работать, тут понятно дело, не-до-Хаскелла.

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

FR>Не понял, форт же один из самых расширяемых языков, он же легко сам на себе расширяется, и метапрограмирование там не уступает лиспу (и превосходит хаскель

)

С выделенным согласен на 100%.

Я имел в виду, что Форт можно и на Haskell написать, если мы не планиурем потом эту реализацию Форта в микроконтроллеры запихивать. А если планируем, тогда да — Форт пишем на Форте + загрузчик на asm'e.
В моем же случае нужен компилятор Форта (т.е. мой Форт не будет работать на микроконтроллерах как некоторые Форты), поэтому написать его можно и на Haskell. В микроконтроллерах будет работать уже asm-код сгенерированный компилятором Форта, который я хотел написать на Haskell.

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

Z>К вопросу о практической применимости вот реальный код (на Scala) из моего собственного компилятора:
Z>

Z>    def optimize : Decision => Decision =  {
Z>      // optimizes IfEq(_,_,Failure,Failure) out
Z>      case IfEq(_,_,t1,t2) if (t1==t2) => t1
Z>      // #{...} >= 0 --- always true
Z>      case IfEq(_, LVec(_,0),t1,_) => t1
Z>      case x => x
Z>    }
Z>

Кстати авторы Скалы рассматривают ее как наследника ML-я?

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

FR>С (*.с *.h) 194 kb ( http://www.lua.org/ftp/lua-2.5.tar.gz )
FR>Ocaml (*.nw) 222 kb ( http://www.cminusminus.org/rsync/dist/lua-ml-20071123.tar.gz )

Про размеры коментариев (без них ML-версия минимум в 2 раза короче), разницу в функциональности и простоту задачи тебе тут уже сказали.

Я же хочу поделиться интересны наблюдением. Объемы программ направленных на решение сходных задач почему-то очень часто являются похжими. Это один из примеров. Другой пример полноценного компилируемого языка вроде D и Nemerle. Их объемы тоже похожи. Казалось бы напрашивается вывод, что пофигу на чем писать. Вот только это если не сравнивать качество решения. Ведь сложность компилторов может быть разная. Все же паттерн-матчинг, более мощьный вывод типов, макросы и т.п. они многого стоят. И будучи написанными на С++ увеличат компилятор еще не в один раз.

Так вот, конечно любую программу можно написать на любом ЯП... по определению. И ресурсом тут является исключительно человеческие возможности. Так что не странно, что объемы компиляторов или интерпретаторов сходны. Это показатель ограничения человеческих возможностей. Так что понято, что раота сделанная на более мощном языке (при прочих равных) получается более качественным, проще расширяется и поддерживается.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

VD>Я же хочу поделиться интересны наблюдением. Объемы программ направленных на решение сходных задач почему-то очень часто являются похжими. Это один из примеров. Другой пример полноценного компилируемого языка вроде D и Nemerle. Их объемы тоже похожи. Казалось бы напрашивается вывод, что пофигу на чем писать. Вот только это если не сравнивать качество решения. Ведь сложность компилторов может быть разная. Все же паттерн-матчинг, более мощьный вывод типов, макросы и т.п. они многого стоят. И будучи написанными на С++ увеличат компилятор еще не в один раз.

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

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

С этим вполне согласен, при прочих равных более мощный язык это хорошо.

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

VD>Кстати авторы Скалы рассматривают ее как наследника ML-я?
Врядли — они хотят двинуть науку и создать идеальную компонентную систему.

Relationship between Scala and Other
Languages
Main influences on the Scala design:
• Java, C# for their syntax, basic types, and class libraries,
• Smalltalk for its uniform object model,
• Beta for systematic nesting,
• ML, Haskell for many of the functional aspects.
• OCaml, OHaskell, PLT-Scheme, as other combinations of FP
and OOP.
• Pizza, Multi-Java, Nice as other extensions of Java with
functional ideas.
(Too many influences in details to list them all)
Scala also seems to influence other new language designs, see for
instance the closures and comprehensions in C# 3.0.

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

FR>Наткнулся на древнюю статейку с ответом на мой вопрос Why ML/OCaml are good for writing compilers. Только все равно ситуация за почти десять лет никуда ни сдвинулась как писали компиляторы в основном на си так и пишут.

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

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

Z>Сейчас пишут в основном на Java.
Z>Мое беглое исследование Google Code(т.е. в основном свежих проектов) дало следующие результаты:
Z>Java ~25%
Z>C ~15%
Z>Pascal ~8%
Z>Ruby ~7%
Z>C# ~5%
Z>Все остальные языки: Haskell, Ocaml, Scala, C++, Python, Lisp etc. в пределах 5%

Это именно по компиляторам или вообще?
И какова методика исследования?

Z>Сейчас пишут в основном на Java.
Z>Мое беглое исследование Google Code(т.е. в основном свежих проектов) дало следующие результаты:
Z>Java ~25%
Z>C ~15%
Z>Pascal ~8%
Z>Ruby ~7%
Z>C# ~5%
Z>Все остальные языки: Haskell, Ocaml, Scala, C++, Python, Lisp etc. в пределах 5%

Мое беглое исследование показало, что в основном в мире пишут на Китайском и Хинди. Завязывал бы ты с Русским, а? А то водь от стада отобъешся.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

Z>По компиляторам, методика очень ad-hoc — ищем: label:compiler label:java

Гугль выдает:

Не найдено ни одного документа, соответствующего запросу label:compiler label:java.

Рекомендации:
Попробуйте использовать другие ключевые слова.

Дхтор! Чё я делаю не так?

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

VD>Дхтор! Чё я делаю не так?
Имелось в виду искать на Google Code, в проектах: http://code.google.com/hosting/

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

Z>Имелось в виду искать на Google Code, в проектах: http://code.google.com/hosting/

А ты не думал, о том, что там просто не все "хостястся"? А то я вот попробовал label:Nemerle и вообще ни гу-гу.

... << RSDN@Home 1.2.0 alpha rev. 637>>

Еще тут http://www.ffconsultancy.com/languages/ray_tracer/verbosity.html и тут http://www.ffconsultancy.com/languages/ray_tracer/comparison.html построчно сравнивают реализации не сложной программы на C++ и ML образных. мне показался очень интересным общий вывод:

In the faster versions of the ray tracers, the OCaml implementations remain the most concise. However, although the most concise C++ is 2.4× longer than the most concise OCaml, the fastest C++ is only 1.65× longer than the fastest OCaml. This reflects that fact that both implementations are converging on the same low-level representation of the program in order to express more optimizations, i.e. OCaml's expressiveness must be sacrificed in order to reach competitive performance.

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

GN>И правда, интересный вывод. Сколько еще придётся sacrefise что бы догнать по скорости.

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

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

D>У меня сходный вопрос, только про Haskell.

D>Захотелось реализовать Форт (Forth) на Haskell'e.
D>

Да, Форт не имеет грамматики
D>

Да, Форт компилируемо-интерпретируемый
D>

Да, Форт в строках занимает совсем немного на любом языке
D>

D>Посмотрел реализации:

Делаем без монад. Даю пример на erlang.

Word = fun( Context ) -> Context2 | integer()
Code = { Word, Word, Word, ... }.
Context = { MathStack, CallStack, PC }
MathStack = CallStack = [Word ]

Плоскую память делать не обязательно. Делаем сегментную - по одному на слово-подпрограмму.
Соответственно,
PC = { Code, integer() }


SubroutineCall = call( Name, Dict ).

call( Name, Dict ) ->
   Code = get( Name, Dict ), 
   fun( { DS, CS, PC } ) ->
      { DS, [ PC | CS ], Code }
   end.
      
ret() ->
   fun( { DS, [ Ret | CS ], _ } ) ->
      { DS, CS, Ret }
   end.

Принцип понятен? Да, надо слова с мутабельной памятью предусмотреть. Ай-ай-ай. Что же делать-то.

А, ну да, конечно. PC = { integer(), integer() }, CodeStorage = array( Code ).
Ну вот, примерно так.

Насчет того, что код монадный? Извините, вы моделируете фон-неймановскую машину с мутабельными операциями. Лучше всего для этого, естественно, подходят мутабельные операции, поэтому импративный язык будет для такого однозначно лучше.

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

GN>И правда, интересный вывод. Сколько еще придётся sacrefise что бы догнать по скорости.

Кстати если сравнить там же максимально оптимизированные варианты:

http://www.ffconsultancy.com/languages/ray_tracer/code/5/ray.cpp
http://www.ffconsultancy.com/languages/ray_tracer/code/5/ray.ml

То получим что практически догоняем:

rayml.exe 00:00:08.375
raycpp.exe 00:00:07.265

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

FR>Во первых у обоих сравниваются неоптимизированные варианты

Я вообще не понял какие варианты сравнивались. Где там соотношения 2.4х и 1.65х

the 105-line C++ and 56-line OCaml programs

Компиляторовалось же с максимальной оптимизацией. Я тогда это делал, что бы показать, что за цифры в бенчмарках на сайте. Например, непонятно, посему именно GCC, и какую погрешность вносит инициализация рантайма.

FR>во вторых примерно полуторократное отставание очень хороший результат, учитывая насколько больше вложенно в низкоурвневую оптимизаци в VC по сравнению с Ocaml (который почти не делает таковую).

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

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

GN>Я вообще не понял какие варианты сравнивались. Где там соотношения 2.4х и 1.65х
GN>

the 105-line C++ and 56-line OCaml programs

Да что-то напутали, но можно все брать с http://www.ffconsultancy.com/languages/ray_tracer/benchmark.html

GN>Компиляторовалось же с максимальной оптимизацией. Я тогда это делал, что бы показать, что за цифры в бенчмарках на сайте. Например, непонятно, посему именно GCC, и какую погрешность вносит инициализация рантайма.

С gcc (3.4.2) я тоже проверил c -O3 время практически одинаково с ocaml.

FR>>во вторых примерно полуторократное отставание очень хороший результат, учитывая насколько больше вложенно в низкоурвневую оптимизаци в VC по сравнению с Ocaml (который почти не делает таковую).

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

Попробовал в С++ добавить #pragma inline_recursion(on) не помогает.

	От:	z00n
	Дата:	14.12.07 09:42
	Оценка:	28 (3) +3

	От:	z00n
	Дата:	14.12.07 06:10
	Оценка:	44 (4)

От:	Lazy Cjow Rhrr	lj://_lcr_
Дата:	14.12.07 08:49
Оценка:	14 (2) +1

	От:	FR
	Дата:	18.12.07 05:27
	Оценка:	+1

	От:	FR
	Дата:	13.12.07 19:50
	Оценка:	20 (2)

	От:	gear nuke
	Дата:	21.12.07 08:21
	Оценка:	16 (2)

От:	lomeo	http://lomeo.livejournal.com/
Дата:	14.12.07 11:06
Оценка:	8 (1)

	От:	Константин Л.
	Дата:	14.12.07 09:01
	Оценка:	+1

От:	VladD2	www.nemerle.org
Дата:	14.12.07 15:55
Оценка:	+1

От:	Didro	home~pages
Дата:	14.12.07 10:14
Оценка:

От:	Gaperton	http://gaperton.livejournal.com
Дата:	21.12.07 08:52
Оценка: