Я думаю, что мы все можем относиться к мему слева. Мы все ждем, пока наша программа скомпилируется (или чья-то еще), и продолжаем думать: «Вот оно. Это провалится». И иногда это так. Но иногда (к счастью) это не так. Затем мы обнаруживаем ошибку (или две, или три), и мы все знаем, как это происходит.
Однако этот «стресс» только усиливается, когда вы используете написанный вами компилятор. Затем вам также нужно беспокоиться о том, что сам компилятор выйдет из строя, выведет файл записи (будь то сборка, исполняемый файл, объектный файл и т. д.), и если ваш тест программа работает.
В большинстве случаев этот стресс возникает на последних этапах получения минимально работающего компилятора. Генерация кода. О, кошмар, который представляет собой генерация кода. К счастью, теперь у нас есть такие библиотеки, как LLVM и B3(хотя B3 все еще довольно новая).
Так в чем проблема, спросите вы, если у нас уже есть библиотеки для работы с этим материалом? Ну, во-первых, документация для этих систем ужасна (просто посмотрите на Quora причины отказа от использования LLVM). Кроме того, эти библиотеки сильно оптимизированы для определенного типа языка (а именно, C/C++, процедурного с небольшой долей объектной ориентации), поэтому, если вы хотите создать язык динамического программирования с утиным типом, вам не повезло.
Зачем создавать что-то новое?
Почему бы нам всем не смириться с LLVM? Что ж, у LLVM есть еще несколько юридических проблем. Подавляющее большинство активной разработки LLVM финансируется Apple, Google и Qualcomm. LLVM незаметно становится стратегией для компаний по утверждению своей собственной интеллектуальной собственности в качестве отраслевого стандарта.
Возьмем, к примеру, Go. Go полностью принадлежит Google, и LLVM поддерживает его как первоклассный интерфейс. Однако использование реализации Go в LLVM подразумевает принятие условий Google для использования Go.
Я полагаю, что блестящий, но злой адвокат мог бы использовать эти термины, чтобы найти способ создать проблемы почти для любого пользователя Go.
Кроме того, другие LLVM-подобные библиотеки имеют очень мало документации или очень новые (например, B3).
Так зачем создавать новый, если уже есть в разработке? Зачем перенасыщать рынок? Это подводит меня к следующей причине разработки YALT (которая, кстати, расшифровывается как Yet Another LLVM-Like Thing): образовательные цели.
Кажется, что кто-то вроде меня многому научился бы, разрабатывая что-то подобное. Не поймите меня неправильно, я знаю, как работают некоторые вещи (я занимаюсь созданием макета компьютера и сделал несколько эмуляторов/виртуальных машин). Но я мало что знаю о методах оптимизации или генерации кода внутреннего компилятора (BCCG).
При этом меня не волнует, широко ли используется этот проект. Я был бы крут, если бы это было так, и за этим стояла небольшая команда участников, но это не моя цель здесь.
Чем будет отличаться YALT (еще одна LLVM-подобная вещь)?
Вам нравится моя аббревиатура? В любом случае, цель YALT — не быть копией LLVM. Его цель — стать легкой, универсальной серверной библиотекой компилятора и решить некоторые проблемы, связанные с LLVM. Я перечислю здесь три.
Во-первых, ошибки LLVM сами по себе. У вас нет возможности увидеть ошибки и действовать соответственно. LLVM просто выручает всю программу.
Во-вторых, это оптимизации. LLVM автоматически оптимизирует ваш код, как будто завтра не наступит (по крайней мере, мне так сказали). Отключить это довольно сложно, и оптимизации в основном предназначены для языков, подобных C/C++ (Rust, однако, выполняет свои собственные оптимизации, а затем передает оптимизированный код в LLVM).
В-третьих, насколько сложно взаимодействовать с API, если только вы не хотите тратить время на возню с компиляторами, заголовками, библиотеками и т. д. это не то, что вы хотите делать. Не предпочтете ли вы более легкий путь?
Можно мне тоже всему этому научиться?
Конечно! Просто оставайтесь с нами в репозитории YALT Github и посмотрите, что должен завершить каждый коммит.
