LINUX.ORG.RU

Написание собственного высокоуровневого ЯП

 , ,


0

2

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

Собственно, наткнулся я на функционально-распределенные Erlang и Elixir, и это оказались реально крутые языки. Однако мне кажется, что я смогу лучше - а если не получится лучше, то только прибавится уважение к тому, что есть, то есть везде одни плюсы.

Собственно, как с наименьшими потерями написать высокоуровневый язык? Я посмотрел на LLVM, QBE, FASM, GNU Assembler и другие крутые, продуманные вещи. И понял, что всё не то. После долгого поиска я задался правильным (на мой взгляд) вопросом - а на каком уровне абстракции ПО происходит вся высокоуровневая магия? И понял - уровень абстракции, интересующий меня - это уровень системных вызовов. Структура исполняемого файла, кодировка машинных инструкций, экспорт символов и релокации - это всё мне не интересно, интересна сама манипуляция данными, без раскуривания мануалов по AMD64 ISA. А с помощью какого инструмента проще, естественней всего взаимодействовать с системными вызовами? Да с помощью того, на котором и под который они были написаны - язык Си.

Итак, почему не генерить код на языке Си, а потом кормить компилятору? Как минимум, потому что хоть в Си и нет рантайма (параллельно запущенной системы, выполняющей служебные функции, например сборщик мусора), есть его подобие - стандартная библиотека. В ней аллокатор, в ней многопоточность, в ней много всего того, чего я бы хотел переписать по-своему. Так вот, почему не выдернуть с корнями libc и не написать свою, со стандартами Си не совместимую? Таким образом получаем полный контроль над системными вызовами, без нужды париться о низкоуровневых вещах и переносимости - язык Си всё делает за нас.

Вопрос - какие подводные камни? Насколько будут Си компиляторы терпеть мою LibC, функций стандартов Си не реализующую? И как бы вы подошли/уже подходили к задаче написания высокоуровневого ЯП?

Ответ на: комментарий от vM

Если это Пайтон 3, то в нем в идентификаторах разрешён Юникод. Видимо парсер воспринимает символ неравенства как идентификатор, но символ неразрешённый. В случае первого примера кода парсер пытается распознать операции меньше либо равно <= или побитового сдвига <<, но встречает не то.

Virtuos86 ★★★★★
()
Последнее исправление: Virtuos86 (всего исправлений: 1)

Зайди на irc канал #proglangdesign в фриноде обсуди

Можешь посмотреть мои потуги

https://bga.github.io/safejs/cMod.unit.html

https://bga.github.io/safejs/jsMod.unit.html

Страшный код на регекспах https://github.com/bga/safejs/blob/master/compile.js

bga_ ★★★★
()
Последнее исправление: bga_ (всего исправлений: 2)