из «весомых» дополнений — расширеные призраки, 'recurse' local var, стабильная работа после сборки новыми gcc (без volatile в стратегических местах оно косорылило), корректный шатдаун с очисткой всей памяти и вызовом призрачных деструкторов, 'do … while', '++/--', 'while … elsif …', загрузка библиотек из .so, ещё всякие мелочи. 64-bit clean (но это не моя заслуга, я просто не сумел достаточно поломать оригинал). вычищены мелкобаги (и крупнобаги с памятью).
по мере сил старался не угробить то, что работало, починить то, что не работало и добавить то, чего мне не хватало.
а, да: ANSI C пошёл сосать хуй и сладострастно чмокать, теперь для сборки нужен GCC.
скриптовые языки. то, чего делать в них не надо (и то, что надо).
1. делать скриптовый язык без замыканий и первоклассных функций — ебанатизм; больший ебанатизм, пожалуй — это убрать из него GC, но до такого, надеюсь, ни один дебил не додумается.
2. делать жёстко типизированый скриптовый язык — полный ебанатизм. это потянет за собой или идиотский синтаксис для генериков, или тип any, который всё равно все будут использовать. если уж в жопе играет типизация — делайте её опциональной.
3. очень желательно иметь в языке тип, способный хранить int64 (в narrow будет добавлен, но не сразу).
4. прототипная система объектов рулит. она и сама по себе рулит, но — никто не забыл, что язык скриптовый?
5. да, как бы это не было противно — c-like синтаксис. ну что поделаешь, вот такая вот хуйня.
6. желательно — многопоточность. или хотя бы «многодвижковость».
7. flex? bison? утилита 'хуйпизда'? забыли сразу.
8. boehm GC? ваше место в биореакторе.
9. мелкие нумерики боксируются? вы ебанулись, штоле?
10. TCO — очень желательно, но совсем не обязательно. в narrow их нет, например. и вряд ли будет, потому что усложнит (и, возможно, замедлит) VM.
11. блядь, не забываем, что язык скриптовый (если можно встроить — он скриптовый, и не ебёт), поэтому должна быть возможность прервать исполнение после n инструкций, или по истечении некоторого времени, или по внешнему событию. с возможностью продолжить с того же самого места.
12. вменяемый API, наверное, вообще упоминать не стоило?
13. как бы этого не хотелось некоторым, но вот наличие «юникода из коробки» нахуй не надо. достаточно библиотеки для работы с utf-8 строками.
14. желательна библиотека для интроспекции и дизасма кодов VM.
15. сообщения об ошибках должны указывать хотя бы файл и строку, а не «ой, я пизданулась по адресу VM 0x029a». stack trace — вообще хорошо.
16. желательно, чтобы исходники можно было скармливать при помощи абстракции «поток ввода», частный случай которой — буфер в памяти.
17. блядь, да идите нахуй со своими многомегабайтными исходниками и скомпиленым кодом, который весит больше самого приложения!