Oberon space
General Category => Общий раздел => Тема начата: valexey_u от Сентябрь 12, 2013, 12:29:10 pm
-
Вирт в Oberon-07/11 (а возможно и раньше) запретил экспорт из модуля (даже в режиме read only) переменные не скалярный типов.
Отсюда возникает минимум два вопроса:
1) Зачем он это сделал? Чем переменные не скалярных типов хуже при read-only экспорте чем переменные скалярных типов? (мы тут всю голову сломали, но придумать вескую причину не смогли)
2) Что такое скалярный тип? В репорте про это нет ни слова. Есть предположение что это Basic Types + Pointer types (в противовес Structured types = Record types + Array types).
-
Ну, в общем, в этом есть некоторый смысл, особенно в свете opaque types и сокрытия реализации - со структурными типами не следует работать напрямую, следует использовать соответствующие экспортированные процедуры.
А значение термина "скалярные типы данных" вполне очевидно, чтобы не тащить это в сообщение о языке.
-
Ну, в общем, в этом есть некоторый смысл, особенно в свете opaque types и сокрытия реализации - со структурными типами не следует работать напрямую, следует использовать соответствующие экспортированные процедуры.
А значение термина "скалярные типы данных" вполне очевидно, чтобы не тащить это в сообщение о языке.
Стоп. А зачем тогда вообще разрешать какой-либо экспорта переменных? И чем, в конце концов, хуже экспорт одной переменной структурного типа чем экспорт 100500 переменных скалярного типа?
И таки что такое "переменная скалярного типа"? Насколько это понятие является языковым и не зависящим от деталей реализации?
-
На всякий случай цитату из первоисточника приведу:
11. Modules
...
Variables cannot be exported, with the exception of those of scalar types in read-only mode.
-
Стоп. А зачем тогда вообще разрешать какой-либо экспорта переменных? И чем, в конце концов, хуже экспорт одной переменной структурного типа чем экспорт 100500 переменных скалярного типа?
Внешний интерфейс (экспортированные поля) не обязан отражать внутреннюю структуру типа, например, у нас есть железяка, в которой принципиально невозможно сделать упакованную запись, т.к. она будет распределена по разным блокам и/или отображена на различные узлы. А если учитывать, что и модуль может реализовывать конкретный функционал под конкретное функциональное устройство, то только процедуры этого конкретного модуля смогут работать напрямую с таким структурным типом.
И таки что такое "переменная скалярного типа"? Насколько это понятие является языковым и не зависящим от деталей реализации?
Понятие "скалярные типы данных" вводятся в обращение ещё в школьном курсе информатики, и трактуются как не имеющие составных частей с точки зрения языка программирования.
-
Стоп. А зачем тогда вообще разрешать какой-либо экспорта переменных? И чем, в конце концов, хуже экспорт одной переменной структурного типа чем экспорт 100500 переменных скалярного типа?
Внешний интерфейс (экспортированные поля) не обязан отражать внутреннюю структуру типа, например, у нас есть железяка, в которой принципиально невозможно сделать упакованную запись, т.к. она будет распределена по разным блокам и/или отображена на различные узлы. А если учитывать, что и модуль может реализовывать конкретный функционал под конкретное функциональное устройство, то только процедуры этого конкретного модуля смогут работать напрямую с таким структурным типом.
Здорово, но про экспорт полей никто и не говорил. Говорили про экспорт переменных :-)
То есть я по прежнему не вижу никакой проблемы для экспорта переменных не скалярных типов (про экспорт ТИПОВ никто не говорит, там нет таких запретов).
И таки что такое "переменная скалярного типа"? Насколько это понятие является языковым и не зависящим от деталей реализации?
Понятие "скалярные типы данных" вводятся в обращение ещё в школьном курсе информатики, и трактуются как не имеющие составных частей с точки зрения языка программирования.
Что значит "не имеющие составных частей"? Имеется ввиду только операция присваивания?
-
2) Что такое скалярный тип? В репорте про это нет ни слова. Есть предположение что это Basic Types + Pointer types (в противовес Structured types = Record types + Array types).
Под скалярными типами в Обероне понимаются все типы, кроме массивов, записей и указателей. Строки, я так понимаю, относятся к массивам (символов), так что они тоже не скалярные.
-
2) Что такое скалярный тип? В репорте про это нет ни слова. Есть предположение что это Basic Types + Pointer types (в противовес Structured types = Record types + Array types).
Под скалярными типами в Обероне понимаются все типы, кроме массивов, записей и указателей. Строки, я так понимаю, относятся к массивам (символов), так что они тоже не скалярные.
Откуда дровишки? По крайней мере на счет указателей у меня БОЛЬШИЕ сомнения.
-
Здорово, но про экспорт полей никто и не говорил. Говорили про экспорт переменных :-)
эээ, структура, как бы, может экспортировать не все поля.
Что значит "не имеющие составных частей"? Имеется ввиду только операция присваивания?
имеется ввиду, что это цельная штука, и если она и имеет какие-то физические части, на уровне языка они не определяются и для возможного доступа к ним служат специальные средства. Например, формально, скалярный тип REAL физически имеет некую структуру, но на уровне языка это единое целое, и нет средств(структурного поля), чтобы напрямую обратиться к мантиссе.
К скалярам, обычно, относят целочисленные, вещественные, перечислимые, диапазонные, символьные, указатели, ссылки и комплексные, если они определены на уровне языка и не имеют структурных полей.
-
Здорово, но про экспорт полей никто и не говорил. Говорили про экспорт переменных :-)
эээ, структура, как бы, может экспортировать не все поля.
Может. А может и все. Кроме того, нигде в репорте не сказано, что структура обязана занимать непрерывный кусок в памяти. То есть это уже нюансы реализации. Она вообще может быть реализована списком или деревом :-) Это никак не пересекается с возможностью экспортировать переменные такого типа. Ну вот вообще никак. Тем более что экспорт там заведомо read only.
Ну, то есть нужно хотя бы один пример, где конкретно запрет экспорта таковых переменных в read-only режиме делает жизнь лучше хотя бы кому-то (при этом все остальное в языке не меняем).
Замечу, именно запрет экспорта, а не решение программиста экспортировать нечто через opaque-тип/переменную opaque-типа.
Что значит "не имеющие составных частей"? Имеется ввиду только операция присваивания?
имеется ввиду, что это цельная штука, и если она и имеет какие-то физические части, на уровне языка они не определяются и для возможного доступа к ним служат специальные средства. Например, формально, скалярный тип REAL физически имеет некую структуру, но на уровне языка это единое целое, и нет средств(структурного поля), чтобы напрямую обратиться к мантиссе.
К скалярам, обычно, относят целочисленные, вещественные, перечислимые, диапазонные, символьные, указатели, ссылки и комплексные, если они определены на уровне языка и не имеют структурных полей.
Ну, то есть ты с igor не согласен? :-)
Кроме того, сколь я помню, в Обероне есть несколько встроенных функций для операций над мантиссой и так далее.
Да, кроме того, тип SET Вирт явно причисляет к скалярным типам, хотя доступ к отдельным "полям" там есть.
-
Под скалярными типами в Обероне понимаются все типы, кроме массивов, записей и указателей. Строки, я так понимаю, относятся к массивам (символов), так что они тоже не скалярные.
Откуда дровишки? По крайней мере на счет указателей у меня БОЛЬШИЕ сомнения.
Вроде нашёл, откуда я это знаю :)
Никлаус Вирт, "Алгоритмы и структуры данных", 2010, Гл.1.3
К сожалению, у меня нет оригинала под рукой (на английском языке). В данном контексте термины "примитивный тип" (в другом переводе: "простой тип") и "скалярный тип" являются синонимами.
-
По поводу указателей в Обероне. Ссылку сейчас не найду, но их принято относить к не скалярным типам, потому что указатели в Обероне, в отличие от машинных адресов в Си, всегда связаны со структурными типами данным, таким как массивы и записи.
-
По поводу указателей в Обероне. Ссылку сейчас не найду, но их принято относить к не скалярным типам, потому что указатели в Обероне, в отличие от машинных адресов в Си, всегда связаны со структурными типами данным, таким как массивы и записи.
Ну, с массивами то указатели в Обероне, скажем, не могут быть связаны в принципе.
Да, а вот на счет указателей и их скалярности единственное что я нашел - это явное перечисление скалярный типов в виртовском Compiler Construction, и среди них действительно указателей нет. Но есть один нюанс - там перечисляются типы не Оберона, а учебного Оберона-0, в котором указателей нет вообще :-) Так что это не особо достоверный источник.
Про скалярные типы в Project Oberon вроде бы тоже ничего нет. Остальное пока не смотрел.
-
Да, кроме того, тип SET Вирт явно причисляет к скалярным типам, хотя доступ к отдельным "полям" там есть.
Что характерно, в Модуле-2 тип-множество у Вирта был составным, а в Обероне стал скалярным.
-
Ну, то есть ты с igor не согласен? :-)
Кроме того, сколь я помню, в Обероне есть несколько встроенных функций для операций над мантиссой и так далее.
Да, кроме того, тип SET Вирт явно причисляет к скалярным типам, хотя доступ к отдельным "полям" там есть.
Это не только я не согласен, как раз сейчас спросил соседскую девчонку-школьницу, вот точно такой список назвала, т.е. в школе это проходится и именно в таком составе.
Встроенные функции это и есть специальные средства, напрямую к мантиссе ты не обратишься - нет такого поля в типе REAL, SET также не имеет внутренних полей, его структура на уровне языка не определена.
-
Да, кроме того, тип SET Вирт явно причисляет к скалярным типам, хотя доступ к отдельным "полям" там есть.
Что характерно, в Модуле-2 тип-множество у Вирта был составным, а в Обероне стал скалярным.
Точнее так - в Обероне-0 явно сказано что он скалярный (точнее Вирт считает что он скалярный), а как оно в Обероне (и соответственно в Oberon-07/11, как в самом свежем представителе) никто, кроме возможно Вирта, не знает :-)
-
Думаю что указатели тоже должны быть read only
-
Что характерно, в Модуле-2 тип-множество у Вирта был составным, а в Обероне стал скалярным.
Точнее так - в Обероне-0 явно сказано что он скалярный (точнее Вирт считает что он скалярный), а как оно в Обероне (и соответственно в Oberon-07/11, как в самом свежем представителе) никто, кроме возможно Вирта, не знает :-)
Из указанного мной выше источника:
1.3. Стандартные примитивные типы
************
Мы обозначаем эти типы следующими идентификаторами:
INTEGER, REAL, BOOLEAN, CHAR, SET.
Кстати, POINTER в этом списке нет.
-
1) Зачем он это сделал? Чем переменные не скалярных типов хуже при read-only экспорте чем переменные скалярных типов? (мы тут всю голову сломали, но придумать вескую причину не смогли)
Экспортировать можно только read only. А для сложных типов сделать read only видимо проблематично. Вот и запретил... :-)
-
В алгоритмах написано что скалярные типы - это те, с которыми можно только := сделать.
Т.е. получается что скалярными являютя и множества и указатели
-
Экспортировать можно только read only. А для сложных типов сделать read only видимо проблематично. Вот и запретил... :-)
Дело, видимо, всё же в другом. Экспортированная переменная доступна всем модулям-клиентам. Если эта переменная доступна для записи, то различные модули-клиенты в принципе могут изменять её значение не согласованно. Получается как бы то же "зло", что и с глобальными переменными. Слишком широкополосный доступ для записи.
-
Кстати, это объясняет почему типы можно экспортировать, а переменные нет.
-
igor, прочитайте внимательно, что процитировали :-)
-
Что-то под вечер мне ребусы тяжело даются :-)
-
Экспортировать можно только read only. А для сложных типов сделать read only видимо проблематично. Вот и запретил... :-)
Дело, видимо, всё же в другом. Экспортированная переменная доступна всем модулям-клиентам. Если эта переменная доступна для записи, то различные модули-клиенты в принципе могут изменять её значение не согласованно.
Запрещён экспорт только статических структурных переменных, динамические экземпляры по прежнему доступны.
-
Что-то под вечер мне ребусы тяжело даются :-)
Где там противоречие с вашим утверждением?
-
По крайней мере на счет указателей у меня БОЛЬШИЕ сомнения.
Нашёл у Кауфмана. Правда, это не про Оберон, а вообще.
Куфман В.Ш., "Языки программирования. Концепции и принципы", 2011, Гл.2.2.3:
Имеются четыре категории типов: скалярные, составные, ссылочные и приватные.
... и далее по тексту разжёвано.
Так что, указатели - это и не скалярный тип, и не составной (по Кауфману).
-
Где там противоречие с вашим утверждением?
Моё утверждение не противоречит Вашему, а скорее дополняет его (или расширяет).
(Я же не утверждал, что нет никаких проблем сделать экспорт read only для переменных сложных типов.)
-
Куфман В.Ш., "Языки программирования. Концепции и принципы", 2011, Гл.2.2.3:
Точнее, гл.2.3.3 (с. 50)
-
1) Зачем он это сделал? Чем переменные не скалярных типов хуже при read-only экспорте чем переменные скалярных типов? (мы тут всю голову сломали, но придумать вескую причину не смогли)
Экспортировать можно только read only. А для сложных типов сделать read only видимо проблематично. Вот и запретил... :-)
Я не вижу где там может возникнуть эта самая проблематичность отличная проблематичности read-only скалярных переменных.
-
Ну с простыми типами понятно. Нужно запретить присваивания и передачу VAR параметром. Хватит ли этого для сложных типов? у меня уверенности нет, что тех же мер достаточно.
-
Где там противоречие с вашим утверждением?
Моё утверждение не противоречит Вашему, а скорее дополняет его (или расширяет).
(Я же не утверждал, что нет никаких проблем сделать экспорт read only для переменных сложных типов.)
Вот вот. Однако начали вы с "Дело, видимо, всё же в другом." ;)
ps Ладно, проехали... У меня тяжелый день просто был. :)
-
Вот вот. Однако начали вы с "Дело, видимо, всё же в другом." ;)
Согласен. Не совсем удачный заход... :-[
-
TYPE
Object* = RECORD
field*: REAL;
END;
VAR obj-: Object; (* не разрешённый экспорт! *)
Может, Вирту не понравилось противоречие: тип Object как бы разрешает запись в поле field, а переменная obj, в то же самое время, - запрещает. Хотя согласен, что такое объяснение выглядит несколько натянутым. Честно говоря, я тоже голову сломал :-)
-
Причины запрета экспорта структурных переменных тоже не вижу... Разве что ослабляются межмодульные связи, м. б. чем-то упрощается раздельная компиляция и динамическая модульность. Скалярный ли тип указатель? Скорее да, собственной структуры у него нет.
-
Я не вижу где там может возникнуть эта самая проблематичность отличная проблематичности read-only скалярных переменных.
Например, в записи одно из полей может быть указателем.
-
Что такое скалярный тип? В репорте про это нет ни слова. Есть предположение что это Basic Types + Pointer types (в противовес Structured types = Record types + Array types).
не являющийся составным (не является объявленной, в определении языка, комбинацией других типов этого ЯП) - какие конкретно типы относятся к простым зависит от ЯП(его описания) - в Обероне (насколько я понимаю) - все, кроме типов RECORD и ARRAY.
-
Вирт в Oberon-07/11 (а возможно и раньше) запретил экспорт из модуля (даже в режиме read only) переменные не скалярный типов.
Отсюда возникает минимум два вопроса:
1) Зачем он это сделал? Чем переменные не скалярных типов хуже при read-only экспорте чем переменные скалярных типов? (мы тут всю голову сломали, но придумать вескую причину не смогли)
имеет смысл если только включить в список запрещенных для экспорта указатели (помимо записей и массивов).
-
имеет смысл если только включить в список запрещенных для экспорта указатели (помимо записей и массивов).
Согласен. Если и запрещать, то тогда вместе с указателями. Иначе смысла - 0. Или у Вирта была какая-нибудь особенность реализации, которую нам ну никак не угадать "общими размышлениями".
-
Согласен. Если и запрещать, то тогда вместе с указателями. Иначе смысла - 0. Или у Вирта была какая-нибудь особенность реализации, которую нам ну никак не угадать "общими размышлениями".
Вообще смысла в таких исключениях "можно, но только read-only" нет - тот же эффект можно получить через экспорт процедур, возвращающих нужные переменные. Скорее всего это просто оптимизация (в расчете на неоптимизирующий компилятор).
P.S. Хотя лично я до сих пор не вижу особой разницы между процедурами set/get для переменной модуля и просто экспортированной переменной модуля. Оно все равно по смыслу остается глобальной переменной со всеми присущими проблемами. Ну разве что брейк поинт можно воткнуть, чтобы рабораться кто и когда все портит. Но это уже борьба (неэффективная) со следствием (бардак в системе).
-
Ну так спросите у самого Вирта )))
-
Ну так спросите у самого Вирта )))
Вирт не отвечает на емыл. А ходатайствовать у Info21 как-то претит...
-
Вирт не отвечает на емыл.
Либо он редиска, либо он решил, что всё фигня, даже обероны )))
-
Согласен. Если и запрещать, то тогда вместе с указателями. Иначе смысла - 0. Или у Вирта была какая-нибудь особенность реализации, которую нам ну никак не угадать "общими размышлениями".
смысл в том, чтобы проггеры с "суконным рылом" не гоношились в динамических структурах порождаемых экспортируемым модулем.
-
Согласен. Если и запрещать, то тогда вместе с указателями. Иначе смысла - 0. Или у Вирта была какая-нибудь особенность реализации, которую нам ну никак не угадать "общими размышлениями".
смысл в том, чтобы проггеры с "суконным рылом" не гоношились в динамических структурах порождаемых экспортируемым модулем.
Эмм.. Не понял. А что динамического вот в этом:
VAR
rec : RECORD i,j,k : INTEGER END;
-
Эмм.. Не понял. А что динамического вот в этом:
VAR
rec : RECORD i,j,k : INTEGER END;
в этом - ничего, но произвольная запись может содержать указатели в качестве полей.
-
Экспортировать можно только read only. А для сложных типов сделать read only видимо проблематично. Вот и запретил... :-)
Я тоже так думаю. Ниасилил научить компилятор следить за константностью экспортированных записей. Когда осилит, тогда и разрешит.
-
Я тоже так думаю. Ниасилил научить компилятор следить за константностью экспортированных записей. Когда осилит, тогда и разрешит.
read-only для записаей/массивов прописано для случая не-VAR параметров процедуры. И я бы не сказал, что там какие-то сложности в реализации.
-
Я тут грешным делом вкуриваю компилятор и прочие модули что в Project Oberon 2013, по идее он должен быть писан на неком переходном языке (Oberon 1990 -> Oberon 2013), так вот, у Вирта там из модулей вполне экспортируются массивы:
MODULE ORS;
TYPE Ident* = ARRAY IdLen OF CHAR;
VAR id*: Ident;
END ORS.
Внимание вопрос - это мы так не правильно поняли что есть скаляр, или же в PO2013 таки язык разрешает экспортировать не скаляры?
-
А вот еще интересней:
MODULE Oberon;
TYPE
Marker* = RECORD Fade*, Draw*: Painter END;
VAR
Arrow*, Star*: Marker;
END Oberon.
То есть тут вообще экспортируются прям таки голые RECORD'ы.
-
Ну вот, по крайней мере этот вопрос похоже закрыт - получил ответ (народ проконсультировался с Виртом и ответил мне как оно на самом деле):
From: Diego Sardina
Subject: Export of scalar/non scalar variables.
Hi there,
> But there is no definition for scalar type.
I asked Prof. Wirth more details about the term scalar type used in the Oberon Report. He replied with:
>> The word "scalar" means "on a scale". It is not a specific technical term.
>> As for Oberon, it is actually synonymous with basic, or with "not
>> structured".
>> Both unstructured and structured variables are supposd to be exported as "read-only".
He also sent me a more recent report with the correct sentence, it is now:
>> Variables are always exported in read-only mode.
This is the reason structured variables are exported in the new Oberon book.
> Thanks, Alexey.
-
>> The word "scalar" means "on a scale". It is not a specific technical term.
>> As for Oberon, it is actually synonymous with basic, or with "not
>> structured".
Блин, вот по-нормальному все равно не сказать! Что такое "not structured"??? Поинтеры/массивы/процедуры сюда входят или нет?
-
>> The word "scalar" means "on a scale". It is not a specific technical term.
>> As for Oberon, it is actually synonymous with basic, or with "not
>> structured".
Блин, вот по-нормальному все равно не сказать! Что такое "not structured"??? Поинтеры/массивы/процедуры сюда входят или нет?
А понятие структурных типов вроде бы в репорте как раз есть.
Впрочем, разве где-то еще кроме этого места скалярные типы упоминались?
-
Впрочем, разве где-то еще кроме этого места скалярные типы упоминались?
Оно упоминается в формальных параметрах процедур. И там оно имеет смысл (из общих соображений) для базовых типов, поинтеров и процедурных типов.
-
Впрочем, разве где-то еще кроме этого места скалярные типы упоминались?
Оно упоминается в формальных параметрах процедур. И там оно имеет смысл (из общих соображений) для базовых типов, поинтеров и процедурных типов.
Ну, что такое структурный тип в репорте определено четко:
StrucType = ArrayType | RecordType | PointerType | ProcedureType.
Другое дело что Вирт опять неоднозначно ответил:
>> The word "scalar" means "on a scale". It is not a specific technical term.
>> As for Oberon, it is actually synonymous with basic, or with "not
>> structured".
При этом basic и structured type определены в репорте четко.