Теперь и скрипты могут быть статически типизированными

[waqur]

Crack — попытка построить статически типизированный язык программирования для написания скриптов. Crack идеологически близок к C++, компилирует скрипт перед выполнением без сохранения на диск (с помощью LLVM), и передаёт управление машинному коду. Так что работать должно быстро.

Crack не претендует на то, чтобы быть интерактивным шеллом: если нет файла с полным текстом скрипта или файл не проходит синтаксический анализ — следует реакция типа "давай, до свидания".

Управление памятью автоматическое, на основе подсчёта ссылок. Циклические ссылки и утечки памяти, ими вызванные шерифа никоим образом не беспокоят — это забота программиста. Безопасная модель памяти, в том числе нет сырых указателей. Функции в языке — жители первого класса. Есть классы и шаблонные классы (их аргументы задаются в квадратных скобках, чтобы не сводить с ума лексический анализатор). Есть автоматический вывод типов (здесь на синтаксис нового языка больше влияния оказал Go, чем C++11). Есть исключения. Аналоги коллекций STL являются встроенными типами языка. Строки иммутабельны, как в Go.

Авторам языка хватило ума не навязывать программистам стиль расстановки отступов, фигурных/круглых скобок и переносов строк. Авторам языка хватило ума не делать автоматическую расстановку точек с запятой в конце инструкций.

http://www.mindhog.net/~mmuller/projects/crack/Manual-0.7.html
https://code.google.com/p/crack-language/

Многопоточность, как тяжёлая, так и лёгкая, пока не проработана. А зачем в скриптах многопоточность?

Comments

[cd-riper.livejournal.com]

но зачем? :)

[waqur.livejournal.com]

1) just for fun (профита не будет, это open source)
2) для поклонников статической типизации (типа меня), которые мечтают её видеть даже в скриптах
3) для того, чтобы вывозить питонистов и рубистов фейсом в дерьме, когда выяснится, что оно работает быстрее раз в 60
4) потому что есть LLVM, а ведь это 90% компилятора -- прикрутить к нему свой лексер и парсер это уровень дипломной работы магистра -- ну вот все и ломанулись изобретать свои языки программирования
5) чтобы проверить на практике парадигму управления памятью исключительно через подсчёт ссылок без GC (некоторые теоретики утверждают, что из-за кольцевых ссылок будут постоянные массовые утечки памяти, Адъ и Израиль, написание реально полезного кода станет вообще почти невозможным и языку позарез нужны слабые ссылки; другие теоретики говорят что фигня всё это и проблема надумана, и в общем если специально не выделываться и не искать на свою ж*пу приключений, то всё будет нормально) -- как оно на самом деле, практика покажет

[cd-riper.livejournal.com]

насчет пятого пункта -- я смотрю ты не в курсе про питон.

и возникает вопрос по терминологии -- а что такое скриптовый язык вообще.

[waqur.livejournal.com]

ну, в Питоне вроде есть GC для кольцевых ссылок? насколько я помню, её там не было изначально, но со временем её таки сделали, именно для этого случая

скриптовый язык -- язык, для которого понятие "файл с исходным кодом, который редактируется программистом" тождественно понятию "исполняемый файл в смысле вызываемости через execve(2)"

[cd-riper.livejournal.com]

правильно, в питоне ее долго не было, соответственно опыт такой уже был. причем, думаю, в сильно большем масштабе.

компиляцию от тебя прячут -- все, язык становится автоматически скриптовым?

[waqur.livejournal.com]

конечно

не надо возиться с мейкфайлами или их аналогами, флагами компиляции, autoconf-скриптами и прочим безобразием

экономия времени


Кстати, мы недавно в нашей системе сборки внедрили систему кэширования для ускорения компиляции большого С++ного проекта. Результат препроцессирования (*.i-файл) + флаги оптимизации хэшируются функцией MD5, получается имя файла, к которому добавляется .o или .obj и в таком виде пишется в отдельную папку. Таким образом, можно срезать путь при компиляции - провести только препроцессирование и сразу достать готовый объектный файл из кэша, если исходники не изменились. Далее проводим эксперимент (для старой и новой системы сборки): три сборки, чтобы разогреть кэши ОС, затем контрольная сборка с замером времени. Добавление объектного кэша даёт ускорение на контрольной сборке, но небольшое: примерно 50%. Вывод таков: C++ный компилятор половину времени проводит в активном дисковом вводе/выводе в контексте препроцессора. Даже для hello world .i-файл имеет размер порядка мегабайта.

Запаковать бы все стандартные заголовочные файлы в какой-то архив, чтобы снизить количество дисковых seek-ов при сборке. Или прямо в бинарный файл компилятора, в пред-разобранном виде. Хотя какой-нибудь #define int char перед #include исключает такой подход.

В общем, авторам новых языков есть где развернуться, особенно в сфере замены препроцессора. В crack'е например, очень красиво макросы сделаны: http://www.mindhog.net/~mmuller/projects/crack/Manual-0.7.html#the_standard_annotations

[cd-riper.livejournal.com]

ну, импорт через .h файлы это решение образца 60-х годов.
сегодня -- сказать, что это полный пиздец, это ничего не сказать.

[waqur.livejournal.com]

а ещё можно пол-юникса переписать на таких скриптах