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

[valexey_u]

Вирт в Oberon-07/11 (а возможно и раньше) запретил экспорт из модуля (даже в режиме read only) переменные не скалярный типов.

Отсюда возникает минимум два вопроса:

1) Зачем он это сделал? Чем переменные не скалярных типов хуже при read-only экспорте чем переменные скалярных типов? (мы тут всю голову сломали, но придумать вескую причину не смогли)
2) Что такое скалярный тип? В репорте про это нет ни слова. Есть предположение что это Basic Types + Pointer types (в противовес Structured types = Record types + Array types).

[Kemet]

Ну, в общем, в этом есть некоторый смысл, особенно в свете opaque types и сокрытия реализации - со структурными типами не следует работать напрямую, следует использовать соответствующие экспортированные процедуры.
А значение термина "скалярные типы данных" вполне очевидно, чтобы не тащить это в сообщение о языке.

[valexey_u]

Ну, в общем, в этом есть некоторый смысл, особенно в свете opaque types и сокрытия реализации - со структурными типами не следует работать напрямую, следует использовать соответствующие экспортированные процедуры.
А значение термина "скалярные типы данных" вполне очевидно, чтобы не тащить это в сообщение о языке.

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

И таки что такое "переменная скалярного типа"? Насколько это понятие является языковым и не зависящим от деталей реализации?

[valexey_u]

На всякий случай цитату из первоисточника приведу:

11. Modules
...
Variables cannot be exported, with the exception of those of scalar types in read-only mode.

[Kemet]

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

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

И таки что такое "переменная скалярного типа"? Насколько это понятие является языковым и не зависящим от деталей реализации?

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

[valexey_u]

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

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

Здорово, но про экспорт полей никто и не говорил. Говорили про экспорт переменных :-)

То есть я по прежнему не вижу никакой проблемы для экспорта переменных не скалярных типов (про экспорт ТИПОВ никто не говорит, там нет таких запретов).

И таки что такое "переменная скалярного типа"? Насколько это понятие является языковым и не зависящим от деталей реализации?

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

Что значит "не имеющие составных частей"? Имеется ввиду только операция присваивания?

[igor]

2) Что такое скалярный тип? В репорте про это нет ни слова. Есть предположение что это Basic Types + Pointer types (в противовес Structured types = Record types + Array types).

Под скалярными типами в Обероне понимаются все типы, кроме массивов, записей и указателей. Строки, я так понимаю, относятся к массивам (символов), так что они тоже не скалярные.

[valexey_u]

2) Что такое скалярный тип? В репорте про это нет ни слова. Есть предположение что это Basic Types + Pointer types (в противовес Structured types = Record types + Array types).

Под скалярными типами в Обероне понимаются все типы, кроме массивов, записей и указателей. Строки, я так понимаю, относятся к массивам (символов), так что они тоже не скалярные.

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

[Kemet]

Здорово, но про экспорт полей никто и не говорил. Говорили про экспорт переменных :-)

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

Что значит "не имеющие составных частей"? Имеется ввиду только операция присваивания?

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

[valexey_u]

Здорово, но про экспорт полей никто и не говорил. Говорили про экспорт переменных :-)

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

Может. А может и все. Кроме того, нигде в репорте не сказано, что структура обязана занимать непрерывный кусок в памяти. То есть это уже нюансы реализации. Она вообще может быть реализована списком или деревом :-) Это никак не пересекается с возможностью экспортировать переменные такого типа. Ну вот вообще никак. Тем более что экспорт там заведомо read only.

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

Замечу, именно запрет экспорта, а не решение программиста экспортировать нечто через opaque-тип/переменную opaque-типа.

Что значит "не имеющие составных частей"? Имеется ввиду только операция присваивания?

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

Ну, то есть ты с igor не согласен? :-)
Кроме того, сколь я помню, в Обероне есть несколько встроенных функций для операций над мантиссой и так далее.

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

[igor]

Под скалярными типами в Обероне понимаются все типы, кроме массивов, записей и указателей. Строки, я так понимаю, относятся к массивам (символов), так что они тоже не скалярные.

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

Вроде нашёл, откуда я это знаю 
Никлаус Вирт, "Алгоритмы и структуры данных", 2010, Гл.1.3
К сожалению, у меня нет оригинала под рукой (на английском языке). В данном контексте термины "примитивный тип" (в другом переводе: "простой тип") и "скалярный тип" являются синонимами.

[igor]

По поводу указателей в Обероне. Ссылку сейчас не найду, но их принято относить к не скалярным типам, потому что указатели в Обероне, в отличие от машинных адресов в Си, всегда связаны со структурными типами данным, таким как массивы и записи.

[valexey_u]

По поводу указателей в Обероне. Ссылку сейчас не найду, но их принято относить к не скалярным типам, потому что указатели в Обероне, в отличие от машинных адресов в Си, всегда связаны со структурными типами данным, таким как массивы и записи.

Ну, с массивами то указатели в Обероне, скажем, не могут быть связаны в принципе.

Да, а вот на счет указателей и их скалярности единственное что я нашел - это явное перечисление скалярный типов в виртовском Compiler Construction, и среди них действительно указателей нет. Но есть один нюанс - там перечисляются типы не Оберона, а учебного Оберона-0, в котором указателей нет вообще :-) Так что это не особо достоверный источник.

Про скалярные типы в Project Oberon вроде бы тоже ничего нет. Остальное пока не смотрел.

[igor]

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

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

[Kemet]

Ну, то есть ты с igor не согласен? :-)
Кроме того, сколь я помню, в Обероне есть несколько встроенных функций для операций над мантиссой и так далее.

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

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