OberonCore

добавил реимпорт констант (в следующем коммите немного украсивки кода). тот же компилятор таскает за собой простыни констант, и очень легко ошибиться, поправив их не везде. ошибка, кстати, там уже была: `guarded` кое-где определено как 10, а кое-где как 8. потому сделал такое:

нувыпонели. и почистил немного код компилятора, сделав почти везде реимпорты. сложил все константы в DevCPT: не самое лучшее место, зато его импортируют все подряд. пусть лежит там. естественно, снежинка после имени поддерживается, так что реимпорт можно опять экспортировать. ;-)

Не думаю, что это произошло потому что в языке не было переимпорта. Ведь
Это не что-то выходящее за рамки в языке, совсем не пытающемся сэкономить на каждом символе. Просто наговнокодили.

я сильно подозреваю, что во-первых, копипаста срезала немного времени компиляции (таки оно около полуминуты собиралось, дешёвый метод срезать пол-секунды, например,— не так уж и бесполезно). и во-вторых (что, мне кажется, главнее) — в редакторе оберона не было поддержки регулярок. поэтому средствами редактора такую трансляцию не сделать, а писать транслятор им стало лень.

но в целом вы правы, скорее всего: OP2 вообще местами написан довольно неряшливо. не так чтобы совсем уж плохо-плохо, но. омики тоже его чистить не стали, потому что особого смысла нет: он отлажен, он работает. я вот по той же причине ничего глобально там не рефакторю: оно работает же.

а насчёт особого синтаксиса — я сначала и сделал, как вы написали. но оно выглядит очень некрасиво: тупо стена текста, всё сливается. я и подумал, что раз руки у меня уже всё равно развязаны, то почему бы не сделать, чтобы выглядело поаккуратней.

на самом деле такую же фигню надо бы и для типов привинтить. не потому что оно сильно надо, а просто для единообразия: раз в одном месте конструкция работает, то было бы логично и в другом её поддерживать. но я пока в сомнениях, потому что оно и здесь решает задачу, которая встречается довольно редко. по факту, мне, кроме как в компиляторе, больше нигде такое количество констант таскать из модуля в модуль не приходилось. (оно и в компиляторе в таком количестве не нужно, авторы просто копипастили весь кусок.)

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

омики вроде специально не делали. вместо них завезли редукторы, которые даже лучше т.к. ресурсы освобождаются явно и совсем даже не обязательно которые контроллируются gc.
бесит на самом деле. иногда в биндах надо делать простенькие обёртки или портировать сишные макросы. приходится размазывать по нескольким модулям, вместо того что бы всё держать в одном.

добавил в StdInterpreter простенькую конверсию типов. REAL я ещё до этого добавил, а теперь сделал конверсию интов в более узкие или широкие инты, или в реалы. так что теперь можно из коммандера позвать, например, `StdLog.Int(666)` или `StdLog.Real(666)`. и даже `StdLog.Real("666");`, а почему нет? интерпретатор, всё-таки, можно немного и ослабить правила. числа в строки, впрочем, не преобразуются, потому что к этому моменту оригинальная запись уже утеряна.

