Oberon&INС/DEC

[vlad]

Библиотека не катит. "module.inc(x, y)" сильно проигрывает "x += y". Должно быть в языке. Можно поспорить "насколько сильно это нужно по сравнению с ...". Конечно есть более важные свойства. Но тем не менее - такая запись имеет преимущества по сравнению с аналогами.

Зачем, если (как Алексей правильно заметил), ПО СУТИ все ее преимущество аналогично преимуществу SQR(x) над x*x - почему "должно", нафига нам 3 оператора присваивания (+= -= :=),

Потому что часто используется (по сравнению с SQR). И яснее выражает намерения (лучше воспринимается). "Увеличить X на Y" против "Присвоить X сумму X и Y".

а может еще пару ввести /=  *=   

Да, это подразумевалось. Ну и битовые конечно: &=, |=. Битовые даже "нужнее" арифметических.

[DIzer]

Потому что часто используется (по сравнению с SQR). И яснее выражает намерения (лучше воспринимается). "Увеличить X на Y" против "Присвоить X сумму X и Y".

не знаю , по мне x:=2*x+x*x+F(x,10)  гораздо естественнее чем ублюдочное  x+=x+x*x+F(x,10)

[vlad]

Потому что часто используется (по сравнению с SQR). И яснее выражает намерения (лучше воспринимается). "Увеличить X на Y" против "Присвоить X сумму X и Y".

не знаю , по мне x:=2*x+x*x+F(x,10)  гораздо естественнее чем ублюдочное  x+=x+x*x+F(x,10)

Пример искуственный и ничего не показывает, кроме использования фичи "не по месту". Конечно никто (кто хочет "лучшего восприятия") не будет писать += в таком выражении.

[DIzer]

Потому что часто используется (по сравнению с SQR). И яснее выражает намерения (лучше воспринимается). "Увеличить X на Y" против "Присвоить X сумму X и Y".

не знаю , по мне x:=2*x+x*x+F(x,10)  гораздо естественнее чем ублюдочное  x+=x+x*x+F(x,10)

Пример искуственный и ничего не показывает, кроме использования фичи "не по месту". Конечно никто (кто хочет "лучшего восприятия") не будет писать += в таком выражении.

  Да ну ,  вместо бурды  ""Увеличить X на Y" против "Присвоить X сумму X и Y"." - всего лишь одно ВЫЧИСЛИТЬ ЗНАЧЕНИЕ ВЫРАЖЕНИЯ В ПРАВОЙ ЧАСТИ И ЗАПИСАТЬ ЕГО В ПЕРЕМЕННУЮ СТОЯЩУЮ В ЛЕВОЙ ЧАСТИ - вот это МОЕ НАМЕРЕНИЕ  и для его реализации вполне хватает ОДНОГО оператора присваивания для всех 6 вариантов.

[Peter Almazov]

Ну и бог бы с ним, а что по поводу псевдокарринга  с помощью дефолтных параметров?

Мне кажется, я не совсем понял суть предложения. Можно пример?

Запросто , допустить такую вещь
DEC(VAR a:INTEGER; b:INTEGER:=-1 )
  Пример ублюдочного карринга (каррирования)
VAR val2d,val1d:REAL;
PROCEDURE  _LEN(X:REAL;Y:REAL:=0; Z:REAL:=0  ):REAL;
BEGIN  RETURN  SQRT(x*x+y*y+z*z)  END _LEN;

BEGIN
......
val2d:=_LEN(5,6);
val1d:=_LEN(5);
.....

ну или чуть покруче
TYPE
Proc=PROCEDURE (X:REAL; Y:REAL=0; Z:REAL:=0):REAL;

Это не карринг, а опциональные параметры.

[vlad]

  Да ну ,  вместо бурды  ""Увеличить X на Y" против "Присвоить X сумму X и Y"." - всего лишь одно ВЫЧИСЛИТЬ ЗНАЧЕНИЕ ВЫРАЖЕНИЯ В ПРАВОЙ ЧАСТИ И ЗАПИСАТЬ ЕГО В ПЕРЕМЕННУЮ СТОЯЩУЮ В ЛЕВОЙ ЧАСТИ - вот это МОЕ НАМЕРЕНИЕ  и для его реализации вполне хватает ОДНОГО оператора присваивания для всех 6 вариантов.

