Overloading parentheses and type expectations (was: The simple Image issue)

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

On 01.09.11 09:46, Dmitry A. Kazakov wrote:
> On Wed, 31 Aug 2011 22:41:01 +0200, Georg Bauhaus wrote:
>
>> Still SPARK, and in some more cases Ada, do require that we write
>> T'() anyway: to resolve another ambiguity (of ()).
>
> Fix SPARK!

Not. At least if this makes me an inference machine for "()";
a "disambiguator"; or a de-obfuscator of clever abbreviations,
omitted names, and long lists of positional parameters.

What is the use of clever detection?  To show that in

   f(1),

given function f, the 1 can only be a an array of length 1?
This, to me, is obfuscation.

> There is no usable languages without overloading. Since you mentioned ()
> [meaning aggregates], think about them used for ordering:
>
>     (x)
>
> returns what? For each type and subtype of x there is some "()". They all
> are overloaded. Do you wish to annotate each of them?


There is evidence that overloading the meaning of () is not
working with normal people, e.g. McIver & Conway (1996). They arent't
aguing about advanced programmers, though. The Turing language has made
() a kind of universal "pick from" operator, arrays, dereferencing,
taking part-of, ..., besides the usual uses.  Readers
will need to disambiguate uses of "()" if they want to know what
some expression actually does.  Some programmers want to know
what an expression does. Other programmers must know what
an expression does.  M & C found that Turing made it difficult
to learn the differences between things all written using "()".

Why would a designer want entirely different things in a language
and then use the same notation for all of them?  Given the evidence,
I think the disadvantages outweigh the advantages.

>     I := Integer'(1 + 2) * 4 ?

Qualification, association, and infix operators.

First, infix expressions are a (dis)service offered to programmers
whose wish is less to program a computer, but rather to write
executable formal expressions (such as non-CS formulas)
in blissful ignorance of the computer. (Even when they like
HP calculators...)  Infix doesn't work well unless
the subject is more or less mathematical and when work can ignore
TIME and SPACE.

I cannot say it better than,
http://c2.com/cgi/wiki?OperatorPrecedenceConsideredHarmful

Then, infix is complex to understand when the model is otherwise that
of simple object oriented programming (ignoring inheritance).
In 3 + 5 (or x + y), which object does "+" manipulate?
Or will the execution update the "+" object?  Consider

   a := 1;
   a.add(2);
   if a /= 3 then
      raise Program_Error;
   end if;

This would put me in a different mode of thinking, and of understanding.
There are no operational effects (or surprises!) of association and
precedence.


Third, an occurrence of qualifying T'(...) frequently creates an object.
When the object appears alone, as in a typical initialization expression,
repeating the type's name may seem silly and redundant.  Just for context,
some less specific circumstances.

   declare
      X : T0'class := T3'( ... );
   begin

is different from

   declare
      X : T3 := ( ... );
   begin

and different from

    Integer'(1 + 2) * 4


"Qualifying" in a different way, though much like Integer'(1 + 2) is not
without uses:

    for P in Pins range 1 .. 3 loop

rather than

    for P in 1 .. 3 loop

carries more information, and will add information that is sometimes
necessary for the Ada compiler to know the literals and their types.
I don't find them necessarily silly and redundant.  Strict, yes.


> Since the dictionary of any language is far less than the number of
> entities an average program in that language describes, you simply cannot
> avoid some kinds overloading.

Sometimes overriding works better than overloading.

At the level of overloading ASCII punctuation, I think the less,
the better.  Use symbols only for things heavily loaded with
meaning. The art is in finding the right weight.