В Umka, как в Go, разделителем является ';' — либо реальная, либо подразумеваемая (в конце строки). Так что просто удалить переносы строк нельзя, однако всегда можно заменить их на ';'. Впрочем, как заметил другой комментатор, какой-то разделитель всё равно нужен. Вы привели пример на Lisp, однако там в той же роли выступают скобки, причём скобка — парный символ, так что в общей сложности их оказывается больше, чем нужно для разделения.
Если уж искать в Umka препятствия к минимализации, то это будет необходимость указывать типы аргументов и результата функции — очевидная издержка статической типизации. Но тогда и само понятие о минимализации надо расширять и уточнять.
Umka пока не столь уж известен, чтобы я оскорбился его отсутствием в вашем списке :) Однако с первого прочтения я действительно не понял, какому именно требованию он не удовлетворил. И в целом, казалось странным, как эти требования оставили от пары сотен языков всего 8, причём довольно экзотических.
Трудно быть беспристрастным, когда сам являюсь автором языка Umka из упомянутого обширного перечня. Однако таблица со сравнением по одному лишь размеру файла кажется несколько странной, как и то, что в ней перемешаны процедурные и функциональные языки (неужели нет априорных предпочтений на сей счёт?).
Кстати, формально Umka вполне удовлетворяет перечисленным требованиям. Любопытно мнение автора, почему он не попал в итоговый список.
Спасибо! Думаю, мне стоит развить язык (например, добавив туда замыкания), прежде чем приниматься за описание внутренностей. Иначе буду выглядеть блёкло на фоне Crafting Interpreters. И да, собрать сообщество вокруг нового языка, если он не революционный, очень трудно. Скромное сообщество Umka пока помогло разве что протестировать интерпретатор на macOS и PowerPC и подготовить Makefile. Любопытствующих много, но когда ещё нет всего того обилия библиотек, какое есть для Python и Lua, практическая применимость языка страдает.
Это уже другой вопрос. Сначала — просто не хотелось заморачиваться с заполнением заголовков. Потом аппетиты выросли, но файл так и остался COM — однако уже многосегментный, да ещё и с 32-битным кодом (в смысле регистров, а не адресов). Затем родилась самокомпилируемая версия под Windows. А теперь — вообще новый проект с компиляцией в байт-код.
Примерно это я и делал. Только обходить загрузчик для этого вовсе необязательно. После того, как он отработал, я волен распоряжаться сегментными регистрами по своему усмотрению. Ни NTVDM, ни DOS Box не жаловался. И вообще, странно предполагать, будто кто-то будет следить за моими манипуляциями с сегментными регистрами после завершения работы загрузчика.
Вы про размер файла или про объём используемой памяти после загрузки? Файлов больше 64 кб быть не может. А примеров программ, занимавших больше 64 кб памяти, у меня в избытке. Посмотрите скриншоты с графиками и фракталами в моём посте по ссылке — это программы в формате COM, запущенные в DOS Box. Раньше они запускались и в штатном NTVDM в Windows.
Думаю, из пары десятков программ он обязательно на что-то ругнётся. Я сначала искал проблему в заголовках, потом — в «любительских» конструкциях в самом машинном коде. Однако если Microsoft заявляет, что применяет машинное обучение для отлова подозрительных файлов, то задача разработчика компилятора серьёзно усложняется: может быть, теперь даже сами авторы антивируса не смогли бы сказать, на что именно антивирус ругается.
Иногда проблема касается и профессионалов: разработчики Go тоже жаловались.
Остаётся добиться того, чтобы полученным файлом был доволен не только загрузчик Windows, но и все антивирусы. Я в своём старом проекте так и не смог надёжно победить Windows Defender, и каждую неделю отправлял очередную жалобу в Microsoft. Кажется, с этим столкнулись практически все разработчики любительских компиляторов под Windows.
Интересный проект, не первый раз о нём слышу. Но беглый просмотр вызывает некоторые сомнения (поправьте, если я заблуждаюсь): документация скудная; нет разобранных примеров; нет готовых дистрибутивов в виде DLL; непонятно, откуда импортируются функции стандартной библиотеки C (нужно тянуть за собой libc/msvcrt?); непонятно, что делать с нетривиальными частями виртуальной машины — например, сборщиком мусора.
Спасибо, очень понравилась первая ссылка — взгляд на проблему с другой стороны баррикад. Хотя некоторые утверждения там весьма поверхностные:
Lua — это стековая машина, и там, на самом деле, просто нечему тормозить.
На самом деле, начиная с версии 5, Lua перешла от стековой машины к регистровой и получила от этого большой прирост быстродействия. У меня один и тот же численный алгоритм на Lua 5 работал в 2-3 раза быстрее, чем на Lua 4.
Добавим сюда всякие задержки на сборке мусора, поиску метода по цепочке наследования — и окажется, что тормозить там есть чему.
А кстати, как бы вы обозначили эти проблемы, помимо быстродействия? Для большинства программистов проблем, кажется, и вовсе нет, когда под рукой Lua/LuaJIT (с последним только та проблема, что Майк Полл перестал им заниматься).
Сейчас это C/C++. Другие языки — при наличии совместимого ABI вызова динамических библиотек. Поскольку многие языки хотят так или иначе работать с DLL, это не должно быть препятствием.
Любопытно, что в обработке многомерных массивов Umka обошёл Wren, который считается в среднем чуть ли не быстрее Lua. Но похоже, циклы for и массивы в Wren хромают.
Про быстроту компиляции: для пользователей время компиляции измеряется от начала разбора исходника до получения исполняемого файла. Если V компилирует только в C, то для пользователей он в принципе не может быть быстрее GCC/MSVC. Пример по-настоящему быстрой компиляции (со своей ценой, разумеется) — это старые версии Delphi.
Про управление памятью: пока локальные массивы выделяются в куче и вообще никак и никогда не освобождаются — я не могу говорить о прогрессе.
Про портирование Doom: насколько я вижу, из всех файлов исходников Doom выбирается ровно один (где 3/4 занимают объявления структур и перечислений), конвертируется из C в V, а затем, при компиляции — из V в C. Этим портирование исчерпывается.
Если уж искать в Umka препятствия к минимализации, то это будет необходимость указывать типы аргументов и результата функции — очевидная издержка статической типизации. Но тогда и само понятие о минимализации надо расширять и уточнять.
Umka пока не столь уж известен, чтобы я оскорбился его отсутствием в вашем списке :) Однако с первого прочтения я действительно не понял, какому именно требованию он не удовлетворил. И в целом, казалось странным, как эти требования оставили от пары сотен языков всего 8, причём довольно экзотических.
Кстати, формально Umka вполне удовлетворяет перечисленным требованиям. Любопытно мнение автора, почему он не попал в итоговый список.
map/filter/reduce) в Umka 0.3 всё же появились:Для полного счастья не хватает замыканий, но это дело трудоёмкое. Да и так ли они нужны?
Иногда проблема касается и профессионалов: разработчики Go тоже жаловались.
На самом деле, начиная с версии 5, Lua перешла от стековой машины к регистровой и получила от этого большой прирост быстродействия. У меня один и тот же численный алгоритм на Lua 5 работал в 2-3 раза быстрее, чем на Lua 4.
Добавим сюда всякие задержки на сборке мусора, поиску метода по цепочке наследования — и окажется, что тормозить там есть чему.
forи массивы в Wren хромают.Про управление памятью: пока локальные массивы выделяются в куче и вообще никак и никогда не освобождаются — я не могу говорить о прогрессе.
Про портирование Doom: насколько я вижу, из всех файлов исходников Doom выбирается ровно один (где 3/4 занимают объявления структур и перечислений), конвертируется из C в V, а затем, при компиляции — из V в C. Этим портирование исчерпывается.