Ответ на »сообщение 4488« (Ev_genus)
___________________________
Watashi wa real programer desu!
Ну это вы погорячились, коллега! Даже никто из "мэтров" так не сказал бы... Керниган и тот только на гиси себя оценивает...  :о)
Вроде вы спрашивали.
Да вроде – нет...
Не стоит так убиваться, все будет круто.
Да мне, собсна, - параллельно. Не хотелось, что бы народ лишний раз смущали скоропалительными выводами.
Ну, впрочем – успехов! Генки-о дасэ! (не люблю ромадзи-транскрибирование! тем более, что по признанию самих "носителей" киридзи более адекватна по фонетике...)

Ответ на »сообщение 4480« (captain cobalt)
___________________________

Большое всем спасибо. Вам и Губанову лично ++большое :)

Ответ на »сообщение 4483« (Владимир Лось)
___________________________

Watashi wa real programer desu!


Вы сначала объяснили, чего вы своим вопросом по Си-коду пытались тут продемонстрировать (кстати, про мой пример с printf-ами "вопрос для ясности замяли" ? :о) )

Абсолютно ничего! Разве я эту тему начал. Вроде вы спрашивали. Я написал своё мнение - не нравится, не еште.


Да! И ещё не забудьте внимательно читать и перечитывать руководства по языкам, компиляторы с которых пытаетесь "воплощать"...

Не стоит так убиваться, все будет круто.

Ответ на »сообщение 4446« (Андрей Хохлов)
___________________________

Насчет "опечатки" у Вирта. Вот точная цитата из его январской статьи этого года (с учетом тонкостей наличия/отсутствия пробелов):

It has become fashionable to regard notation as a secondary issue depending purely on personal taste. This could partly be true, yet the choice of notation should not be considered arbitrary. It has consequences and reveals the language’s character.

Choosing the equal sign to denote assignment is one notoriously bad example that goes back to Fortran in 1957 and has been copied blindly by armies of language designers since. This bad idea overthrows a century-old tradition to let = denote a comparison for equality, a predicate that is either true or false. But Fortran made this symbol mean assignment, the enforcing of equality. In this case, the operands are on unequal footing: The left operand, a variable, is to be made equal to the right operand, an expression. Thus, x=y does not mean the same thing as y=x. Algol corrected this mistake with a simple solution: Let assignment be denoted by :=.

This might appear as nitpicking to programmers accustomed to the equal sign meaning assignment. But mixing up assignment and comparison truly is a bad idea because it requires using another symbol for what the equal sign traditionally expresses. Comparison for equality became denoted by the two characters == (first in C). This is an ugly consequence that gave rise to similar bad ideas using ++, --, &&, and so on.

Some of these operators exert side effects in C, C++, Java, and C#, a notorious source of programming mistakes. It might be acceptable to, for example, let ++ denote incrementation by 1, if it would not also denote the incremented value, thereby allowing expressions with side effects. The trouble lies in the elimination of the fundamental distinction between statement and expression. The former is an instruction to be executed, the latter a value to be computed and evaluated. The ugliness of a construct usually appears in combination with other language features. In C, a programmer might write x+++++y, a riddle rather than an expression, and a challenge for even a sophisticated parser. Is its value equal to ++x+++y+1? Or is the following correct?

x+++++y+1==++x+++y
x+++y++==x+++++y+1

We might as well postulate a new algebra. I find absolutely surprising the equanimity with which the programmer community worldwide has accepted this notational monster. In 1962, the postulating of operators being right-associative in the APL language made a similar break with established convention. Now x+y+z suddenly stood for x+(y+z), and x-y-z for x-y+z.

Ответ на »сообщение 4482« (Старик Оберон)
Если компилятор допускает возможность их опускать при вызове функции, значит, он не соответствует описанию языка Виртом, т.е. некорректен.

Логично.

Возможность автоматического разыменования указателей связана с тем, что указатель не может указывать на указатель. Неоднозначности нет.

Однако, процедура может возвращать результат процедурного типа. В том числе своего собственного типа (вспомним этюд про конечный автомат). Нужное количество вызовов можно осуществить написав соответствующее количество скобок. P(); P()(); P()()(); ... Если бы P могло означать вызов, возникла бы неоднозначность.

Поэтому на вопрос

V:=P; (* 0 or Error? *)

Ответ Error.

Посыпаю голову пеплом. ;)

Ответ на »сообщение 4463« (Сергей Перовский)
___________________________
Тогда зачем новая идеология и новый инструментарий?
Ну, во-первых, а кто вам сказал, что она окончательно оформилась? Если и существуют люди, которые считают, что уже пора красные флажками понятийную и методологическую территорию метить, то это либо верхогляды и выскочки, которым неуютно, когда кто-то начинает сомневаться в стройности набора заученных ими аксиом и говорит "неудобные" для их мирка веши, либо - "формирователи школ и религий", которым особенно важно держать как можно больше народа в пределах этих "флажков"...

