Четвертый переводчик в Java

Question

Здесь Я нашел интерпретатор Simple Forth, реализованный на Java.
Однако я не понимаю значения этого, если я хочу использовать это?

В чем может быть преимущество четвертого переводчика:

• Если окончательный скомпилированный код будет исполняется JVM до сих пор "Байт код "что бы мы дальше Переводчик делать?
• Поможет ли это в письменной форме? эффективные / трудные программы?
• Буду ли я писать свой код в Форт и переводчик преобразует его в Java?

Ваши мысли ...

Answer 1

Автор на странице описывает, как реализующий подмножество FORTH и подходящий для включения в другие приложения; предположительно он предназначен для обеспечения возможности сценариев для приложения. Маловероятно, что система работает, выпуская байт-коды Java или JVM; он почти наверняка использует интерпретатор, написанный на Java.

Традиционно интерпретатор FORTH может быть реализован с очень маленьким объемом памяти. Я знаю кого-то, кто реализовал один на COSMAC, и основной интерпретатор имел длину 30 байт . Байтовый код, ориентированный на стек, также был очень компактным, так как не требовалось указывать расположение операндов - он просто считывал из стека и помещал результат в верхнюю часть стека. Это сделало его популярным в кругах встраиваемых систем, где небольшие издержки интерпретатора были более чем компенсированы компактным представлением логики программы.

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

Answer 2

Поможет ли это в письменной форме? эффективные / жесткие программы?

* +1004 * Это спорно.

Я уверен, что FORTH люди скажут вам, что это быстро. Но я сомневаюсь, что скорость выполнения программы FORTH, выполняемой на интерпретаторе FORTH, реализованном в Java, будет соответствовать скорости эквивалентной программы, реализованной непосредственно в Java. Для начала, JIT-компилятор не сможет так хорошо оптимизировать интерпретатор FORTH, как для простой версии Java.

Если под «тесным» вы подразумеваете «использование меньшего количества памяти», я думаю, что разница будет незначительной. Помните, что в случаях «FORTH в Java» и «простой Java» у вас есть все накладные расходы памяти Java JVM. Это может затмить любое сравнение плотности кода FORTH с эквивалентной плотностью скомпилированного кода Java.

Answer 3

Это позволяет вам писать эффективные / трудные программы. Частично потому, что способность определять определяющие слова (слова, исполняемые во время компиляции) может иметь эффект эффективного определения предметно-ориентированного языка (DSL). Forth также поощряет рефакторинг (иначе стековые вещи просто становятся непостижимыми ...), и, таким образом, код будет трудным.

Answer 4

Не переводчик байт-кода

Ответы на ваши вопросы: «см. Ниже, вроде, и нет».

Это просто программа, которая принимает некоторые данные и выдает некоторые результаты. Ввод сценария Forth. За исключением некоторых очень крупных систем, на самом деле редко получается байт-код. jRuby, Clojure, Scala ... такие большие системы производят байт-код.

Однако ваш интерпретатор Forth, вероятно, просто так: интерпретатор сценариев, который написан на Java. Входные данные, которые он принимает, являются своего рода программой, так что в итоге вы получите приятное двойное косвенное выполнение. Далее выполняется через интерпретатор байт-кода, выполняющийся через jvm, работающий на CPU.

Теперь, если вы запустили это на эмуляторе ЦП или написали интерпретатор на Forth, вы можете сделать его тройным косвенным. (И в некотором смысле это уже происходит, потому что ваш процессор Intel переводит большинство x86 кодов операций в микрооперации перед их выполнением.: -)

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

Вы должны думать обо всем этом, пока не поймете это.

Answer 5

7th ИМХО ближе к оригинальному дизайну четвёртого, чем любой другой язык RPN в JVM. Есть редактор с нумерацией строк и кодом beautyfier. Существует соответствующая реализация "interpiler" и словаря со словарем / current / context. Условно большинство аппаратно-зависимых слов - для сохранения или извлечения из определенного адреса памяти - отсутствует. Любые слова для подсчета памяти на JVM в любом случае были бы совершенно бессмысленными. Некоторые полезные дополнения к четвертому синтаксису были сделаны в 7th :

• слово помощь
• 7 является объектно-ориентированным
• существует сопоставление с шаблоном, похожим на Perl
• комплексные числа и массивы являются частью языка
• механизм перенаправления / отсутствия доступа, который при необходимости может отправлять вывод в стек или консоль и предотвращать выполнение слов file-io, например. во время тестирования

Answer 6

Основным преимуществом интерпретатора FORTH, подобного, является его интерактивность. Это означает, что я ввожу слово и сразу получаю ответ. Если для создания файла или чего-либо еще необходим промежуточный шаг, это преимущество исчезло. Второе - это аспект POL (проблемно-ориентированный язык) : язык должен быть расширяемым плавно . Таким образом, если язык FORTH не способен компилировать новые слова, он бесполезен.

Answer 7

Существует несколько систем Forth, которые реализуют интерпретатор Forth в Java. Есть два, о которых я знаю, которые на самом деле компилируют четвертый исходный код в класс JVM и позволяют вам выполнять код Forth напрямую без необходимости интерпретатора.

• HolonJ от Wolf Wejgaard
• Мисти Бич Форт