Здравствуйте, Сергей Губанов, Вы писали:
СГ>Во всех инструкциях типа: IF, WHILE, REPEAT, CASE, WITH, и т.д. что очевидно из контекста обсуждения (модули и процедуры не обсуждались вообще).
Мне почему-то кажется, что если бы Вирт по какой-то причине оставил бы BEGIN скажем в инструкции WITH — его бы вы тоже предусмотрительно исключили бы из обсуждения.
Здравствуйте, Курилка, Вы писали:
К>Он очень хорошо демонстрирует, что верифицировать императивные языки, в которых есть побочные эффекты при вызове функций почти нельзя (за исключением тривиальных случаев), и Оберон тут ну ничем не лучше ни сей, ни явы, ни шарпа. Другое дело строгие функциональные языки, но не уверен, что Сергей хотябы представление о них имеет нормальное.
Оберон в этом плане лучше сей, хотя функциональные языки еще лучше.
Здравствуйте, alexku, Вы писали:
A>Здравствуйте, Сергей Губанов, Вы писали:
СГ>>Вы путаете процедуру с процедурой-функцией.
A>А вы путаете божий дар с яичницей.
A>
A>IF oneItem # anotherItem THEN
A>
A>Где в этом коде гарантия того, что я сравниваю значения переменных а не адреса процедур?
Процедурные переменные — тоже переменные, так что Вам нет ни какого дела до того, что внутри себя они содержат на самом деле адреса процедур. Думайте о них как просто о переменных значениями которых являются процедуры. Это повышает уровень абстракции. Так что тут IF oneItem # anotherItem THEN сравниваются две самых обычных переменных, и всёго-то.
Здравствуйте, Пацак, Вы писали:
П>Здравствуйте, Сергей Губанов, Вы писали:
СГ>>Речь шла не о служебном слове BEGIN, а о самостоятельном блоке BEGIN ... END, которого в Обероне нет.
П>И чем же пара BEGIN ... END в объявлении процедуры менее самостоятельна, чем в цикле или условном операторе? Тем, что Вирт не догадался написать что-нибудь типа PROCEDURE .... BEGPROC ... END? Или наоборот IF condition BEGIN END?
2) В, принципе, вместо слов IF, END и т.д. можно изобрести совершенно другие слова. Можно изобрести какую угодно другую семантику, но сам, так сказать, синтаксический скелет:
Здравствуйте, qwertyuiop, Вы писали:
Q>P.S. Значти, если в вашем знаменитом WHILE a DO x END у процедуры x будут аргументы, то надо написать скобки? Так же как и в С? Но тогда это повлияет на подсчет оверхеда! Вы не находите, что вы здесь слегка лукавите, придумывая выгодные вам примеры?
А я это не скрываю. Любому ясно что мое сообщение является гиперболизацией. Я об этом уже писал, но из-за того что сообщений слишком много, Вы, видимо, то мое сообщение не прочитали.
Здравствуйте, Трурль, Вы писали:
Т>А самому никак?
А разве я сказал "по определению"? Я всего лишь попросил обосновать Ваше утверждение. Естественно, могу, как смог Mamut чуть раньше. Но с каких дел я должен обосновывать утверждения оппонентов?
Здравствуйте, alexku, Вы писали:
A> А этим примером вы показали его незнание.
Вообще-то, этим примером я показал порочность побочного эффекта от того что выражение имеет значение, а также от того что из while можно выйти по break. Они провоцируют совершение глупых ошибок. Если бы этого не было, то глупые ошибки бы не провоцировались.
Здравствуйте, Сергей Губанов, Вы писали:
П>>И чем же пара BEGIN ... END в объявлении процедуры менее самостоятельна, чем в цикле или условном операторе? Тем, что Вирт не догадался написать что-нибудь типа PROCEDURE .... BEGPROC ... END? Или наоборот IF condition BEGIN END? СГ>На этот вопрос ответ уже был дан: http://www.rsdn.ru/Forum/Message.aspx?mid=1216614&only=1
Это не ответ на вопрос. Повторю его, если непонятно: чем использование BEGIN END в подпрограммах и модулях с синтаксической точки зрения отличается от использования его же в управляющих инструкциях? ИМХО — ничем. А в таком случае говорить, что эта связка в обероне не используется — явное лукавство.
Далее, по поводу звездочек (спустимся с небес на землю):
REPEAT x:=y() UNTIL b() = c() = * x * y * * * b * * * c * *
WHILE a() DO x := y() END = * a * * * x * y * * *
IF a = b() THEN x(c(), d()) END = * a * b * * * x * c * * * d * * * *
IF a() and ^b() THEN x:=z() ELSE y:=z() END = * a * * * * b * * * x * z * * * y * z * * *
IF a() THEN x:=k() ELSIF b() THEN y:=k() ELSE z:=k() END = * a * * * x * k * * * b * * * y * k * * * z * k * * *
CASE n() OF a(): i:=x() | b(): i:=y() ELSE i:=z() END = * n * * * a * * * i * x * * * b * * * i * y * * * i * z * * *
Итого имеем: строгое чередование лексема — звездочка наблюдается только в синтетических простейших случаях, имеющих мало общего с тем, что может встретиться в реальной программе. Ну и стоило ради этого огород городить?
СГ>2) В, принципе, вместо слов IF, END и т.д. можно изобрести совершенно другие слова. Можно изобрести какую угодно другую семантику, но сам, так сказать, синтаксический скелет:
СГ>имеющий всего лишь один единственный служебный разделитель — универсальная вещь — она не устареет никогда.
СГ>Не нравится слово BEGIN, ну что-же, придумайте свой язык и используйте любое другое слово, главное сохраните упомянутый выше "синтаксический скелет".
СГ>>Уверяю Вас это было видно сразу же по тексту программы. Ведь активация процедуры-функции всегда помечается скобками () даже если список параметров пуст.
M>Это сыграло мое неполное знание синтаксиса языка. В общем, такое же, как и у вас, когда вы сетовали на оператор "-->" в C++
Я сетовал на то что легко совершить глупую ошибку благодаря побочному эффекту. Языки же я знаю.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Здравствуйте, alexku, Вы писали:
A>> А этим примером вы показали его незнание.
СГ>Вообще-то, этим примером я показал порочность побочного эффекта от того что выражение имеет значение, а также от того что из while можно выйти по break. Они провоцируют совершение глупых ошибок. Если бы этого не было, то глупые ошибки бы не провоцировались.
Сергей, рядом уже было показано, что на Обероне можно получить такиеже грабли как и в любом другом императивном языке, т.к. мы не можем гарантировать отсутствие побочных эффектов. И не надо превозносить Оберон — до функциональных языков ему как отсюда до Сатурна. Провоцирует Оберон провоцирует, может на пару процентов меньше чем си или, скажем, шарп, не более...
Здравствуйте, Mamut, Вы писали:
M>То есть максимум, что отсюда получается, это designator := designator [([ExpList])]. В другой документации об этом ничего, вроде, не говорится.
Так ведь дело в том, что это не надо описывать с помощью EBNF. Это надо описать обычным языком. Точно также как, то что переменная перед использованием должна быть объявлена, точно также как то что имена переменных должны быть разными и т.д. и т.п. EBNF тут не силен.
M>Only one value, however, can be returned as the result of a function. This value, moreover, cannot be of a structured type.
Процедура-функция может возвращать переменные только базовых типов, но не может возвращать переменные сложных типов определенных пользователем (хотя указатели на них возвращать может, ведь указатель — тоже базовый тип). До Delphi 3 (или 4?) в Object Pascal было аналогичное ограничение.
M>Кстати, я, по-моему, только сейчас понял ту идею, которую хотел донести Сергей, когда он начинал говорить об оверхеде. А именно то, что он указал гораздо позже. А именно: M>
M>* a * b * c * d * e
M>
M>где, исключая пробелы, "*" — это служебные лексемы. M>А ведь действительно, с именно таким синтаксисом сложнее допустить ошибку при написании программы:
Вот теперь и умереть не страшно, хоть до одного человека что-то донес...
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Здравствуйте, Mamut, Вы писали:
СГ>>>Уверяю Вас это было видно сразу же по тексту программы. Ведь активация процедуры-функции всегда помечается скобками () даже если список параметров пуст.
M>>Это сыграло мое неполное знание синтаксиса языка. В общем, такое же, как и у вас, когда вы сетовали на оператор "-->" в C++
СГ>Я сетовал на то что легко совершить глупую ошибку благодаря побочному эффекту. Языки же я знаю.
А пример аналогичный на Обероне так и останется заигноренным?
Здравствуйте, Socrat, Вы писали:
S>Здравствуйте, Сергей Губанов, Вы писали:
СГ>>Кстати, можно усовершенствовать:
СГ>>LOOP a[i] := b[j]; СГ>> IF b[j] # 0X THEN INC(i); INC(j) ELSE EXIT END СГ>>END
СГ>>так короче.
S>А так можно?
S>LOOP a[i] := b[j]; S> IF b[j] = 0X THEN EXIT END; INC(i); INC(j) S>END
А так было в оригинале. Только условие b[j] # 0X наиболее вероятное чем b[j] = 0X, поэтому я его перенес в главную ветвь. Вообще же такой код ошибочен семантически, так как может привести к выходу за границы массива. Нужно делать проверку на это.
Здравствуйте, Socrat, Вы писали:
СГ>>LOOP a[i] := b[j]; СГ>>IF b[j] # 0X THEN INC(i); INC(j) ELSE EXIT END СГ>>END
S>Что-то не заметил разницы... Разве что в одну строчку написал.
b[j] = 0X менее вероятно чем b[j] # 0X, поэтому я поменял главную и второстепенную ветвь в IF.
Здравствуйте, qwertyuiop, Вы писали:
Q>В конце концов в Обероне ввели LOOP именно потому, что бывают случаи, когда без этого не обойтись (в отличие, например, от goto, без которого обойтись можно, но путем усложнения программы).
А Вы считайте, что наоборот. Изначально был LOOP, а потом ввели WHILE и REPEAT по просьбам трудящихся.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Здравствуйте, Mamut, Вы писали:
M>>То есть максимум, что отсюда получается, это designator := designator [([ExpList])]. В другой документации об этом ничего, вроде, не говорится.
СГ>Так ведь дело в том, что это не надо описывать с помощью EBNF. Это надо описать обычным языком. Точно также как, то что переменная перед использованием должна быть объявлена, точно также как то что имена переменных должны быть разными и т.д. и т.п. EBNF тут не силен.
В принципе, верно, но в документации на сайте я такого не нашел. Возможно, плохо искал
M>>Кстати, вопрос, как можно понять следующую фразу из Programming in Oberon: M>>
M>>Only one value, however, can be returned as the result of a function. This value, moreover, cannot be of a structured type.
СГ>Процедура-функция может возвращать переменные только базовых типов, но не может возвращать переменные сложных типов определенных пользователем (хотя указатели на них возвращать может, ведь указатель — тоже базовый тип). До Delphi 3 (или 4?) в Object Pascal было аналогичное ограничение.
А понял. Вроде как бы тоже ограничение, но в рамках языка/среды возможно оправданное.
M>>Кстати, я, по-моему, только сейчас понял ту идею, которую хотел донести Сергей, когда он начинал говорить об оверхеде. А именно то, что он указал гораздо позже. А именно: M>>
M>>* a * b * c * d * e
M>>
M>>где, исключая пробелы, "*" — это служебные лексемы. M>>А ведь действительно, с именно таким синтаксисом сложнее допустить ошибку при написании программы:
СГ>Вот теперь и умереть не страшно, хоть до одного человека что-то донес...
Просто надор было эту идею сразу нести в массы, а не подсчитывать лексемы Что-то в стиле
Как мне кажется, написание программ могло бы быть облегчено и, возможно, ускорено, если бы создатели придерживались простого правила — одно пользовательское выражение + одна лексема.
-- И дальше — звездочки, примеры программ и так далее — а то устроили этакое кровавое побоище ---
Что-то я в друг подумал. Это, наверное, единтсвенный флейм на РСДНе, в котором собеседники поняли друг друга
Просто надор было эту идею сразу нести в массы, а не подсчитывать лексемы 
Что-то в стиле
