Re: Overloading parentheses and type expectations

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Fri, 02 Sep 2011 12:37:17 +0200, Georg Bauhaus wrote:

> On 02.09.11 09:54, Dmitry A. Kazakov wrote:
> 
>> Rubbish, mathematical notation is taught in school. It is easy to show that
>> all known alternatives (e.g. Polish expressions) are incomprehensive for
>> normal people.
> 
> Still, I hesitate to call empirical findings "rubbish".

empirical, adj
...
2. based on practical experience rather than scientific proof
3. (of a proposition) subject, at least theoretically, to verification 
4. (Medicine) of or relating to medical quackery

Would "quackery" be OK? (:-))

> Mathematical notation may, and does, use a circled ⊕,
> not + when the writer wants to emphasize that she isn't
> referring to some "known" +.

+ is used for all kinds of additive elements, numbers, vectors, matrices
etc.

> The use of ∫ is common for indicating an integral.

Integral is not an addition. Addition is used by (Lebesque) integration,
but defined on a set measure. It has the standard notation +, e.g.

   µ(A U B) = µ(A) + µ(B)   if A and B are disjoint, etc

> Is there anything about + that makes its meaning more special
> than that of ∫?

Yes. Integral is a value according to some measure. + is an operation of a
group. (I hope you won't argue that * is addition because it could be
defined in terms of +)

>>> Why would a designer want entirely different things in a language
>>> and then use the same notation for all of them?
>>
>> See above. This is the way human brain works. And the things are not
>> entirely different, they are instances of some class. The language captures
>> this by using "+" everywhere "addition" is meant.
> 
> In order to capture meaning of classes, one first has to learn and
> become aware and become familiar with what a class is before even
> touching and understanding of class. Those not familiar with CS
> abstractions, maybe even those who are familiar with CS abstractions,
> have not found it obvious that a pointer dereference written p()
> is the same thing as an array indexing operation written a(),
> or as a function call written f().

Sorry, people can be unaware of anything. Why, for somebody unaware of +, 

   Integer'(Add (Integer'(1), Integer'(2)) 

would become more understandable? Is he aware of Integer? Of 1, 2. What
does the apostrophe mean? Does it stand for gender? Is '(Add (Integer' a
string. What is string?

> Proof:  The lengthy and recurring discussion of a[i] being
> the same as *(a + i) in C does not take place when explaining
> Ada arrays; but Ada programmers will need to do some
> overload resolution work when seeing x(y).

Nope. Mathematically there is no difference between an array and a valued
pure subprogram. Both are run-time implementations of a mapping. Why there
should be different notation for them?

> One ingredient of productive programming is the principle
> of least surprise.  Overflow is one of the surprises.
> 
>: 1 Max_Int + N - ;
> 
> (- (+ 1 Max_Int) N)
> 
> 1 + Max_Int - N;
> 
> (1 + Max_Int) - N;
> 
> Presuming familiarity with either language, why would the human
> brain be better at detecting the error on line 3 and not on
> lines 1,2,4? Even though, if I understand correctly, the brain
> isn't aided by distinct syntax when breaking things down?

1. Overflow is not an error it is a valid, mandated behavior.

2. If the contract excludes overflow then, the only correct line is #3,
since the compiler is allowed to reorder the expression to produce the
mathematically correct result.

> Note that the parens above have only one meaning.

Wrong. There are two meanings of brackets above:

1. "()" : N -> N   , e.g. (1)=1

2. "()" : <exceptional-state> -> <exceptional-state> , e.g.
Constraint_Error is propagated out of brackets.

>>  Whether "+" is used as an
>> infix operation or as a function call, its semantics remains exactly the
>> same.
> 
> The phrase "its semantics" is stipulating a specific interpretation
> of binary "+"; Smalltalk is assigning different meaning to "+",
> at least using very different reasoning (to the untrained).

I care little of Smalltalk (sorry, for unintended pun).

> But you do write x + y ...
> Meaning is also unclear when languages have rules (or not)
> explaining the order of evaluation of arguments; or the effects
> of aliasing in the presence of optimization.

That does not change the semantics of +. The semantics of an expression (or
a program) depends on the semantics of its parts, but is not equivalent to
them. The composition rules of the language tell you how these parts are
supposed to interplay.

> The human brain needs to learn, and then to rummage through a mountain
> of, information about the expression and its meaning in order to see,
> for example, from where this strange and irregularly occurring difference
> in executing x + y should stem, for seemingly the same x and y, by the
> looks of it.  (Timing dependent shared variable update through y, say.)

And a consistent use of Whatever.Package.Name.Add instead of + is supposed
to ease the process of learning?

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de