![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
как написать компилятор языка J
Mar. 22nd, 2010 03:24 pmПоследние две недели изучал lisp по книге Питера Норвига. Почувствовал себя мольеровским мсье Журденом, который вдруг понял, что всю жизнь говорил "прозой". ;-) Многие системы компьютерной алгебры (с которыми я работал постоянно, последние лет >15) если и не написаны непосредственно на lisp, то (как Mathematica), фактически, реализуют его неявно (не по букве, так по духу). Но речь не об этом... Глянув на настоящий lisp, я понял как "малой кровью" достичь (местами) табуированного "священного грааля" векторных языков -- компиляции.
Эта мысль оказалась не новой. Еще в 1979-м Burge, Moses и Pratt задавались вопросом "APL and LISP—should they be combined, and if so how?". Эта статья мне, к сожалению, недоступна, но и lisp и APL с тех пор здорово изменились. Каким бы ни был ответ -- возможно, сейчас стоит задать тот-же вопрос заново. Мой ответ: "Да, должны. И понятно -- как".
"Священный грааль" в виде компиляции APL в машинный код или C тоже был "взят" неоднократно. Был частичный компилятор фирмы STSC, написал свою книгу "An APL Compiler" Timothy Budd и свой компилятор APEX Robert Bernecky. Но то APL. Для J, насколько я знаю, на сегодня компилятора нет.
С другой стороны, компилятор есть в большинстве популярных реализаций Common Lisp. Причем такой, что компилирует программу как целыми модулями, так и по одной функции "на лету". Замыкания, созданные во время работы программы тоже транслируются в машинный код. Идея компиляции в замыкания тоже не нова, но для APL и J так, насколько я понял, никто не делал. Так почему бы не сделать ?
Написание компилятора в замыкания по трудозатратам сопоставимо с написанием интерпретатора. Да и структура его подобна. Если использовать опыт, накопленный при написании интерпретатора J. Добавив, развитую Бернецким, морфологию массивов -- можно, мне кажется, получить весьма высокопроизводительную вещь. Другое дело, что примитивы в J очень нетривиальны, реализация полной спецификации J с существующими на сегодня оптимизациями займет, наверное, целую человеко-жизнь. Прелесть, однако, в том, что компиляцию в замыкания несложно реализовывать поэтапно, добавляя по одному глаголу, наречию или союзу. Такая работа, по идее, должна хорошо распараллеливаться.
И так, в чем я здесь не прав ? Стоит ли этим заняться ?
( Чтобы не быть голословным... )
Эта мысль оказалась не новой. Еще в 1979-м Burge, Moses и Pratt задавались вопросом "APL and LISP—should they be combined, and if so how?". Эта статья мне, к сожалению, недоступна, но и lisp и APL с тех пор здорово изменились. Каким бы ни был ответ -- возможно, сейчас стоит задать тот-же вопрос заново. Мой ответ: "Да, должны. И понятно -- как".
"Священный грааль" в виде компиляции APL в машинный код или C тоже был "взят" неоднократно. Был частичный компилятор фирмы STSC, написал свою книгу "An APL Compiler" Timothy Budd и свой компилятор APEX Robert Bernecky. Но то APL. Для J, насколько я знаю, на сегодня компилятора нет.
С другой стороны, компилятор есть в большинстве популярных реализаций Common Lisp. Причем такой, что компилирует программу как целыми модулями, так и по одной функции "на лету". Замыкания, созданные во время работы программы тоже транслируются в машинный код. Идея компиляции в замыкания тоже не нова, но для APL и J так, насколько я понял, никто не делал. Так почему бы не сделать ?
Написание компилятора в замыкания по трудозатратам сопоставимо с написанием интерпретатора. Да и структура его подобна. Если использовать опыт, накопленный при написании интерпретатора J. Добавив, развитую Бернецким, морфологию массивов -- можно, мне кажется, получить весьма высокопроизводительную вещь. Другое дело, что примитивы в J очень нетривиальны, реализация полной спецификации J с существующими на сегодня оптимизациями займет, наверное, целую человеко-жизнь. Прелесть, однако, в том, что компиляцию в замыкания несложно реализовывать поэтапно, добавляя по одному глаголу, наречию или союзу. Такая работа, по идее, должна хорошо распараллеливаться.
И так, в чем я здесь не прав ? Стоит ли этим заняться ?
( Чтобы не быть голословным... )
