Oleg N. Cher писал(а):
Я слышал, что в Zonnon'е если модуль начинается с MODULE, то ключевые слова ожидаются в верхнем регистре, а если с module, то только в нижнем. Это очень интересное решение, но, к сожалению, не учитывает момент, когда программист, работая с ключевыми словами в нижнем регистре заведёт и экспортирует переменную с именем TYPE (или DO), а другой программист, работая с исходником в верхнем регистре, не сможет её использовать. Этого бы очень хотелось избежать. Как бы вы предложили поступить в этом случае?
Oleg N. Cher писал(а):
Протестировал решение Трурля на таком модуле:
Код:
module DO; end DO.
Оно тоже не решает проблему идентов в верхнем регистре, совпадающих с ключевыми словами.
Здесь может даже регистровая нечувствительность была бы лучше? По крайней мере, тогда бы такие иденты запрещались, приравниваясь к ключевым словам. Хотя бардака типа:
Код:
fOR i := 1 To 10 bY 2 do .. eNd;
конечно же не хочется...
Видимо, в данном случае регистровая нечувствительность, фактически, является единственным решением. Может быть, есть смысл в некой ограниченной нечувствительности, сохраняя основные достоинства регистронезависимости и чувствительности к регистру.
Например. Пусть ключевые слова задаются только в верхнем или нижнем регистре в зависимости от MODULE/module в начале.
Буквы идентификаторов должны быть в одном и том же регистре, т.е. нельзя одновременно определить (в одной области), к примеру, "ident" и "Ident" или "iDent" и т.д.
При совпадении набора букв в идентификаторе и ключевого слова хотя бы одна буква в идентификаторе должна быть в ином регистре. К примеру, допустимы "do" или "Do" (и "dO") при наличии ключевого слова "DO".
Ключевое (и, возможно, самое проблемное) -- необходимо разделить пространство имён -- на имена типов и все прочие имена, где две области имеют свою уникальность (по аналогии с рядом функциональных языков, и, вроде бы, в Паскаль-подобном языке такое размежевание потенциально осуществимо). Тогда имеется возможность иметь идентичные имена в типах и переменных/параметрах/константах (а также и процедурах), напр.:
Код:
var date: date;
(* или:
var date: Date; *)
При этом нельзя одновременно определить в одной области переменные как "var date: ..." и, напр., "var Date: ...". И не могут быть одновременно два типа, напр., как "type date = ..." и "type Date = ...".
На границе модулей экспортируемый интерфейс адаптируется для импортирующего модуля. Для последнего экспортируемые имена являются условно регистронезависимыми, но допускается только один вариант применения регистра в идентификаторе.
Например:
Код:
(* Модуль с ключевыми словами в верхнем регистре, экспортирующий
тип и переменную *)
MODULE M1;
TYPE Do* = ...;
VAR do*: Do;
...
END M1.
(* Модуль с ключевыми словами в нижнем регистре, импортирующий
элементы из M1 *)
module M2;
import M1;
(* Использование импортированного типа. Идентификатор "Do" может быть в любом регистре,
напр. и как "DO" и пр., но допустим только один вариант применения: *)
var d1: M1.Do;
var d2: M1.Do;
(* var d2: M1.DO; -- ошибка, т.к. в модуле уже используется вариант M1.Do *)
(* Применение импортированной переменной. Аналогично, регистр идентификатора "do"
может быть любым, но в единственном варианте: *)
...
begin
d1 := M1.do;
d2 := M1.do;
...
end;
...
end M2.
В импортирующем модуле в случае квалифицированных имён (как "модуль.идентификатор") регистр идентификатора может быть любым (но в единственном варианте). Если гипотетически в языке возможен и доступ без квалификации, то требуется использовать вариант регистра идентификатора, отличающийся от ключевого слова:
Код:
MODULE M1;
TYPE Do* = ...;
VAR do*: Do;
...
END M1.
module M2;
import M1;
(* использование типа M1.Do: *)
var d1: DO;
var d2: DO;
(* использование переменной M1.do: *)
...
begin
d1 := Do;
d2 := Do;
...
end;
...
end M2.
Возможна и некая расширенная форма директивы а-ля import в стиле:
Код:
(* импортируется переменная и тип с указанием варианта имени
для каждого идентификатора: *)
import M1(Do, type DO);
Не в курсе, возможна ли подобная схема для Оберон-экспериментов (у себя ранее рассматривалась схожая проблематика, но не для Оберонов).