Re: Overloading parentheses and type expectations

[Georg Bauhaus <rm.dash-bauhaus@futureapps.de>]

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".

Mathematical notation may, and does, use a circled ⊕,
not + when the writer wants to emphasize that she isn't
referring to some "known" +. Also, dot minus, ∸, is
sometimes used for subtraction never going below 0.
The use of ∫ is common for indicating an integral. TTBOMK,
the symbol isn't used to denote anything but integrals.
Unlike the way () has many uses in Ada.  And ∫ is not
used in Ada (or similar languages), but + is. Why?

Is there anything about + that makes its meaning more special
than that of ∫? More worthy of being included in the language?
Is + better adjusted to how our brain works than ∫ and that
therefore is a privileged symbol?

Or is it habit + keyboard?  I guess it is.  No need to refer
to cognitive psychology.

When computers had less characters for syntax, and programmers
typed <<< x : x in S .ST. P(x) >>> or similar instead of
{x : x in S | P(x)}, they quickly gave up overloaded < etc
when {} and | became available.
Why?  Because (a) they are easier to type, (b) they were
expected in the first place.  There is sanity in finding
a break even point between time spent deciphering
ASCII symbolism at one extreme and symbolitis at the other.

>> 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().  Cute as it may seem, common
as it may seem, conceptually sound as it may seem, expressing
differences using .all, [], or () seems to help programmers
understand programs.

And then you would have to go the other way, too, from the common
aspect and the identical syntax for different thingswhen debugging
and trying to determine what kind of () is causing trouble.

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).

>> First, infix expressions are a (dis)service offered to programmers
>> whose wish is less to program a computer,
>
> I'd like to see a hard proof that, for instance, Forth is more productive,
> safer, easier to understand, etc than Ada.

(Von Neumann called early Fortran notation a waste...)
OK, I'm assuming people insist that infix is really a must;
Although ... only with elementary math operators... Oh, and
with logical operators.

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?

Note that the parens above have only one meaning.

>  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).
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.  I'm saying this not
because Ada didn't care, it does, but because nothing of all
this is visible to the reader studying the expression, infix or not.

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.)

> Information unnecessary to understanding the program is noise. When also
> required by the compiler, it constitutes a language deficiency. (There
> could be some exceptions from this rule)

Understanding is on a scale.  This is why we say "easily understood".
This is why I say that I do not want to be forced into being an
inference machine without need. Just to understand something that is totally
obvious and consistent with some little additions I'm fine with, yes,
even redundancies.  And redundancy is subjective, of course.