Идеология без методологии - еще одна песочница для развлечения веселых ребят.
Полностью с вами согласен!
Поэтому даже тот же UML еле-еле со скрипом и "треском по швам" несколько нотаций и методологий пытается объединить...

За реляционными базами данных стоит математический аппарат - реляционная алгебра. И никакие потуги разработчиков БД и даже разработчиков СУБД не могут разрушить этой основы.
Ну, допустим не одна только реляционная алгебра. Опять-таки, всё упирается в общепринятый вычислительный механизм. В смысле легкости интерпретации положений теории в конкретных строчках кода... :о)

За ООП теперь уже тоже вырос достаточно мощный математический аппарат объектного исчисления, позволяющий, по крайней мере, однозначно трактовать любые манипуляции с наследованием и полиморфизмом.
Ой-ли? Вы посмотрите на "локальность" работ на эту тему по годам и по географии... :о)
К тому же однозначность здесь только в рамках именно этого подхода. Кстати, у ребят из  МТИ, Солнца и МС-Ресёч ни слова, ни пол-слова про альтернативные реализации "перепоручения функциональности" нет, а сами реализации – существуют и успешно работают (взять тот же Self, или работы европейцев по реализации ООП на Форте – вот где мысль разгулялась (по причине абсолютной гибкости Форта в качестве средства для конструирования новых языков), - куда там Лиспу с объектными расширениями! :о) )...

На каком математическом аппарате основана идеология компонентного программирования? Или это только философская идея?
Вот вам прям так "сразу вынь – да положь"! Мы ж только в начале пути... И никто не сказал, что он в правильном направлении... Поэтому "облачков" в рисунках и философствования больше, чем "матзакорючек"...

Ответ на »сообщение 4462« (Ev_genus)
___________________________
Кстати, а вот вы, например, знаете почему в Си появились выражения, подобные приведённым: 2[p], p[2], *(p+2) ?
Или вы в полной уверенности, что это просто Керниган, Ричи и Пайк вот так вот захотели весь программисткий мир "гибкостью" языка восхитить? :о)

Ответ на »сообщение 4462« (Ev_genus)
___________________________
Предлагаю, вам, всеръёз занятся изучением Албанского языка.
Анатава Арубаниядзин дес-ка?

Начните хоть с книги Ахо, Сети, Ульман "Компиляторы: ..."
Вы сначала объяснили, чего вы своим вопросом по Си-коду пытались тут продемонстрировать (кстати, про мой пример с printf-ами "вопрос для ясности замяли" ? :о) )

Да! И ещё не забудьте внимательно читать и перечитывать руководства по языкам, компиляторы с которых пытаетесь "воплощать"...

Ответ на »сообщение 4480« (captain cobalt)
___________________________

Если мы говорим про язык Оберон, то читаем у Вирта.

* The Programming Language Oberon
8.1. Operands

If the designated object is a variable, then the designator refers to the variable's current value. If the object is a procedure, a designator without parameter list refers to that procedure. If it is followed by a (possibly empty) parameter list, the designator implies an activation of the procedure and stands for the value resulting from its execution.

(possibly empty) parameter list. (Возможно пустой) список параметров при желании можно трактовать как отсутствие списка, хотя имелось в виду вполне определенно, что в EBNF-правиле конструкция [ExpList], которая  согласно EBNF обозначает появление 0 или 1 раз, появляется 0 раз. А вот для [ActualParameters] - ровно 1 раз.

ProcedureCall = designator [ActualParameters].
ActualParameters = "("[ExpList]")".

Т.е. ProcedureCall = designator "(" ")".

Абсолютно также (слово в слово) идет и в описании The Programming Language Oberon-2.

Но раз есть сомнения, смотрим дальше, теперь в упомянутом описании Oberon-2.

В 10.1. Formal Parameters написано:
A function procedure without parameters must have an empty parameter list. It must be called by a function designator whose actual parameter
list is empty too.

Процедура-функция без параметров должна иметь пустой список параметров. Она может вызываться через обозначение функции, список фактических параметров которого также пуст.

Смотрим следующую книгу Вирта.

* Programming in Oberon.
13. Function Procedures

Calls inside an expression are called function designators. Their syntax is the same as that of procedure calls. However, a parameter list is mandatory, although it may be empty.

Тут нет двоякости толкование. Список параметров обязателен, хотя он может быть пустым. После вызова функции, у которой нет параметров, всегда должны быть скобки.

Если компилятор допускает возможность их опускать при вызове функции, значит, он не соответствует описанию языка Виртом, т.е. некорректен.