Pull to refresh

Comments 13

Какой процент языков программирования создаётся по этому принципу?
Как-то не очень понятен вопрос. По какому принципу?
Сколько языков имеют компилятор на LLVM? Очень многие: C, C++, Objective C, Go, Rust, D, и многие другие.
Просто здесь не очень корректно само название (это перевод): должно быть «создание компилятор языка программирования», потому что для создания собственно языка достатоно описать его синтаксис и семантику, но без компилятора он вряд ли кому-то будет нужен.
Человек выше просто обобщенно спросил по поводу ЯП, имея ввиду конечно же именно компиляторы. Я бы за него хотел спросить, пользуясь случаем. Сколько создается компиляторов именно на LLVM для своих ЯП, просто языков в наше время довольно много, неужели все проходят через этот путь, ибо лично мне кажется эта задача довольно сложной. Или я что-то упустил? И да, имеются ли какие-нибудь альтернативы LLVM тогда? В наше время много языков строятся на базе JS, у них там какая-то своя машина более простая, или что? Просто часто создается впечатление что написать свой ЯП — это как обвертку какую-то написать, не более. Спасибо.
Создание компилятора на LLVM не сложнее, чем другие решения. Насчёт языков на базе JS я не в курсе. У меня в публикациях можно найти переводы статей, как сделать компилятор ЯП для простого ЯП на LLVM, это довольно просто.
LLVM позволяет вам сделать компилятор в нативный код сразу для множества целевых платформ (по количеству бэкендов LLVM). JS этого не позволяет, очевидно.
Спасибо. Для меня сложность заключается в том, что языки имеют очень много языковых конструкций, и все их нужно скормить компилятору. Например, первый в мире в классическом понимании язык PL/1, вышедший в 78 году, уже на тот момент имел столько конструкций, что до сих пор не существует компилятора, который может обработать их все, а современные языки не менее сложные, в них даже циклов несколько (for, while, foreach), я уж не говорю о конкретных реализациях, например в Java очень удобно работать с потоками. Там любой поток представлен в виде абстрактного класса InputStream и не нужно уточнять что это за поток (а это может быть что угодно — FileInputStream, ZIPInputStream (да, Java умеет работать с ZIP из коробки) и т. д., и все это нужно каким-то образом реализовывать. И это только частный случай, я даже не беру работу с консолью, десктопом в виде Qt, GTK+, которые в идеале нужно интегрировать, ибо всем хочется чтобы на языке можно было писать все, а не только web-странички клепать. Вот она сложность. Нет, не знаю, может я что-то не так понял, но пока я все это вижу так, вот я и удивляюсь что обычные разрабы создают свои ЯП, что возможно только крупным корпорациям по понятным причинам.
Да, написание полноценного парсера для современного ЯП может быть очень сложной задачей. Но и её можно упростить, если использовать генераторы, позволяющие описывать грамматику в BNF (EBNF), например, ANTLR.
Вот-вот, я поэтому и думал что есть что-то проще, учитывая количество языков и комменты под очередной такой статьей, мол, и чем он от Паскаля того же отличается, очередной проходной язык, только десять минут времени потерял зря) Не, может не так много, но с десяток наберется. В общем, зажрался народ по-ходу)

P. S. И да, за переводы огромное спасибо, вы не представляете себе какое важное дело вы сделали, ибо по сути в рунете вообще нет материалов по созданию своего ЯП, да и не удивительно никто не занимался даже их переводом, ибо даже этот мануал впервые перевел только один человек, но осилил только три первые главы, ибо уж очень материала много. Вообще невероятно конечно, я коммент могу оставить раз в три дня, больше не успеваю, а тут человек десять глав в одиночку перевел…
Спасибо за отзыв.
Я перевёл только вторую половину, первую перевёл другой человек.
В «рунете» что-то такое искать бесполезно, нужно сразу искать на английском языке.
Да-да, я и говорю что тот человек первые три части перевел. А про рунет да, так и есть, благо я на инглише неплохо читаю на самом деле, но это медленнее получается по времени, увы, но часто выбора нет, это да…

P. S. А, семь глав перевели, да, сути это не меняет)
Владимир, прошу прощения, о какой версии llvm тут идёт речь? Дело в том что серия статей начиналась в 2011-м году, а наверняка с тех пор много чего поменялось. Хотел немного в это поиграться, просто для общего развития. В результате сейчас не знаю, какую версию llvm качать.
Да, в 2011 году перевод начал Amper, части 1-5. Части 1-10 переведены мной (10-я будет скоро).
Лучше всего качать всегда последнюю версию (сейчас это 5.0). Отличия возможны, но в первых частях, где идёт описание лексического анализатора, парсера и AST, на сам LLVM ничего не завязано, там отличий быть не должно. Какие-то отличия могут быть в частях 3-5, где происходит генерация LLVM IR и подключение JIT, но в таких случаях лучше всего смотреть в оригинальный исходник проекта (он входит в общее дерево исходников LLVM) и в оригинальный текст документа.
Если будут вопросы, обращайтесь, постараюсь ответить, если смогу.
Поправка: Части 1-10 части 6-10
Sign up to leave a comment.

Articles