p.s.: компилятор, кстати, дубовый и адово рекурсивный. даже `IF/ELSIF` через рекурсию парзится. так проще, удобней, и меня вполне устраивает сегфолт, если стек закончился.
алсо, тайпкасты будут. но через `CAST(typename)(expr)`. AO-шное `typename(expr)` мне не нравится: грепнуть все касты сложнее. ;-)
и `LSH` не нравится. будет для легаси кода, но рядом будут и `SHL`, `SHR`, `SAR`.
надо пилить массивы, открытые массивы, и аттачить ко всему type tag'и. тогда можно будет приступать к GC.
p.p.s.: у Nanojit есть опкоды для арифметики с проверкой переполнения, кстати. использовать их, правда, не очень удобно. я пока не решил, нужна ли эта проверка вообще.
пуристы мне скажут, что конечно нужна. это Правильно и Хорошо. на что я им отвечу, что оберон даже локалы не инитит, так что прен-цен-дент наплевательства есть. `INTEGER` — это прибитое гвоздями знаковое 32-битное целое, и на это можно полагаться в ручных проверках переполнения. и я вам скажу, что намного более чаще чем нет эти проверки не нужны. так что я склоняюсь к тому, чтобы их если и делать, то опциональными. не опцией компилятора, а встроеной функцией или новым оператором.
как я уже где-то писал, надёжность оберона не в том, что он магически защищает программиста от алгоритмических ошибок программиста, а в том, что он не позволит сделать самые неприятные штуки — типа выхода за пределы массива и порубания хипа на лапшу. это всё ещё не освобождает от ручной проверки диапазонов, NIL и прочего. точно так же и переполнение интов надо проверять (если надо). в отличие от той же сишечки — переполнение индекса массива поймает range checker, например.
ещё никак не могу решить, нужен ли мне дурацкий юникод по-умолчанию. склоняюсь к мысли, что нафиг не нужен, и CHAR следует делать восьмибитовым целым без знака. разбазаривать четыре байта на ерунду — это перебор. в два байта юникод давно не влазит. и все нормальные API всё равно заточены на utf-8. так что эксперимент с большими CHAR-ами я считаю провалившимся. надо — будет LONGCHAR.
ах, да. FOR не будет. ну не нужно оно. и LOOP не будет: тоже не нужно. лучше попробую изобрести красивый синтаксис для итераторов Парнаса. WITH будет. и CASE будет как в CP, а не как в O7.
и RETURN прибивать гвоздями не буду, скорее всего. это — опять таки — идеологически правильно, но я довольно часто пишу код типа:
Код:
PROCEDURE Smth;
BEGIN
IF wasDone THEN RETURN; END;
<do-something>
wasDone := TRUE;
END Smth;
нувыпонели. да, это криво с точки зрения Чистого Структурного. но лишний отступ, как по мне, читается намного хуже.
также подумываю над тем, чтобы повысить точку с запятой до терминатора. она сейчас опциональна (как в CP), но камон. я считаю, что её «сепараторность» — тяжёлое наследие паскаля. там это имело смысл для `if smth then smth else smth;`. в оберонах это смысла не имеет, и навсегда закроет холивар «ставите ли вы точку с запятой после последнего statement-а?»
а `TRUE` и `FALSE` повышены до ключевых слов. потому что тоже камон.
Вход
FAQ
Поиск
вообще, у меня переполнение не проверяется в том числе и парзером, и сворачивалкой констант (потому что это делается тем же `resolveExpr()` что и весь остальной код).