Спасибо большое! 🙏 Мотивация — это главная проблема. У меня тоже было несколько попыток, которые забрасывал на полпути. Сейчас решил довести до конца хотя бы минимальный рабочий прототип: парсер + интерпретатор + базовый набор библиотек. Если интересно — подписывайтесь, буду выкладывать прогресс. Возможно, вдохновлю вас начать свой проект! 😄 Удачи и вам!
Спасибо за подробный фидбек и за карму! Рад, что в целом зашло. По вашим замечаниям: 1. Разделители vs ключевые слова (swx/sx/wx вместо ;) Согласен, что ; — проверенный временем подход, и проблемы JS с ASI (Automatic Semicolon Insertion) и Go с принудительной вставкой ; после return — хорошие антипримеры. Но здесь идея была в другом: ключевые слова-границы работают не как "разделитель между инструкциями", а скорее как маркеры контекста — они сообщают парсеру (и читателю), какой тип логического блока начинается/завершается. Это ближе к подходу Lisp (где скобки определяют структуру) или Ruby (where do/end обрамляют блоки), чем к С-подобному ;. Проблема return в JS/Go возникает именно потому, что ; — невидимый разделитель, который компилятор вставляет по своим правилам. Здесь же границы явные и читаемые, поэтому такой класс багов исключён by design. Но замечание принимаю — если язык будет расти, вопрос "а не добавить ли ; как опциональный разделитель внутри блоков" точно встанет. 2. => в определении функций (sx) Тут полностью понимаю скепсис. => действительно стало мемом 2010-х (CoffeeScript → ES6 → Kotlin → Dart...). В моём случае => используется не как "стрелочная функция" в духе JS/Kotlin, а как визуальный разделитель между сигнатурой и телом: sx myFunc(a, b) => { ... } ^сигнатура^ ^тело^ Можно было обойтись просто {}, как в C/Go: sx myFunc(a, b) { ... } Но тогда возникает неоднозначность: { после ) — это начало тела функции или объектный литерал / блок данных? => убирает эту двусмысленность для парсера и для человека. Если коротко: => здесь не дань моде, а disambiguation token. Но если предложите более элегантное решение — с удовольствием рассмотрю, язык ещё в стадии формирования. Ещё раз спасибо за конструктивный разбор! 🙏
Да, пока так :) В демо-версии сейчас слишком много промежуточных файлов и настроек для ВМ, которые нужно постоянно перекидывать. Чтобы не мучиться с конфликтами путей при каждой итерации в технической части, залил архивом. Это временно, скоро причешу репозиторий и разложу всё по полочкам!
Спасибо большое! 🙏 Мотивация — это главная проблема. У меня тоже было несколько попыток, которые забрасывал на полпути. Сейчас решил довести до конца хотя бы минимальный рабочий прототип: парсер + интерпретатор + базовый набор библиотек. Если интересно — подписывайтесь, буду выкладывать прогресс. Возможно, вдохновлю вас начать свой проект! 😄 Удачи и вам!
Спасибо за подробный фидбек и за карму! Рад, что в целом зашло. По вашим замечаниям: 1. Разделители vs ключевые слова (swx/sx/wx вместо
;) Согласен, что;— проверенный временем подход, и проблемы JS с ASI (Automatic Semicolon Insertion) и Go с принудительной вставкой;после return — хорошие антипримеры. Но здесь идея была в другом: ключевые слова-границы работают не как "разделитель между инструкциями", а скорее как маркеры контекста — они сообщают парсеру (и читателю), какой тип логического блока начинается/завершается. Это ближе к подходу Lisp (где скобки определяют структуру) или Ruby (where do/end обрамляют блоки), чем к С-подобному;. Проблема return в JS/Go возникает именно потому, что;— невидимый разделитель, который компилятор вставляет по своим правилам. Здесь же границы явные и читаемые, поэтому такой класс багов исключён by design. Но замечание принимаю — если язык будет расти, вопрос "а не добавить ли;как опциональный разделитель внутри блоков" точно встанет. 2.=>в определении функций (sx) Тут полностью понимаю скепсис.=>действительно стало мемом 2010-х (CoffeeScript → ES6 → Kotlin → Dart...). В моём случае=>используется не как "стрелочная функция" в духе JS/Kotlin, а как визуальный разделитель между сигнатурой и телом: sx myFunc(a, b) => { ... } ^сигнатура^ ^тело^ Можно было обойтись просто{}, как в C/Go: sx myFunc(a, b) { ... } Но тогда возникает неоднозначность:{после)— это начало тела функции или объектный литерал / блок данных?=>убирает эту двусмысленность для парсера и для человека. Если коротко:=>здесь не дань моде, а disambiguation token. Но если предложите более элегантное решение — с удовольствием рассмотрю, язык ещё в стадии формирования. Ещё раз спасибо за конструктивный разбор! 🙏Да, пока так :) В демо-версии сейчас слишком много промежуточных файлов и настроек для ВМ, которые нужно постоянно перекидывать. Чтобы не мучиться с конфликтами путей при каждой итерации в технической части, залил архивом. Это временно, скоро причешу репозиторий и разложу всё по полочкам!