Rakudo Star 2015.06

Прочитаю, продолжим. Спасибо. Дома где-то была книжка. Что-то я, видать ,упустил в свое время. Я как-то думал, что перл преобразуется в синтаксическое дерево и оно явно интерпретируется.

Так и есть, в дерево разбора, optree. Это при стандартном использовании Perl, когда есть две фазы - фаза компиляции -> фаза выполнения. После компиляции можно генерировать C или byte код с помощью модулей B::*, но это уже скорее экзотика. Еще RPerl 1.0 на днях вышел. А вот в Perl6 уже JIT компиляция используется.

Ну optree — это еще не байткод. Байткод появляется в 6м перле, и я не думаю, что это хорошо. Вот от Java и прочего JRuby избавиться, а разработчики еще мне одну виртуальную машину навязать готовы....

Вон коллеги матерятся от связки Tomcat+JRuby в продакшене, потому как память течет из-за того, что какие-то треды криво завершаются.

Perl компилирует (компилятор не однопроходной+оптимизирующий) не в машинный код, а в PP-коды которые выполняется на стековой виртуальной машине Perl - то есть интерпретируется. JIT-компиляции там не много и jit-у не подвергается вся программа.

Недавно вышедший RPerl делает то что думалось сообществом давным-давно: транслирует perl-код через промежуточные этапы в С++-код который компилируется в машинный код (работает, уже опробовал).

Поясните мимокрокодилу, четко и ясно, чем принципиально новый перл лучше того же питона? Ну синтаксисом, ок. Что еще?
Что там с многопоточностью, параллельностью? GIL?
Он перестал быть write-once?

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

чего бы не было, к примеру, в руби.

контекстов?

Хм... Тем не менее выполняет это самое optree, судя по тому, что написано в книжке, вполне себе стековая виртуальная машина a la forth (только стеков больше и сборщик мусора прикручен :) ). И Ларри Волл сотоварищи пишут об этом как о PVM, выполняющей PP-коды. Насколько это отличается от подхода MoarVM - надо будет на досуге посмотреть, поковырять...

Ну что сказать,

Как и выяснилось, все это вопрос наименования. Пока мы признали, что трансляции в байт-код не происходит. Форт, если мне память не изменяет, состоит из «статей», которая или представляет собой оттранслированный машинный код или набор ссылок на другие статьи (то есть код на форте), Поэтому, стековой машины достаточно.

Вот цитата из документации на MoarVM (скачал, смотрю), раздел «bytecode»

This consists of a sequence of instructions. Instruction codes are always 16 bits in length. The first 8 bits describe an instruction «bank», and the following 8 bits identify the instruction within that bank. Instruction banks 0 through 127 are reserved for MoarVM core ops or future needs. Instruction banks 128 through 255 are mappable per compilation unit, and are used for «plug-in» ops.

Opcodes may be followed by zero or more operands.

Из раздела «Interpretator»

The interpreter first dispatches on op bank, then on the code within that. For the core and primitive operations, that is done through a switch that is inlined directly inside of the interpreter.

The list of ops is held in src/core/oplist. This is processed by the tools/update_ops_h.p6 tool to generate src/core/ops.h and ops.c, which contain all of the metadata about the operations and operation banks.

Ну, то есть, байт-код, как-то организованный.

Rakudo является компилятором Perl 6 под Parrot, если чо.

Вы по ссылке сходите.
Это набор компиляторов.