OberonCore

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

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

как вы считаете, коллеги?

в общем, я в LC предварительно сделал так: CONST/TYPE/VAR, потом PROCEDURE, потом допускается ещё CONST/TYPE/VAR, но повторных PROCEDURE уже нельзя. так, мне кажется, правильно: минимизируем мешанину, более-менее чётко указываем, что такая возможность не для хаоса бездумной фигни, а с целью.

p.s.: естественно, на глобальном уровне такой фокус не разрешён.

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

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

то есть, так:

то же самое относится и к константам, и к типам.

p.s.: для global scope это малооправдано, получится каша. поэтому на глобальном уровне такое запрещено.

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

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

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

с SYSTEM, мне кажется, перебор. к тому же я требую помечать UPSCOPE любой доступ, а не только изменение (так проще). импортировать SYSTEM для штатной фичи языка как-то… не надо, по-моему. а вот сделать код с идеологически некрасивой штукой чуть более некрасивым, и чуть более заментым — самое то.

p.s.: так-то потребовать импорта SYSTEM при доступе (любом) к outer locals несложно, там буквально одна проверка. если только для изменений — то сложнее будет, размазано по компилятору уже. но таки это получается перегруз SYSTEM, который предназначен строго-строго для вещей, которые «не влезай — убьёт!»

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

вы таки будете смеяться, но `UP.` у меня как раз работает как указатель уровня (это проверяется, правильные уровни выбираются). не поверите: удобно. в том числе и для вот таких финтов:

ну и да, для доступа к глобалам есть `GLOBAL.`. но оно не энфорсится, потому что очень уж много кода ломается. а так-то надо бы, для вящей чистоты. разве что переименовать в какое-нибудь `GG`, а то больно длинно.