[Oberon-07/11] Export non-scalar variable.

[valexey_u]

Да, кроме того, тип SET Вирт явно причисляет к скалярным типам, хотя доступ к отдельным "полям" там есть.

Что характерно, в Модуле-2 тип-множество у Вирта был составным, а в Обероне стал скалярным.

Точнее так - в Обероне-0 явно сказано что он скалярный (точнее Вирт считает что он скалярный), а как оно в Обероне (и соответственно в Oberon-07/11, как в самом свежем представителе) никто, кроме возможно Вирта, не знает :-)

[ilovb]

Думаю что указатели тоже должны быть read only

[igor]

Что характерно, в Модуле-2 тип-множество у Вирта был составным, а в Обероне стал скалярным.

Точнее так - в Обероне-0 явно сказано что он скалярный (точнее Вирт считает что он скалярный), а как оно в Обероне (и соответственно в Oberon-07/11, как в самом свежем представителе) никто, кроме возможно Вирта, не знает :-)

Из указанного мной выше источника:

1.3. Стандартные примитивные типы
************
Мы обозначаем эти типы следующими идентификаторами:
INTEGER, REAL, BOOLEAN, CHAR, SET.

Кстати, POINTER в этом списке нет.

[ilovb]

1) Зачем он это сделал? Чем переменные не скалярных типов хуже при read-only экспорте чем переменные скалярных типов? (мы тут всю голову сломали, но придумать вескую причину не смогли)

Экспортировать можно только read only. А для сложных типов сделать read only видимо проблематично. Вот и запретил... :-)

[ilovb]

В алгоритмах написано что скалярные типы - это те, с которыми можно только := сделать.
Т.е. получается что скалярными являютя и множества и указатели

[igor]

Экспортировать можно только read only. А для сложных типов сделать read only видимо проблематично. Вот и запретил... :-)

Дело, видимо, всё же в другом. Экспортированная переменная доступна всем модулям-клиентам. Если эта переменная доступна для записи, то различные модули-клиенты в принципе могут изменять её значение не согласованно. Получается как бы то же "зло", что и с глобальными переменными. Слишком широкополосный доступ для записи.

[igor]

Кстати, это объясняет почему типы можно экспортировать, а переменные нет.

[ilovb]

igor, прочитайте внимательно, что процитировали :-)

[igor]

Что-то под вечер мне ребусы тяжело даются  :-)

[Kemet]

Экспортировать можно только read only. А для сложных типов сделать read only видимо проблематично. Вот и запретил... :-)

Дело, видимо, всё же в другом. Экспортированная переменная доступна всем модулям-клиентам. Если эта переменная доступна для записи, то различные модули-клиенты в принципе могут изменять её значение не согласованно.

Запрещён экспорт только статических структурных переменных, динамические экземпляры по прежнему доступны.

[ilovb]

Что-то под вечер мне ребусы тяжело даются  :-)

Где там противоречие с вашим утверждением?

[igor]

По крайней мере на счет указателей у меня БОЛЬШИЕ сомнения.

Нашёл у Кауфмана. Правда, это не про Оберон, а вообще.
Куфман В.Ш., "Языки программирования. Концепции и принципы", 2011, Гл.2.2.3:

Имеются четыре категории типов: скалярные, составные, ссылочные и приватные.

... и далее по тексту разжёвано.
Так что, указатели - это и не скалярный тип, и не составной (по Кауфману).

[igor]

Где там противоречие с вашим утверждением?

Моё утверждение не противоречит Вашему, а скорее дополняет его (или расширяет).
(Я же не утверждал, что нет никаких проблем сделать экспорт read only для переменных сложных типов.)

[igor]

Куфман В.Ш., "Языки программирования. Концепции и принципы", 2011, Гл.2.2.3:

Точнее, гл.2.3.3 (с. 50)

[valexey_u]

1) Зачем он это сделал? Чем переменные не скалярных типов хуже при read-only экспорте чем переменные скалярных типов? (мы тут всю голову сломали, но придумать вескую причину не смогли)

Экспортировать можно только read only. А для сложных типов сделать read only видимо проблематично. Вот и запретил... :-)

Я не вижу где там может возникнуть эта самая проблематичность отличная проблематичности read-only скалярных переменных.