Re: Overloading parentheses and type expectations

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

On Thu, 01 Sep 2011 11:50:59 +0200, Georg Bauhaus wrote:

> 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?

1. Common sense.

2. Limitations put on human brain. We can memorize only a few concepts and
whatever we see or do has to be broken into these basic concepts, e.g.
"additive".

> To show that in
> 
>    f(1),
> 
> given function f, the 1 can only be a an array of length 1?

It cannot, because f is not a prefix operation.

Anyway, ANY written language needs understanding (translation into the
domain). Are you arguing for a hieroglyphic language where each possible
program has a corresponding alphabet symbol?

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

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.

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

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

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

The text is about levels of precedence. They were probably unaware of the
simple fact, that ambiguity should not be resolved using precedence as in
C. For proper language design see Ada, where ambiguity stay unresolved:

   X and Y or Z   -- Ambiguous => erroneous 

> In 3 + 5 (or x + y), which object does "+" manipulate?

Three objects:

1. The left argument
2. The right argument
3. The result

All this has nothing to do with the notation. Whether "+" is used as an
infix operation or as a function call, its semantics remains exactly the
same.

> Third, an occurrence of qualifying T'(...) frequently creates an object.

I doubt it. Anyway, semantically there should be no difference.

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

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)

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

Both are cases of polymorphism. It is OK to inherit "+" from some common
base. Unfortunately Ada cannot this due to lack of MD, MI and interface
inheritance. But that would change nothing at the syntax level: 1+2 would
remain 1+2 (as it should be).

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