OberonCore
https://forum.oberoncore.ru/

зачем и почему нельзя возвращать записи и массивы?
https://forum.oberoncore.ru/viewtopic.php?f=29&t=6319
Страница 2 из 2

Автор:  Info21 [ Вторник, 04 Декабрь, 2018 18:49 ]
Заголовок сообщения:  Re: зачем и почему нельзя возвращать записи и массивы?

Kemet писал(а):
Проблемы начинаются с головы, а не с языка программирования.
Причём особую роль играет голова, сочинившая язык программирования.

Автор:  Trurl [ Среда, 05 Декабрь, 2018 08:29 ]
Заголовок сообщения:  Re: зачем и почему нельзя возвращать записи и массивы?

budden писал(а):
Или всё же при передаче нужно одно копирование, а при возврате - два? Я запутался...

При передаче обычно обходятся без копирования, а при возврате... Ну, представьте стек при вызове concat(str(a), str(b)).

Автор:  budden [ Среда, 05 Декабрь, 2018 11:05 ]
Заголовок сообщения:  Re: зачем и почему нельзя возвращать записи и массивы?

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

Автор:  Илья Ермаков [ Среда, 05 Декабрь, 2018 11:09 ]
Заголовок сообщения:  Re: зачем и почему нельзя возвращать записи и массивы?

Передача параметров по ссылке, вообще-то. именно и существует, чтобы избежать копирования.
Для VAR- и OUT-параметров в процедуру копируется только адрес исходного объекта (записи или массива).

Автор:  Kemet [ Среда, 05 Декабрь, 2018 15:07 ]
Заголовок сообщения:  Re: зачем и почему нельзя возвращать записи и массивы?

Trurl писал(а):
budden писал(а):
Или всё же при передаче нужно одно копирование, а при возврате - два? Я запутался...

При передаче обычно обходятся без копирования, а при возврате... Ну, представьте стек при вызове concat(str(a), str(b)).
С учетом, что возвращается конкретный тип, куда входит размер массива, то представить легко. Другое дело, что мозг отключать очень вредно, ибо результат вряд-ли кому понравится.

Автор:  budden [ Среда, 05 Декабрь, 2018 16:08 ]
Заголовок сообщения:  Re: зачем и почему нельзя возвращать записи и массивы?

Илья Ермаков писал(а):
Передача параметров по ссылке, вообще-то. именно и существует, чтобы избежать копирования.
Для VAR- и OUT-параметров в процедуру копируется только адрес исходного объекта (записи или массива).

Но ведь и передача параметров по значению зачем-то существует.

Автор:  Валерий Лаптев [ Среда, 05 Декабрь, 2018 17:38 ]
Заголовок сообщения:  Re: зачем и почему нельзя возвращать записи и массивы?

Цитата:
Но ведь и передача параметров по значению зачем-то существует.

1. историческая причина - вспоминаем алгол-60.
2. Элементарные типы данных по размеру сопоставимы с адресами. Поэтому передача адресов встроенных типов практически смысла не имеет. Зачем делать косвенный доступ, когда можно прямой?
Собственно, вспоминаем яву: элементарные типы передаются по значению, объекты - по ссылке (адресу).

Автор:  budden [ Среда, 05 Декабрь, 2018 18:44 ]
Заголовок сообщения:  Re: зачем и почему нельзя возвращать записи и массивы?

Это был риторический вопрос :)

Автор:  Илья Ермаков [ Среда, 05 Декабрь, 2018 18:48 ]
Заголовок сообщения:  Re: зачем и почему нельзя возвращать записи и массивы?

budden писал(а):
Илья Ермаков писал(а):
Передача параметров по ссылке, вообще-то. именно и существует, чтобы избежать копирования.
Для VAR- и OUT-параметров в процедуру копируется только адрес исходного объекта (записи или массива).

Но ведь и передача параметров по значению зачем-то существует.


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

Ну т.е. для Do (IN ar: ARRAY OF INTEGER), если Вам понадобится массив того же размера (без перевыделения с запасом), то это на стеке не сделать.
Это в Аде размер массива на стеке может зависеть от параметров процедуры (кстати, средство-то как раз совсем несложное и очень практичное для системных задач).
Поэтому и бывает нужно Do (ar: ARRAY OF INTEGER). Хотя это, на мой вкус, пахнет нарушением сокрытия информации: потребность процедуры в копии массива влияет на её сигнатуру (впрочем, только на уровне требования перекомпиляции).

