Oberon space
General Category => Общий раздел => Тема начата: valexey от Январь 19, 2012, 10:43:50 pm
-
Помнится кто-то говорил, что в Обероне INC/DEC были введены, ибо они отражают напрямую асмовые команды увеличения на единицу и уменьшения. То есть когда компилятор видит это, он не думает, а просто генерит напрямую соответствующий код. По сути это практически получаются прямые асмовые вставки.
Теперь предположим, что мы затачиваем Оберон, создавая его диалект, под собственную железку. В железке INC и x:=x+1 и даже x:=a+b - один фиг. То есть там нет выделенной команды для инкремента и/или декремента.
Теперь вопрос - нужно ли нам в этом самом диалекте в обязательном порядке оставить эти самые INC/DEC? Ведь они будут только смущать программиста, он будет думать, что это оптимальней. А это не так. И вообще это плодит сущности и делает язык толще.
-
Не надо.
Я сильно помог? :)
-
Более того, в реализации XDS оператор x := x + a не всегда можно тупо заменить на INC(x, a). Не смотря на то, что эти два случая отличаются только формой записи, во втором случае компилятор начинает материться на несовместимость типов, а первый случай с теми же самыми аргументами проглатывает не поморщившись. :)
-
Ага. Значит INC/DEC в топку.
-
ну, теоретически, inc/dec более прямо демонстрируют намерение программиста, да и меньше шансов сделать ашыпку типа x := y + a; вместо x := x + a; если программер хотел сделать inc(x, a);
-
ну, теоретически, inc/dec более прямо демонстрируют намерение программиста, да и меньше шансов сделать ашыпку типа x := y + a; вместо x := x + a; если программер хотел сделать inc(x, a);
INC(x,a) синтаксически гадость - не понятно кто тут вход а кто выход (и есть ли выход вообще). Легко перепутается с INC(a,x) (при условии что и a и x это переменная а не литерал).
-
Поясню - INC(a) - тут однозначно что и с кем, ибо альтернативы вообще говоря нет. INC(a,b) - не понятно, ибо варианта два.
Ну и тем более INC(что-то-там) плох тем, что это не процедура по сути, а statement замаскированный под вызов процедуры.
-
Более того, в реализации XDS ...
Ага. Значит INC/DEC в топку.
Только нужно ещё иметь в виду, что в данном случае и реализация может быть не совсем удачная. Хотя, защищать INC/DEC я не берусь.
-
Мне нравятся Си-подобные конструкции, которые, имхо, очень даже подойдут Оберону:
x:=x+1 | x++
x:=x+a | x+=a
-
Мне нравятся Си-подобные конструкции, которые, имхо, очень даже подойдут Оберону:
x:=x+1 | x++
x:=x+a | x+=a
Ну, мало ли что нравится :-) Вопрос в необходимости. x+:=a будет смотреться слишком уж криптографически :-) А сам по себе x++ смысла несет не больше, чем INC(x). Хотя сишнику конечно на ++ смотреть приятней ;-)
-
Поясню - INC(a) - тут однозначно что и с кем, ибо альтернативы вообще говоря нет. INC(a,b) - не понятно, ибо варианта два.
Ну и тем более INC(что-то-там) плох тем, что это не процедура по сути, а statement замаскированный под вызов процедуры.
На мой взгляд, эта процедура себя оправдывает только в том случае когда по второму параметру передается ЗНАЧЕНИЕ сложного выражения.По - факту, новички обычно не ошибаются с вызовами этой процедуры (те кто ее использует).
-
x+:=a будет смотреться слишком уж криптографически :-)
x+=a; без ":"
-
x+:=a будет смотреться слишком уж криптографически :-)
x+=a; без ":"
Ну это ж полсинтаксиса переделывать :-) тогда и обычное присваивание будет =, а если так, то сравнение будет уже что-то другое. ==? но это как-то по уродски смотрится (несмотря на то что привык). А если инкремент сделать через +=, а просто присваивание через :=, то это ж неконсистентность синтаксиса выходит. То есть опять таки не красиво.
Поэтому делаем просто - выкидываем инкремент вообще нафиг. Ибо нинужен. :-)
PS. Если что - посмотрите на первое сообщение топика, там ясно, что я смотрю не в сторону совсем уж general purpose языка для жирного десктопного железа, меня сейчас больше мелкоконтроллеры заботят, а там взаимнооднозначность важна. И если чел видит x:=x+1 в одном месте, а в другом INC(x), то это действительно, РЕАЛЬНО должен быть разный код, а не потому, что левой пятке зачесалось. Байты имеют значение.
-
И если чел видит x:=x+1 в одном месте, а в другом INC(x), то это действительно, РЕАЛЬНО должен быть разный код, а не потому, что левой пятке зачесалось. Байты имеют значение.
А это еще с какого перепугу - все таки Оберон ЯВУ, а то про что вы пишите даже СИ не гарантирует. :(
-
И если чел видит x:=x+1 в одном месте, а в другом INC(x), то это действительно, РЕАЛЬНО должен быть разный код, а не потому, что левой пятке зачесалось. Байты имеют значение.
А это еще с какого перепугу - все таки Оберон ЯВУ, а то про что вы пишите даже СИ не гарантирует. :(
В этом самом ЯВУ INC является рудиментом ЯНУ, да еще и не актуальной железяки. В сях, кстати, аналогично. А вот в С++ уже нет.
-
В этом самом ЯВУ INC является рудиментом ЯНУ, да еще и не актуальной железяки. В сях, кстати, аналогично. А вот в С++ уже нет.
У вас в рассуждениях серьезная ошибка - которой страдают все жестянщики - вы отождествляете модель с реализацией - это не верно. Но беда даже не в этом - каждый раз когда вы это делаете, вы подменяете множество ДОПУСТИМЫХ решений вопроса ОБЩЕПРИНЯТЫМИ.
-
В этом самом ЯВУ INC является рудиментом ЯНУ, да еще и не актуальной железяки. В сях, кстати, аналогично. А вот в С++ уже нет.
У вас в рассуждениях серьезная ошибка - которой страдают все жестянщики - вы отождествляете модель с реализацией - это не верно. Но беда даже не в этом - каждый раз когда вы это делаете, вы подменяете множество ДОПУСТИМЫХ решений вопроса ОБЩЕПРИНЯТЫМИ.
Это я то жестянщик? :-D
Еще раз - в данном конкретном случае мне не нужна абстрактная вундервафля. Мне интересно посмотреть что можно сделать для решения вполне конкретных проблем которые возникают при программировании мелкоконтроллеров, причем, для начала, для вполне конкретных мелкоконтроллеров. Ибо то что там сейчас - это жесть и содомия (к которой, впрочем, все привыкли).
Если уж кому-то сильно хочется INC, то я не стал бы вносить этот INC в язык, я бы просто добавил в язык inline-функции/процедуры. И тогда это INCоподобное сможет реализовывать каждый по мере своих потребностей. А сам INC можно засунуть например в стандартную либу. Правда, следуя обероновским правилам, придется писать нечто вроде: "Int.INC(a)", где Int - имя модуля где лежит INC. :-)
-
Это я то жестянщик? :-D
Да
Еще раз - в данном конкретном случае мне не нужна абстрактная вундервафля. Мне интересно посмотреть что можно сделать для решения вполне конкретных проблем которые возникают при программировании мелкоконтроллеров, причем, для начала, для вполне конкретных мелкоконтроллеров. Ибо то что там сейчас - это жесть и содомия (к которой, впрочем, все привыкли).
Это только подтверждает тезис выше..... Если для Ваших задач СУЩЕСТВЕННА разница в каком месте сидит значение (регистр процессора, ячейка ОЗУ) - используйте ассемблер, зачем морочить людям голову.... ОБЕРОН это ЯВУ. Хотя можно конечно поставить вопрос о создания псевдонизкоуровневого языка с синтаксисом оберона, который будет обеспечивать ваши запросы - но это ДРУГАЯ постановка вопроса....
-
Это только подтверждает тезис выше..... Если для Ваших задач СУЩЕСТВЕННА разница в каком месте сидит значение (регистр процессора, ячейка ОЗУ) - используйте ассемблер, зачем морочить людям голову.... ОБЕРОН это ЯВУ. Хотя можно конечно поставить вопрос о создания псевдонизкоуровневого языка с синтаксисом оберона, который будет обеспечивать ваши запросы - но это ДРУГАЯ постановка вопроса....
А как только дело доходит до реальных применений, оно становится существенно почти всегда. В регистре сидит оно, на стэке, или в куче, если на стеке или в куче, то есть ли это значение в кеше первого уровня, или оно в кэше второго уровня? или третьего? или просто в ОЗУ? или вообще в своп уже уехало?
Подобные вещи не существенны когда на современном железе решают проблемы двадцатилетней давности. Тогда да, можно позволить себе абстрагироваться от реальной машины по полной программе. Правда чаще всего такие задачи на таком железе решаются чисто в учебных целях в учебных же учреждениях. Либо это какой-то мелкий скриптинг (не важно на каком языке - плюсах, паскале или питоне).
-
А как только дело доходит до реальных применений, оно становится существенно почти всегда.....
Подобные вещи не существенны когда на современном железе решают проблемы двадцатилетней давности. ....
Это в ВАШИХ задачах, вы -не пуп земли , хе, беда прям с вами господа жестянщики...
-
А как только дело доходит до реальных применений, оно становится существенно почти всегда.....
Подобные вещи не существенны когда на современном железе решают проблемы двадцатилетней давности. ....
Это в ВАШИХ задачах, вы -не пуп земли , хе, беда прям с вами господа жестянщики...
Ну, возможно да, мне просто так "везло", что на всех работах я всегда наталкивался на то, что от железяки полностью абстрагироваться нельзя. Равно как и у дргих с кем я знаком. Впрочем, разговор ушел от основной темы достаточно далеко. Начну ка для него я новую тему.
-
Создал тему. Тут: http://oberspace.dyndns.org/index.php/topic,163.0.html
-
Теперь вопрос - нужно ли нам в этом самом диалекте в обязательном порядке оставить эти самые INC/DEC? Ведь они будут только смущать программиста, он будет думать, что это оптимальней. А это не так. И вообще это плодит сущности и делает язык толще.
Нафиг. Но вот "+=" было бы полезным. Более явно отражает намерения.
P.S. "++" актуально только для сишных указателей. Типа *dst++ = *src++ рулит. В языке без указателей - ненужно.
-
Нафиг. Но вот "+=" было бы полезным. Более явно отражает намерения.
P.S. "++" актуально только для сишных указателей. Типа *dst++ = *src++ рулит. В языке без указателей - ненужно.
По поводу этого варианта - я согласен с Алексеем - нафиг плодить сущности.... Но как вам нравится такой вариант - ввести дефолтные параметры в подпрограммы и запихнуть эту процедуру в бибилиотеку (в этом случае эта процедура ничем выделятся не будет от остальных) ? ;)
-
Нафиг. Но вот "+=" было бы полезным. Более явно отражает намерения.
P.S. "++" актуально только для сишных указателей. Типа *dst++ = *src++ рулит. В языке без указателей - ненужно.
По поводу этого варианта - я согласен с Алексеем - нафиг плодить сущности.... Но как вам нравится такой вариант - ввести дефолтные параметры в подпрограммы и запихнуть эту процедуру в бибилиотеку (в этом случае эта процедура ничем выделятся не будет от остальных) ? ;)
Библиотека не катит. "module.inc(x, y)" сильно проигрывает "x += y". Должно быть в языке. Можно поспорить "насколько сильно это нужно по сравнению с ...". Конечно есть более важные свойства. Но тем не менее - такая запись имеет преимущества по сравнению с аналогами.
-
Библиотека не катит. "module.inc(x, y)" сильно проигрывает "x += y". Должно быть в языке. Можно поспорить "насколько сильно это нужно по сравнению с ...". Конечно есть более важные свойства. Но тем не менее - такая запись имеет преимущества по сравнению с аналогами.
Зачем, если (как Алексей правильно заметил), ПО СУТИ все ее преимущество аналогично преимуществу SQR(x) над x*x - почему "должно", нафига нам 3 оператора присваивания (+= -= :=), а может еще пару ввести /= *= :D
-
Библиотека не катит. "module.inc(x, y)" сильно проигрывает "x += y". Должно быть в языке. Можно поспорить "насколько сильно это нужно по сравнению с ...". Конечно есть более важные свойства. Но тем не менее - такая запись имеет преимущества по сравнению с аналогами.
Возможно действительно должно быть, по крайней мере исходя из железнячного шкурного интереса: INC(x)/x++ машина делать не умеет. Нет такой инструкции, а вот x+=y/INC(x,y) умеет. Но с точки зрения компилятора, это все равно баловство на самом деле. Ибо оптимизация элементарнейшая. Может быть еще на этапе "препроцессора" за километр до кодогенерации. Распознать и заменить x:=x+y на x+=y - нефиг делать.
Кроме того, мне не жутко не нравится синтаксическая форма x+=y в контексте синтаксиса оберона. То есть не зная как с этим поступить, я скорее это дело вырезал бы из языка, отложив проблему на потом, нежели воткнул бы абы что, лишь бы былО.
А вопрос отображения x:=x+y на машкоды, можно решить инструментальными средствами.
-
.... я скорее это дело вырезал бы из языка, отложив проблему на потом, нежели воткнул бы абы что, лишь бы былО.
А вопрос отображения x:=x+y на машкоды, можно решить инструментальными средствами.
Ну и бог бы с ним, а что по поводу псевдокарринга с помощью дефолтных параметров?
-
Ну и бог бы с ним, а что по поводу псевдокарринга с помощью дефолтных параметров?
Мне кажется, я не совсем понял суть предложения. Можно пример?
-
Ну и бог бы с ним, а что по поводу псевдокарринга с помощью дефолтных параметров?
Мне кажется, я не совсем понял суть предложения. Можно пример?
Запросто , допустить такую вещь
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;
-
Библиотека не катит. "module.inc(x, y)" сильно проигрывает "x += y". Должно быть в языке. Можно поспорить "насколько сильно это нужно по сравнению с ...". Конечно есть более важные свойства. Но тем не менее - такая запись имеет преимущества по сравнению с аналогами.
Зачем, если (как Алексей правильно заметил), ПО СУТИ все ее преимущество аналогично преимуществу SQR(x) над x*x - почему "должно", нафига нам 3 оператора присваивания (+= -= :=),
Потому что часто используется (по сравнению с SQR). И яснее выражает намерения (лучше воспринимается). "Увеличить X на Y" против "Присвоить X сумму X и Y".
а может еще пару ввести /= *= :D
Да, это подразумевалось. Ну и битовые конечно: &=, |=. Битовые даже "нужнее" арифметических.
-
Потому что часто используется (по сравнению с SQR). И яснее выражает намерения (лучше воспринимается). "Увеличить X на Y" против "Присвоить X сумму X и Y".
не знаю , по мне x:=2*x+x*x+F(x,10) гораздо естественнее чем ублюдочное x+=x+x*x+F(x,10)
-
Потому что часто используется (по сравнению с SQR). И яснее выражает намерения (лучше воспринимается). "Увеличить X на Y" против "Присвоить X сумму X и Y".
не знаю , по мне x:=2*x+x*x+F(x,10) гораздо естественнее чем ублюдочное x+=x+x*x+F(x,10)
Пример искуственный и ничего не показывает, кроме использования фичи "не по месту". Конечно никто (кто хочет "лучшего восприятия") не будет писать += в таком выражении.
-
Потому что часто используется (по сравнению с 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"." - всего лишь одно ВЫЧИСЛИТЬ ЗНАЧЕНИЕ ВЫРАЖЕНИЯ В ПРАВОЙ ЧАСТИ И ЗАПИСАТЬ ЕГО В ПЕРЕМЕННУЮ СТОЯЩУЮ В ЛЕВОЙ ЧАСТИ - вот это МОЕ НАМЕРЕНИЕ ;D и для его реализации вполне хватает ОДНОГО оператора присваивания для всех 6 вариантов.
-
Ну и бог бы с ним, а что по поводу псевдокарринга с помощью дефолтных параметров?
Мне кажется, я не совсем понял суть предложения. Можно пример?
Запросто , допустить такую вещь
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;
Это не карринг, а опциональные параметры.
-
;) Да ну , вместо бурды ""Увеличить X на Y" против "Присвоить X сумму X и Y"." - всего лишь одно ВЫЧИСЛИТЬ ЗНАЧЕНИЕ ВЫРАЖЕНИЯ В ПРАВОЙ ЧАСТИ И ЗАПИСАТЬ ЕГО В ПЕРЕМЕННУЮ СТОЯЩУЮ В ЛЕВОЙ ЧАСТИ - вот это МОЕ НАМЕРЕНИЕ ;D и для его реализации вполне хватает ОДНОГО оператора присваивания для всех 6 вариантов.
Больше похоже на намерение процессора ;) Типа "мое дело взять отсюда, сделать это, и положить туда". А какое там было НАМЕРЕНИЕ у программиста и какое это имеет отношение к предметной области - не важно, на результат не влияет :)
-
Это не карринг, а опциональные параметры.
точнее "параметры по умолчанию" или дефолтные. Ну да , я и сказал что это псевдо карринг ( более точно ублюдочный) :D - в данном случае введение их позволило разгрузить язык , от не совсем вписывающихся в него 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);
-
Больше похоже на намерение процессора ;) Типа "мое дело взять отсюда, сделать это, и положить туда". А какое там было НАМЕРЕНИЕ у программиста и какое это имеет отношение к предметной области - не важно, на результат не влияет :)
;) Хитрите Vlad - намерение программиста в первом приближении- либо составить алгоритм исходя из задачи , либо заложить его в компутер заставив решать задачи (либо то и то)- и не фиг ЯВУ мешать ему в этом - в любом случае, в мою голову не влазит , каким образом Ваши ШЕСТЬ вариантов могут помочь ему в этом ;) (в сравнении с ОДНИМ моим).
Хотя, конечно, - что там часто случается умножение и деление на два ? - да нет проблем - введем операторы 2/= и 2*= (для самовыражения программиста) :)
-
да нет проблем - введем операторы 2/= и 2*= (для самовыражения программиста) :)
таки /2= и *2= - представляется более взвешенным решением ;D ;D ;D , а компьютер - не имеет своего намерения и вообще не знает что такое переменная ;D -или я несовременен ? , да, каюсь, но лет 20 назад все было именно так.... но тогда проггеров было достаточно мало, и не было у "дедков" от программирования нужды проводить отсеивания конкурентов, путем введения доп. операторов в язык и забивающей мозги болтовни.. ;D
-
Больше похоже на намерение процессора ;) Типа "мое дело взять отсюда, сделать это, и положить туда". А какое там было НАМЕРЕНИЕ у программиста и какое это имеет отношение к предметной области - не важно, на результат не влияет :)
;) Хитрите Vlad - намерение программиста в первом приближении- либо составить алгоритм исходя из задачи , либо заложить его в компутер заставив решать задачи (либо то и то)- и не фиг ЯВУ мешать ему в этом - в любом случае, в мою голову не влазит , каким образом Ваши ШЕСТЬ вариантов могут помочь ему в этом ;)
Вы забыли про то, что потом программу надо будет прочесть и понять, что она делает применительно к предметной области. Причем возможно, что читать будет другой программист. Вот тут и начинается ЯВУ. И особенности синтаксиса (записи) начинают играть значение. А то да, можно было бы и на перле писать все скрипты :)
(в сравнении с ОДНИМ моим).
Хотя, конечно, - что там часто случается умножение и деление на два ? - да нет проблем - введем операторы 2/= и 2*= (для самовыражения программиста) :)
Форма записи одна, использующая уже известные "значки" операций, не надо хитрить. Операторы "2/=" не нужны: обсуждаемая форма замечательно покрывает эти частые операции: x /= 2, x *= 2.
-
Вы забыли про то, что потом программу надо будет прочесть и понять, что она делает применительно к предметной области. Причем возможно, что читать будет другой программист. Вот тут и начинается ЯВУ. И особенности синтаксиса (записи) начинают играть значение. А то да, можно было бы и на перле писать все скрипты :)
Ну если программист будет из лиги "любителей 6 видов присваивания" то наверное да.... :) Но вы мне так и не ответили каким образом ему поможет разбираться в задаче членство в этом элитарном клубе ;)
Форма записи одна, использующая уже известные "значки" операций, не надо хитрить. Операторы "2/=" не нужны: обсуждаемая форма замечательно покрывает эти частые операции: x /= 2, x *= 2.
Ну испортили шутку - я всего лишь попытался высмеять "наивное" фичевание языка, путем применения аргументов аналогичных вашему...
но, чувствую, с прогерами нужно быть попроще... :)
-
x+:=a будет смотреться слишком уж криптографически :-)
x+=a; без ":"
Паскаль ближе к алголу, чем к сям, а значит должно быть: x +:= a, а не x += a.
+:= -- это стандартная операция в алголе-68...