Pull to refresh

Comments 18

Меня мучает только один вопрос — зачем?
Любопытство, полезный опыт и способ скоротать время в летние ночи
я понимаю, если бы вместо брайнфака было бы что-то полезное, но писать язык, на котором брайнфакно что-то писать…
Чтобы написать полноценный язык, нужно вначале написать что-то очень простое.
Теперь допишите в компилятор возможность вызова методов JVM, чтобы можно было использовать библиотеки из той же Java, и можно будет пилить транслируемый в BF процедурный язык.
На очень простой и скорее бесполезной задаче проверен весь стек технологий
Проверено, что всё запускается.

На новом языке/технологии всегда полезно написать «Hello, world!».
А есть смысл генерировать сразу байткод, если можно сгенерировать исходник Java, и прогнать уже через javac?
Данная статья именно о написании своего компилятора, а не трансляции Brainfuck в Java и последующей компиляцией.

Если вам нужно генерировать исходник на Java, то данная возможность есть из коробки. Посмотрите класс Translator, с помощью него можно получить исходник либо на Java, либо на C++.
Если вам нужно получить class файл, то опять же есть такая возможность. Компилятор поддерживает сохранение байткода в файл.

К тому же для «компиляции» вашим методом нужно иметь на борту машины JDK, в то время как моей реализации внешние программы не нужны.
javac есть только в JDK (Java developer kit), а обычная Java (JRE) не имеет такой утилиты.
В принципе, можно подключить к проекту %JDK_PATH%\lib\tools.jar и у нас есть компилятор:

JavaCompiler compiler = ToolProvider.getSystemJavaCompiler();
Да тут скорее проблема, что JDK тянет за собой еще различные зависимости и намного тяжелее jre. Или tools есть и в jre?
Нет, tools нету в JRE.

Как вариант, просто скопировать tools.jar к библиотекам проекта. Он конечно большой по размеру (в JDK 1.8.05 — 18 Мб), но при большом желании можно повыкидывать оттуда javap, jstack, jmap, jps и прочие ненужные вещи.
Почему ваш компилятор выполняет лексический анализ, но не синтаксический? Правильный Brainfuck ведь предполагает наличие пар [ и ], это ограничение на синтаксис. Компилятор может генерировать разумные сообщения об ошибках, если встретит одинокий ] или незакрытый [.

Также можно добавить в компилятор генерацию дебажной инфы (исходный файл, метки строк). Тогда программы, содержащие +[>+] будут при падении ссылаться на нужное место в исходнике, можно будет исполнять код построчно и т. п.

Сам как-то на досуге писал компилятор Brainfuck в JVM, в котором такое реализовал: github.com/SBasalaev/jbfc
Потому что я не ставил для себя задачу писать дополнительные проверки «от дурака» и предполагал, что данные всегда корректны. Задача моя была написать простой компилятор.
Да, информацию можно добавлять, но я делал уклон на небольшую компактную реализацию, без подобных фич.
Не факт, что без синтаксического анализатора получилось проще.
Туда можно было бы вынести детектирование [+] и [-] вместе со всеми остальными оптимизациями.
Любое разделение тут сделано для абстракции, можно было бы написать всю компиляцию в один проход и получилось бы еще проще. Да и ту да же всунуть синтаксический анализ и добавление информации для отладки. Весь алгоритм в итоге получился бы онлайновым.
Sign up to leave a comment.

Articles