Oberon&INС/DEC

[valexey]

Помнится кто-то говорил, что в Обероне INC/DEC были введены, ибо они отражают напрямую асмовые команды увеличения на единицу и уменьшения. То есть когда компилятор видит это, он не думает, а просто генерит напрямую соответствующий код. По сути это практически получаются прямые асмовые вставки.

Теперь предположим, что мы затачиваем Оберон, создавая его диалект, под собственную железку. В железке INC и x:=x+1 и даже x:=a+b - один фиг. То есть там нет выделенной команды для инкремента и/или декремента.

Теперь вопрос - нужно ли нам в этом самом диалекте в обязательном порядке оставить эти самые INC/DEC? Ведь они будут только смущать программиста, он будет думать, что это оптимальней. А это не так. И вообще это плодит сущности и делает язык толще.

[Peter Almazov]

Не надо.
Я сильно помог? 

[igor]

Более того, в реализации  XDS оператор x := x + a не всегда можно тупо заменить на INC(x, a). Не смотря на то, что эти два случая отличаются только формой записи, во втором случае компилятор начинает материться на несовместимость типов, а первый случай с теми же самыми аргументами проглатывает не поморщившись. 

[valexey]

Ага. Значит INC/DEC в топку.

[Geniepro]

ну, теоретически, inc/dec более прямо демонстрируют намерение программиста, да и меньше шансов сделать ашыпку типа x := y + a; вместо x := x + a; если программер хотел сделать inc(x, a);

[valexey]

ну, теоретически, inc/dec более прямо демонстрируют намерение программиста, да и меньше шансов сделать ашыпку типа x := y + a; вместо x := x + a; если программер хотел сделать inc(x, a);

INC(x,a) синтаксически гадость - не понятно кто тут вход а кто выход (и есть ли выход вообще). Легко перепутается с INC(a,x) (при условии что и a и x это переменная а не литерал).

[valexey]

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

Ну и тем более INC(что-то-там) плох тем, что это не процедура по сути, а statement замаскированный под вызов процедуры.

[igor]

Более того, в реализации  XDS ...

Ага. Значит INC/DEC в топку.

Только нужно ещё иметь в виду, что в данном случае и реализация может быть не совсем удачная. Хотя, защищать INC/DEC я не берусь.

[Vartovyj]

Мне нравятся Си-подобные конструкции, которые, имхо, очень даже подойдут Оберону:
x:=x+1    |    x++
x:=x+a    |    x+=a

[valexey]

Мне нравятся Си-подобные конструкции, которые, имхо, очень даже подойдут Оберону:
x:=x+1    |    x++
x:=x+a    |    x+=a

[DIzer]

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

Ну и тем более INC(что-то-там) плох тем, что это не процедура по сути, а statement замаскированный под вызов процедуры.

На мой взгляд, эта  процедура себя оправдывает только в том случае когда по второму параметру передается ЗНАЧЕНИЕ сложного выражения.По - факту, новички обычно не ошибаются с вызовами этой процедуры  (те кто ее использует).

[Vartovyj]

x+=a; без ":"

[valexey]

x+=a; без ":"

Ну это ж полсинтаксиса переделывать :-) тогда и обычное присваивание будет =, а если так, то сравнение будет уже что-то другое. ==? но это как-то по уродски смотрится (несмотря на то что привык). А если инкремент сделать через +=, а просто присваивание через :=, то это ж неконсистентность синтаксиса выходит. То есть опять таки не красиво.

Поэтому делаем просто - выкидываем инкремент вообще нафиг. Ибо нинужен. :-)

PS. Если что - посмотрите на первое сообщение топика, там ясно, что я смотрю не в сторону совсем уж general purpose языка для жирного десктопного железа, меня сейчас больше мелкоконтроллеры заботят, а там взаимнооднозначность важна. И если чел видит x:=x+1 в одном месте, а в другом INC(x), то это действительно, РЕАЛЬНО должен быть разный код, а не потому, что левой пятке зачесалось. Байты имеют значение.

[DIzer]

И если чел видит x:=x+1 в одном месте, а в другом INC(x), то это действительно, РЕАЛЬНО должен быть разный код, а не потому, что левой пятке зачесалось. Байты имеют значение.

А это еще с какого перепугу  - все таки Оберон ЯВУ, а то про что вы пишите даже СИ не гарантирует.

[valexey]

И если чел видит x:=x+1 в одном месте, а в другом INC(x), то это действительно, РЕАЛЬНО должен быть разный код, а не потому, что левой пятке зачесалось. Байты имеют значение.

А это еще с какого перепугу  - все таки Оберон ЯВУ, а то про что вы пишите даже СИ не гарантирует.

В этом самом ЯВУ INC является рудиментом ЯНУ, да еще и не актуальной железяки. В сях, кстати, аналогично. А вот в С++ уже нет.