Комментарии 24
Если статья о том, как писать велосипедный ЯП в учебных целях, то нужно больше информации именно про внутреннее устройство языка и компилятора, это было бы интересней.
class MyClass:
var a, b
proc Create, Free
func SomeFunction
endвместо
interface MyClass{int a,b {get;set;}void Create();void Free();int SomeFunction();}.
Забавненько!
Циклы "while" и "until" отличаются только способом обработки условия. И, по всей видимости, оба являются циклом с предусловием (хотя в упомянутом Паскале — цикл "repeat...until" — это цикл с постусловием).
Цикл "for" явно Сишного вида, и значит — тоже цикл с предусловием...
А где же в "новейшем" языке цикл с постусловием?
Т.е., условие мы пишем в начале цикла, а по факту проверяется оно в конце?
ИМХО: это будет путать программиста, привыкшего ставить условие там (в начале или конце), где оно должно проверяться.
Раз уж Вы решили дифференцировать циклы по истинности/ложности условия (while/until), то стоит добавить ещё 2 разновидности:
1) loop...while ( условие );
2) loop...until ( условие );
%-)
P.S.:
Замена "this->" на знак $ мне понравилась — приятный сахарок :)
Но выглядит лишним слово "end" после каждого "case" в операторе "switch"...
Хозяин – барин.
Да все будет, как руки дойдут… :)
Теперь об изменениях:
— Переделал until цикл, теперь вместо него цикл whilst — можно сказать, что это копия while, только с пост-условием.
Изменения залил на github.
Как автор ЯП, который посвятил этой теме много времени, можете прокомментировать, почему выбрали концепцию-со-сборщиком-мусора?
Меня (как системного программиста на С++ и С, внимательно наблюдающего за Rust), удивляет это направление )) Почему (особенно, учитывая эту великолепную статю), всё меньше людей задаются вопросами, как создать лучшуюю-RAII, или ещё-лучшую модель типов, или ещё-лучшие-zero-cost-abstractions, или ещё-лучший-хаскелл? ))
В отличии от других ЯП, таких как Python, Perl, JS, Ruby и т.д., сборщик мусора у моей ВМ реализован через метки, т.е. переменная помечается, как мусор сразу при объявлении. Сборщик мусора имеет на момент вызова готовый массив указателей на мусор в памяти.
Основная идея заключалась в том, что даже в нетипизированном языке сборка мусора должна лежать на плечах программиста и быть полностью ему подконтрольна. Используя gc() программист на 150% уверен где, когда и сколько памяти будет освобождено сборщиком мусора.
Также изначально затеивал такую архитектуру, как небольшую оптимизацию. Ведь сборщику мусора вообще не нужно напрягаться, чтобы исправно выполнять свою работу.
for(x?=0; x<10; x++):
gc()
endИли вот вызвали мы функцию, а в ней позвали gc — соберёт ли он весь мусор в проекте или только мусор внутри функции? Если первое — gc будет запрещено звать в любой библиотеке. Если второе, то можно и автоматически его звать при каждом выходе из скоупа.
Вот тогда он был бы реально полезен автору.
- ИМХО. Я бы поменял местами $ и @. Например в Ruby и Crystal используются именно @ как замена конструкции
this., а '$' чаще встречается именно в именах переменных. - Вызвав
Free, я удаляю значения из памяти даже если они используются в другом месте? - Почему
gc()пишется со строчной буквой, аFree()с прописной? - Соглашусь с автором выше, ничего принципиально нового в языке не вижу. Как учебный язык ок, но, на мой взгляд, стоит добавить какую-нибудь изюминку.
- Лично мне больше нравится $ на месте this-> :)
- Ну да. На то это и Free, чтобы память освобождать.
- Можно писать с каких угодно букв. Язык не придирчив к этому.
- Как по мне, некоторые вещи, которые я реализовал являются весьма необычными, например поддержка многопоточности и всего необходимого для неё функционала прямо из коробки и без использования костылей… Но об этом я наглядно расскажу чуть позже, как найду время для написания очередной статьи.
Нельзя же рассматривать плюшки языка, не описав перед этим синтаксис языка и базовые вещи. Так что эту статью можно считать вводной… Наверное...
2) С тем, что в последнее время получил развитие отказ от ручного управления памятью, выглядит очень опасно. Нужно как-то ограничить. Например разрешать вызов free только из контекста функции main, чтобы управление всегда происходило явно. Возможно, через контроллер, определяемый программистом на уровне приложения, а не библиотеки.
4) Тут я с вами категорически не соглашусь, сначала нужно дать что-то читателю, чтобы вызвать у него интерес. Тогда он и неинтересные части прочтет.
Mash, основы языка