OberonCore

Сигнал уже прошёл по другим каналам viewtopic.php?p=65464#p65464

http://www.astrobe.com/forum/viewtopic.php?f=4&t=129&sid=f2678c41fe23f89c25b7ebcc76c3d849&start=10#p270
дата файла oberon07.report.pdf от 15 сент.
вроде бы 10.1 немного исправлен, если не ошибаюсь.

Доковская версия 18-Aug-2011 10:38 --- http://www.inf.ethz.ch/personal/wirth/Articles/Oberon/
По всей видимости, pdf из неё генерируется.

вот как раз они и отличаются (pdf от doc)
по крайней мере из 10.1 удалено "Value parameters must not be of an array or record type.". (Видимо эта фраза избыточна)

из форума astrobe (сообщения админа сайта):
12 сент
"I have written to Prof Wirth for clarification as both sections dealing with parameters seem to have only been partially updated. Section 10.1 also is not consistent with Section 9.2.
I will report back here when I know more."

17 сент.
"A corrected version of the report can now be downloaded from Prof Wirth's site:"

Теперь разглядел. Большое спасибо.

Так которая версия правильная?

Адрес документа тот же: http://www.inf.ethz.ch/personal/wirth/A ... Report.pdf
Содержимое обновилось после 13-го числа. Правильную версию нужно повторно скачать.

Спасибо.

Для предотвращения таких случаев проще изначально указывать номер редакции (revision). Типа поля build в очередной сборке программы.

На странице проф.Вирта дата ревизии сообщения об языке теперь 22.09.2011

PS.
Ради интереса сравнил.

- п.4.
добавлено COPY и LONG
- п.9.1
добавлено:
Neither may assignments be made to imported variables.
удалено:
2. Arrays must have the same element type, and the length of the destination array must not be
less than the length of the source array.
- п.10.2
добавлено COPY(x, v) ...
- Appendix The Syntax of Oberon
мелкие исправления очепяток

PPS
в файле от 26.09.2011
- п.10.2
исправлен тип аргумента у NEW(v) с "base type" на "pointer type"

viewtopic.php?p=65821#p65821
Не знаю.
У меня в квази-арифметических алгоритмах это дело часто используется для размещения вспомогательных массивов. Длина вспомогательных массивов обычно равна (реже +\-1) длине "основного".

Можно, конечно, и обойтись. Но будет менее элегантно и чревато ошибками в ран-тайме (не та длина массива).

Можно не обходиться, а по-другому записать: viewtopic.php?p=65497#p65497

Это и есть "обойтись", которое имелось в виду.

А чем эти способы отличаются в плане задания длины массива?

А она статически неизвестна, нужен код для проверок и, если что, переразмещения на куче.

Так размер стэка по умолчанию один мегабайт. Раз у Вас всё на стеке раньше убиралось, то задайте статический размер того массива в мегабайт и перераспределять не надо будет, уберётся всегда.

Правда если вы любили там, например, рекурсию делать, то статический массив в пролёте...

В приведённом Вами способе размеры статически фиксированы PROCEDURE P (VAR A: ARRAY N OF Type; B, C: ARRAY N OF Type);

upd: По-моему, нестыковка. Может B, C д.б. открытыми массивами?

Что не так?

Проблема в том, что 2N > 1 мб могут быть. Если меньше, то проблем нет.

Да, все параметры должны быть открытыми массивами.

Предполагается, что процедура должна работать для любых массивов.

Пусть процедура должна что-то сделать с матрицей. Она эту матрицу получает в кач. единств. параметра.
Но внутри алгоритма нужна вспомогат. матрица или несколько.
Для алгоритма заводится внутренняя процедура, в которой вспомогат. матрицы создаются на стеке как value-параметры.

Рекурсия -- да, реально возможна.
---
Обойтись можно, это с самого начала ясно (более того, трюк с value-массивами пришел последним).
Но как-то чисто эстетически использовать глоб. переменную на куче не нравится.
Раз уж можно легко использовать стек, не оставляя за собой мусора.

Теперь понятно. И прямого аналога не видно, и, согласен, причина значимая.

Нужна возможность размещать "дин". массивы на стэке при входе в процедуру. Типа Должна ли она быть в языке или библиотеке? В сях есть что-то типа stack_alloc. В аде, может быть, можно размещать b, c: ARRAY LEN(a)...

Может спросите Вирта, что он по этому моменту думает?