Интерпретатор на Java

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

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

  • если конечный скомпилированный код должен быть выполняется JVM по-прежнему " байт код" что бы мы далее Переводчик будет делать?
  • поможет ли это в письменной форме эффективные / жесткие программы?
  • буду ли я писать свой код в Далее и переводчик преобразует его на Яву?

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

6
forth interpreter java

7 ответов

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

это спорно.

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

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

4

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

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

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

5

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

ответы на ваши вопросы: "см. ниже, вроде, и нет".

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

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

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

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

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

2

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

2

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

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

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

0

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

0