в интерпретаторе, кстати, можно в качестве внешних кавычек использовать бэктики (`), а для строк подходят и одинарные, и двойные.

а мне не надо явно, мне надо, чтобы указатель на View этот самый View не якорил, и превращался в тыкву, если View помер. ;-)

вот тут я не уверен, что стоит менять. сейчас склоняюсь к мысли, что намного лучше спрятать внешние импорты в модуль, в каталог с соответствующей архитектурой; а кода в таком модуле не надо. и добавлять архитектурно-независимый модуль-обёртку, если необходимо.

а почему бы, собственно, и да?

в смысле, StdInterpreter теперь умеет считать простенькую математику. нет, работу с переменными делать не буду. наверное… ;-)

само собой, это автоматически означает, что `Dialog.Call()` тоже умеет, потому что он использует StdInterpreter как раз.

не, ну гулять — так гулять! `ABS(COS(PI)) + PI` — а почему бы и да. в конце концов, я же хотел калькулятор — так вот он.

больше нельзя переопределять глобальные константы и типы. во-первых, это защищает от переопределения стандартных типов и констант. (`CONST TRUE = FALSE;`, `TYPE INTEGER = BYTE;` — ни-ни!) а во-вторых, запрещает перекрытие глобалов в процедурах.

второе получилось нечаянно, но мне нравится. помимо большей строгости это решает проблему со штуками типа:

вот тут второе `APtr` — оно чем должно быть? а фиг его знает, репорт не говорит. вместо чтобы выдумывать сложные правила — проще запретить нафиг. вообще, перекрытие глобальных имён — это плохо, 'пнятненько?

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

для переменных такая проверка не проводится: мне кажется, такие перекрытия всё же стоит оставить.


p.s.: собственно, запретил перекрытия отцовских т. и к. во вложеных процедурах. так хорошо, так правильно.

это одна из фич, которая НЕ отключается модификатором `IN ComponentPascal`. простите, но я считаю подобный код очень грязным в любом случае. во фрэймворке такая ерундень встречается только в StdCoder. а, и ещё Host/Win очень грязный был.

добавил опциональные `END IF` и подобные. чота сначала не сообразил, и сделал кучу новых кейвордов (`ENDIF`, etc.). а потом как сообразил! если за `END` следует другой оператор, то там должна быть точка с запятой, так что `END IF` парзится вполне однозначно.

конечно, в большинстве случаев это лишнее: не надо писать такие лесенки-простыни, чтобы приходилось усердно размышлять, от кого там `END`; но на практике такое иногда получается, и тогда явное указание лучше комментария. поэтому штука опциональная.

коммиты вышли грязные, поэтому ссылку не даю. но изменения в DevCPP минимальные: просто вместо `CheckSym(end)` везде вызывать `CheckSym2(end, if)`, например, и в `CheckSym2()` проверять и съедать дополнительный токен, если надо.

p.s.: или сделать `CheckSymEnd()`, и там добавить ещё более лучшие овощи^w сообщения об ошибках.

запретил присваивание WITH-переменной, если она указатель. разрешено только присвоить ей NIL, а больше ничего. изменять поля по-прежнему можно, если переменная изначально не r/o.

это ничего особо не даёт, кроме бития меня по рукам: я иногда от лени использую такую переменную как временную, потому что неохота в VAR лазить. особо ничего от этого не ломается, но если можно бить по рукам за ленивый код — то почему бы и да.

NIL разрешён ровно потому, что это используется в одном месте среды — в DevDebug. когда-нибудь кто-нибудь обязательно удивится, зачем было сделано такое исключение, и построит интересную гипотезу — не зная, что это просто хак для удобства.

кстати, пригодилось новое поле readonly в `CPT.Object`: теперь оно INTEGER, и там три состояния: `rw`, `ro`, и `roShallow`. третье состояние нетранзитивное. вообще, надо бы пройтись по компилятору и поубирать проверки на externalR, заменив установкой нового поля при создании импорта.

ыы. кп превращается в ada.

hellraiser, язык Ада, всё как полагается.

перевёл линуксовый registry-бэкэнд на SQLite. опционально: если модуль с поддержкой SQLite не загрузится (не установлена, например) — то откатится назад к обычным файлам. хотя я считаю, что SQLite должна стоять везде, а у кого её нет — тот дурак^w страуструп.

собственно, rationale для прошлого камента: запущеных процессов ящика бывает больше одного. и они все лезут в базу реестра, в том числе и на запись. ну да, финальное приложение можно кастомизировать, но рабочие ящики-то все в одну. SQLite эту проблему решает сам, без моего вмешательства: запись всегда консистентна, прочитаные значения всегда актуальны. именно по этой причине я SQLite и впилил (а не потому что Там Обязательно Нужна БД).

конечно, тот же механизм синхронизации можно и на BBCB написать, но… вот тут тот случай, когда: «а зачем?» SQLite — удобный и надёжный инструмент. нет смысла переизобретать с нуля абсолютно всё ваще.

type guards теперь надо писать так: `var(AS Type)`. о форме `var(:Type)` я думал, но отказался: во-первых, и так закорючек много, сишечкой воняет; а во-вторых, двоеточие плохо считывается, слишком маленькое и незаметное. пришлось добавить ещё одно ключевое слово, увы. думал ещё и над формой `var(TYPE Type)`, чтобы ключевых слов не добавлять, но громоздко как-то, и лошад сказал, что на объявление типа похоже.

про `var AS Type` тоже были размышления, но отказался из-за того, что это всё равно придётся в скобочки брать постоянно, и вхачивать проверки, чтобы запретить `var AS Mod.Type.field` — которую парзер разрешит, но выглядит это ужасно и читается никак.

не то чтобы я был от `AS` в восторге, но это лучше, чем ничего.

заодно портанул в лин rtf-конвертер из вин, через iconv. там, кстати, мелкобаг (в конвертере): после `\u` не скипается `\'`.

p.s.: в принципе, `var(AS Type)` даже более-менее читается: «переменная (как тип)» — уточнение, то есть.

А ему и не обязательно бросаться в глаза, в конце-концов это всего лишь подсказка. Не припомню, чтобы и оригинальная-то форма записи создавала проблему. Это происходит потому, что для понимания кода недостаточно знать только тип операции, нужно также знать и смысл элементов. А зная их не составляет сложности и распознавание выражения.

оригинальная таки неоднозначна. помимо прочего — её нельзя однозначно распарзить в AST если не строить сразу по пути таблицу символов. не то чтобы большое препятствие, но. в целом, я пытаюсь идти в направлении «операции с разным смыслом не должны выглядеть одинаково», и при этом стараюсь не очень перегрузить язык подробностями и длиннотами. мне кажется, что пока получается — хотя это, конечно, субъективно.

и вот двоеточие меня в плане читаемости тут не устраивает: ну слишком легко его при чтении не заметить. как минимум — мне легко. да и вообще, сишечкой начинает пахнуть (в плане кучи закорючек). а, следовательно, надо или сделать элемент заметней, или не вводить вообще; но «не вводить» конфликтует с «не должны выглядеть одинаково». синтаксис с уточнением типа в скобках мне нравится, поэтому я попробовал придумать, как сделать его яснее, и при этом не очень испортить язык.

оригинальный компонентный паскаль на всякий случай всё ещё поддерживается в полном объёме через `MODULE xxx IN ComponentPascal`. в конце концов, если я не внедрю и не попробую на практике — то я и не пойму, сильно оно мешает, или нормально смотрится. пока что мне нравится: читать стало легче, и код писать не мешает.

однако, сделал генератор OpenGL-биндов на основе xml от хроняк. однако, мегабайт (почти) гуано получился. однако, однако.

к сожалению, OpenGL — очень уж хитрый предмет. кроме базового GL1 (которое по нынешним временам бесполезно чуть менее, чем полностью) всё остальное по правилам следует получать динамикой, через `glXGetProcAddress()` и аналоги. причём делать это надо уже после того, как создан GL-контекст с нужными параметрами, иначе драйвер вправе вернуть NIL (и на винде, например, некоторые драйвера точно так и делают; на линуксах, впрочем, тоже).

соответственно, модуль выглядит так: ему надо поставить колбэк `GetProcAddr()`, а все gl-процедуры описаны как обычные глобальные переменные разных процедурных типов. изначально каждой из них присваивается скрытая процедура-загрузчик, которая вызывает `GetProcAddr()`, и присваивает результат глобалу. такой вот динамический импорт.

всего там больше двух тысяч процедур, и больше трёх с половиной тысяч констант. в принципе, по уму бы это надо разбить на разные модули, отдельно для каждой версии OpenGL. но мне лень. компилится оно знатно: около секунды.

вообще, конечно, можно впилить в компилятор специальный тип процедуры, и генерить stub сразу из кодогена, чтобы оный stub вызывал `GetProcAddr()`, а потом правил первую инструкцию на `JMP`. но тоже лень. хотя что-то в этой мысли есть, я её ещё подумаю.

если кто хочет генератор (или его выхлоп; но я в выхлопе пока не очень уверен) — пишите в ЛС, поделюсь. а выкладывать не буду, стыдно очень.

p.s.: надо бы потом сделать View для gl-рисования. по типу как Controls сделаны, с нативным окном.

алсо, дошли лапы посмотреть, как CP2 компилирует `Proc(str + "abc")`. хм. омики как обычно не стали умничать, пытаться что-то на стеке вычислить…

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