Больше похоже на намерение процессора Типа "мое дело взять отсюда, сделать это, и положить туда". А какое там было НАМЕРЕНИЕ у программиста и какое это имеет отношение к предметной области - не важно, на результат не влияет

[DIzer]

Это не карринг, а опциональные параметры.

точнее "параметры по умолчанию" или дефолтные.  Ну да , я и  сказал что это псевдо карринг ( более точно ублюдочный)  -  в данном случае введение их позволило разгрузить язык , от не совсем вписывающихся в него DEC, INC - понизив их до обычных процедур.
Но что мешает нам двигаться далее в этом направлении?
Type
 Pr=PROCEDURE(X:REAL; Y:REAL:=0; Z:REAL:=0):REAL;
Var c1,c2: Pr;
.....
c1:=_LEN(x,y,0);
c2:=_LEN(x,5,4);

[DIzer]

Больше похоже на намерение процессора Типа "мое дело взять отсюда, сделать это, и положить туда". А какое там было НАМЕРЕНИЕ у программиста и какое это имеет отношение к предметной области - не важно, на результат не влияет

  Хитрите Vlad - намерение программиста в первом приближении- либо составить  алгоритм исходя из  задачи , либо заложить его в компутер  заставив решать задачи (либо то и то)- и не фиг  ЯВУ мешать ему в этом - в любом случае, в  мою голову не влазит , каким образом Ваши ШЕСТЬ вариантов могут помочь ему в этом  (в сравнении с ОДНИМ моим).
 Хотя, конечно, - что там часто случается умножение и деление на два ? - да нет проблем - введем операторы 2/=   и 2*= (для самовыражения программиста) 

[DIzer]

да нет проблем - введем операторы 2/=   и 2*= (для самовыражения программиста) 

таки /2=  и *2= - представляется  более взвешенным решением      , а компьютер - не имеет своего намерения и вообще не знает что такое переменная  -или я несовременен ? , да, каюсь, но лет 20 назад все было именно так.... но тогда проггеров было достаточно мало, и не было у "дедков" от программирования нужды проводить отсеивания конкурентов, путем введения доп. операторов в язык и забивающей мозги болтовни..

[vlad]

Больше похоже на намерение процессора Типа "мое дело взять отсюда, сделать это, и положить туда". А какое там было НАМЕРЕНИЕ у программиста и какое это имеет отношение к предметной области - не важно, на результат не влияет

  Хитрите Vlad - намерение программиста в первом приближении- либо составить  алгоритм исходя из  задачи , либо заложить его в компутер  заставив решать задачи (либо то и то)- и не фиг  ЯВУ мешать ему в этом - в любом случае, в  мою голову не влазит , каким образом Ваши ШЕСТЬ вариантов могут помочь ему в этом 

Вы забыли про то, что потом программу надо будет прочесть и понять, что она делает применительно к предметной области. Причем возможно, что читать будет другой программист. Вот тут и начинается ЯВУ. И особенности синтаксиса (записи) начинают играть значение. А то да, можно было бы и на перле писать все скрипты

(в сравнении с ОДНИМ моим).
 Хотя, конечно, - что там часто случается умножение и деление на два ? - да нет проблем - введем операторы 2/=   и 2*= (для самовыражения программиста) 

Форма записи одна, использующая уже известные "значки" операций, не надо хитрить.  Операторы "2/=" не нужны: обсуждаемая форма замечательно покрывает эти частые операции:  x /= 2, x *= 2.

[DIzer]

Вы забыли про то, что потом программу надо будет прочесть и понять, что она делает применительно к предметной области. Причем возможно, что читать будет другой программист. Вот тут и начинается ЯВУ. И особенности синтаксиса (записи) начинают играть значение. А то да, можно было бы и на перле писать все скрипты

 

Ну если  программист будет из лиги "любителей 6 видов присваивания" то наверное да....  Но вы мне так и не ответили каким образом ему поможет разбираться в  задаче членство в этом элитарном клубе 

Форма записи одна, использующая уже известные "значки" операций, не надо хитрить.  Операторы "2/=" не нужны: обсуждаемая форма замечательно покрывает эти частые операции:  x /= 2, x *= 2.

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

[Geniepro]

x+=a; без ":"

Паскаль ближе к алголу, чем к сям, а значит должно быть: x +:= a, а не x += a.

+:=  -- это стандартная операция в алголе-68...