[Oberon 07/13] Запретить параметры по ссылке

[ilovb]

vlad высказывался, что VAR - это моветон. С чем я не согласен, ибо не могу представить себе процедурное программирование без параметров, передаваемых по ссылке. С другой стороны есть проблема при чтении кода, если VAR параметры никак не выделяются.
Т.е. хочется чтобы синтаксис помогал видеть эти самые VAR параметры.

Какие есть варианты? И какой из них лучше?
1. Оставить как есть, но явно помечать при вызове как в C#
2. Запретить передачу по ссылке, но разрешить процедуре возвращать несколько значений как в Lua
3.

[Geniepro]

Пункт 2 не очень подходит как причина для убирания VAR-параметров, так как может понизить эффективность кода за счёт нежелательных копирований тяжёлых структур.
Так что лучше пункт 1 -- раз уж параметр процедуры объявляется как VAR, то и при вызове этой процедуры этот параметр тоже должен помечаться как VAR. В этом плане в сишарпе сделано правильно...

[valexey_u]

Да сделать как в Go, и не париться :-) То есть возвращение нескольких переменных - это чисто процедурная фича же.

Но тут есть засада - если так сделать, то возникает сильный соблазн все возникшие ошибки возвращать исключительно в качестве одного из возвращаемых значений функции. А это убого, это ОЧЕНЬ убого. Это даже хуже чем когда код ошибки возвращается как результат, а результат заполняется как VAR-аргумент. Я на это в Go уже напоролся - мне очень не понравилось писать в таком стиле. Код становится либо нечитабельным, либо просто начинаешь плевать на обработку ошибок.

[valexey_u]

Пункт 2 не очень подходит как причина для убирания VAR-параметров, так как может понизить эффективность кода за счёт нежелательных копирований тяжёлых структур.

Откуда бы им там взяться, этим лишним копированиям? Менять VAL-переменную все равно нельзя, так что ничто не мешает тяжелые переменные передавать не копированием, а банально указатель/ссылку передавать. Но это уже нюансы реализации абсолютно прозрачные для пользователя. (реализация может быть любой - например на четных строках вызова функции компилятор может копировать всю процедуру, а на не четных работать через адреса)

[Geniepro]

Пункт 2 не очень подходит как причина для убирания VAR-параметров, так как может понизить эффективность кода за счёт нежелательных копирований тяжёлых структур.

Откуда бы им там взяться, этим лишним копированиям? Менять VAL-переменную все равно нельзя, так что ничто не мешает тяжелые переменные передавать не копированием, а банально указатель/ссылку передавать. Но это уже нюансы реализации абсолютно прозрачные для пользователя. (реализация может быть любой - например на четных строках вызова функции компилятор может копировать всю процедуру, а на не четных работать через адреса)

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

Ну что же, welcome to haskell!

[vlad]

Какие есть варианты? И какой из них лучше?
1. Оставить как есть, но явно помечать при вызове как в C#
2. Запретить передачу по ссылке, но разрешить процедуре возвращать несколько значений как в Lua
3.

Я бы ничего не запрещал - можно придумать ситуации, когда VAR даже для скалярных типов имеет смысл. Но разрешил бы возвращать рекорды наряду со скалярными типами.
При этом да, можно синтаксически усложнить жизнь любителям все делать по ссылке и заставить писать их в месте вызова "ref" (как в  C#) или еще чего.

[vlad]

Я бы ничего не запрещал - можно придумать ситуации, когда VAR даже для скалярных типов имеет смысл. Но разрешил бы возвращать рекорды наряду со скалярными типами.
При этом да, можно синтаксически усложнить жизнь любителям все делать по ссылке и заставить писать их в месте вызова "ref" (как в  C#) или еще чего.

Основная идея расширения оберона все та же: не запрещать "сомнительные" конструкции (потому как они всякие нужны), а делать их более явными. В тоже время дать альтетрнативу таким конструкциям (для 90% случаев) в виде максимально простого и наглядного кода.