Так же и с расширяемыми записями - если нужна копия заранее неизвестного типа-расширения.

Автор:  budden [ Среда, 05 Декабрь, 2018 20:27 ]
Заголовок сообщения:  Re: зачем и почему нельзя возвращать записи и массивы?

Ну это Вы копнули гораздо глубже моего дилетантского понимания. Вы хотите сказать, в Обероне можно сделать то, чего нельзя в Си? Вроде же в Си так нельзя? :shock: Тут возникает ряд вопросов, но я имел в виду другие, более простые, на мой взгляд, вещи - копирование нужно для как минимум, для изоляции копии от оригинала. А изоляция нужна, прежде всего, чтобы обойтись без кучи - копия имеёт чётко заданное и очень простое время жизни. И при этом никакой не Раст.

Автор:  PSV100 [ Среда, 05 Декабрь, 2018 20:30 ]
Заголовок сообщения:  Re: зачем и почему нельзя возвращать записи и массивы?

Теперь стало понятным в полной мере основное требование "assignment compatible", которое касается в т.ч. и return (Oberon не применяю и не обращал внимание на такие особенности) -- из report-а о языке:
Цитата:
Appendix A: Definition of Terms
[...]
Assignment compatible
An expression e of type Te is assignment compatible with a variable v of type Tv if one of the
following conditions hold:
1. Te and Tv are equal and neither abstract, extensible, or limited record nor open array types;
[...]

И как я понимаю, изначально в Oberon-семействе все record-ы были расширяемые и позже в КП появились extensible-декларации с разделением методики типов, а ограничения для return исторически не изменились (при которых и статические массивы были забанены за компанию).

И, если не ошибаюсь (и просьба поправить в случае чего), вроде как имеются ещё и заморочки со структурной эквивалентностью вида:
VAR a: ARRAY 10 OF INTEGER;
VAR b: ARRAY 10 OF INTEGER;

Переменные a и b считаются разных типов, и не прокатит присваивание аля "a := b". Необходимо объявлять переменные вместе под единым типом ("VAR a, b: ..."), или объявлять тип отдельно с последующим применением. Если разрешить возвращать по значению всё то, что уже имеет разрешение для копирования, то для удобства напрашивается некий марафет имеющихся шероховатостей в языке.

Автор:  PSV100 [ Среда, 05 Декабрь, 2018 20:32 ]
Заголовок сообщения:  Re: зачем и почему нельзя возвращать записи и массивы?

Валерий Лаптев писал(а):
Собственно, вспоминаем яву: элементарные типы передаются по значению, объекты - по ссылке (адресу).

Кстати, лишний косвенный уровень доступа к объектам (и нагрузка на управление кучей) может сказываться при определенных сценариях, и в упомянутой Java, вроде как, всё же сдались и собираются ввести value-типы.

Автор:  PSV100 [ Среда, 05 Декабрь, 2018 20:35 ]
Заголовок сообщения:  Re: зачем и почему нельзя возвращать записи и массивы?

И всё же, в языке проглядывается дырка в надёжности. Выше в теме указывалось расширение Oberon-X, где кроме модифицированного return имеется и перегрузка операторов, включая и операцию присваивания ":=". Имхо, если подобные перегрузки ввести стандартом в язык, то уже вряд ли можно говорить о предельной простоте, особенно в случае образовательных основ, мол реализовать полноценно те же "комплексные числа" или специализированные контейнеры могут лишь "избранные". Хотя, для условных "избранных" перегрузка, скорее всего, будет удобством. Но на сегодня, вроде бы, есть запрет на "прямое" копирование для расширяемых типов (основное "боевое" средство для моделирования "в большом"), но есть косвенная возможность копий (через аргументы процедур, и я не в курсе всех возникающих нюансов при использовании массив), и в итоге нет полного контроля типа и специализированных средств в случае поддержки необходимости копирования. А если всё-таки вводить фундаментальную поддержку пользовательских типов, то при современном взгляде необходимо соблюдать и "строгие значения" -- уникальные типы, или иными словами каким-то способом предусматривать move-семантику (особенно при уже имеющейся концепции "лимитированных" типов) -- задача не простая, однако.

Страница 2 из 2 Часовой пояс: UTC + 3 часа
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/