Oberon&INС/DEC

[DIzer]

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

У вас в рассуждениях серьезная ошибка - которой страдают все жестянщики - вы отождествляете модель с реализацией  - это не верно. Но беда даже не в этом - каждый раз когда вы это делаете, вы подменяете множество  ДОПУСТИМЫХ решений вопроса ОБЩЕПРИНЯТЫМИ.

[valexey]

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

У вас в рассуждениях серьезная ошибка - которой страдают все жестянщики - вы отождествляете модель с реализацией  - это не верно. Но беда даже не в этом - каждый раз когда вы это делаете, вы подменяете множество  ДОПУСТИМЫХ решений вопроса ОБЩЕПРИНЯТЫМИ.

Это я то жестянщик? :-D

Еще раз - в данном конкретном случае мне не нужна абстрактная вундервафля. Мне интересно посмотреть что можно сделать для решения вполне конкретных проблем которые возникают при программировании мелкоконтроллеров, причем, для начала, для вполне конкретных мелкоконтроллеров. Ибо то что там сейчас - это жесть и содомия (к которой, впрочем, все привыкли).

Если уж кому-то сильно хочется INC, то я не стал бы вносить этот INC в язык, я бы просто добавил в язык inline-функции/процедуры. И тогда это INCоподобное сможет реализовывать каждый по мере своих потребностей. А сам INC можно засунуть например в стандартную либу. Правда, следуя обероновским правилам, придется писать нечто вроде: "Int.INC(a)", где Int - имя модуля где лежит INC. :-)

[DIzer]

Это я то жестянщик? :-D

Да

Еще раз - в данном конкретном случае мне не нужна абстрактная вундервафля. Мне интересно посмотреть что можно сделать для решения вполне конкретных проблем которые возникают при программировании мелкоконтроллеров, причем, для начала, для вполне конкретных мелкоконтроллеров. Ибо то что там сейчас - это жесть и содомия (к которой, впрочем, все привыкли).

  Это только подтверждает тезис выше..... Если для Ваших задач СУЩЕСТВЕННА разница в  каком месте сидит значение (регистр процессора, ячейка ОЗУ) - используйте ассемблер, зачем морочить людям голову.... ОБЕРОН это ЯВУ. Хотя можно конечно поставить вопрос о создания псевдонизкоуровневого языка с синтаксисом оберона, который будет обеспечивать ваши запросы - но это ДРУГАЯ постановка вопроса....

[valexey]

Это только подтверждает тезис выше..... Если для Ваших задач СУЩЕСТВЕННА разница в  каком месте сидит значение (регистр процессора, ячейка ОЗУ) - используйте ассемблер, зачем морочить людям голову.... ОБЕРОН это ЯВУ. Хотя можно конечно поставить вопрос о создания псевдонизкоуровневого языка с синтаксисом оберона, который будет обеспечивать ваши запросы - но это ДРУГАЯ постановка вопроса....

А как только дело доходит до реальных применений, оно становится существенно почти всегда. В регистре сидит оно, на стэке, или в куче, если на стеке или в куче, то есть ли это значение в кеше первого уровня, или оно в кэше второго уровня? или третьего? или просто в ОЗУ? или вообще в своп уже уехало?

Подобные вещи не существенны когда на современном железе решают проблемы двадцатилетней давности. Тогда да, можно позволить себе абстрагироваться от реальной машины по полной программе. Правда чаще всего такие задачи на таком железе решаются чисто в учебных целях в учебных же учреждениях. Либо это какой-то мелкий скриптинг (не важно на каком языке - плюсах, паскале или питоне).

[DIzer]

А как только дело доходит до реальных применений, оно становится существенно почти всегда.....

Подобные вещи не существенны когда на современном железе решают проблемы двадцатилетней давности. ....

Это в ВАШИХ задачах, вы  -не пуп земли , хе, беда прям с вами господа жестянщики...

[valexey]

А как только дело доходит до реальных применений, оно становится существенно почти всегда.....

Подобные вещи не существенны когда на современном железе решают проблемы двадцатилетней давности. ....

Это в ВАШИХ задачах, вы  -не пуп земли , хе, беда прям с вами господа жестянщики...

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

[valexey]

Создал тему. Тут: http://oberspace.dyndns.org/index.php/topic,163.0.html

[vlad]

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

Нафиг. Но вот "+=" было бы полезным. Более явно отражает намерения.

P.S. "++" актуально только для сишных указателей. Типа *dst++ = *src++ рулит. В языке без указателей - ненужно.

[DIzer]

Нафиг. Но вот "+=" было бы полезным. Более явно отражает намерения.

P.S. "++" актуально только для сишных указателей. Типа *dst++ = *src++ рулит. В языке без указателей - ненужно.

По поводу этого варианта - я согласен с Алексеем - нафиг плодить сущности.... Но как вам нравится такой вариант - ввести дефолтные параметры в подпрограммы и запихнуть эту процедуру в бибилиотеку (в этом случае эта процедура ничем выделятся не будет от остальных)  ? 

[vlad]

Нафиг. Но вот "+=" было бы полезным. Более явно отражает намерения.

P.S. "++" актуально только для сишных указателей. Типа *dst++ = *src++ рулит. В языке без указателей - ненужно.

По поводу этого варианта - я согласен с Алексеем - нафиг плодить сущности.... Но как вам нравится такой вариант - ввести дефолтные параметры в подпрограммы и запихнуть эту процедуру в бибилиотеку (в этом случае эта процедура ничем выделятся не будет от остальных)  ? 

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

[DIzer]

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

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

[valexey]

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

Возможно действительно должно быть, по крайней мере исходя из железнячного шкурного интереса: INC(x)/x++ машина делать не умеет. Нет такой инструкции, а вот x+=y/INC(x,y) умеет. Но с точки зрения компилятора, это все равно баловство на самом деле. Ибо оптимизация элементарнейшая. Может быть еще на этапе "препроцессора" за километр до кодогенерации. Распознать и заменить x:=x+y на x+=y - нефиг делать.

Кроме того, мне не жутко не нравится синтаксическая форма x+=y в контексте синтаксиса оберона. То есть не зная как с этим поступить, я скорее это дело вырезал бы из языка, отложив проблему на потом, нежели воткнул бы абы что, лишь бы былО.

А вопрос отображения x:=x+y на машкоды, можно решить инструментальными средствами.

[DIzer]

.... я скорее это дело вырезал бы из языка, отложив проблему на потом, нежели воткнул бы абы что, лишь бы былО.

А вопрос отображения x:=x+y на машкоды, можно решить инструментальными средствами.

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

[valexey]

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

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

[DIzer]

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

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

Запросто , допустить такую вещь
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;