Re: Overloading parentheses and type expectations

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

On 02.09.11 14:40, Dmitry A. Kazakov wrote:

> 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

The non-scientific meanings are not applicable to how this study
of understanding programming languages was conducted.



> Integral is not an addition.

Other operations aren't addition either, yet some are considered
more worthy of inclusion as infix symbols than others. I just think
that language design should reflect computers' + more than + from
school. How?

Specialists in using + let us know that most programmers have no idea
of what they are doing, for example, when adding floats. (I don't
say I have.  Dewar, author of a number of chapters on FPT units
in microprocessors, has hinted that he will consult specialists,
so I don't feed all too bad.)  Still we all write x + y, and many
don't care what this actually means.

The point is: the language does not draw attention to +
as a source of errors induced by school think.  It does
not encourage learning about computer addition by making
the default syntax for + so conventional.


> 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 equally abhorred, as is ∪.  Maybe ∪ should not be used
in languages other than SETL because ∪ implies properties
of data structures that typical implementations of a Set will
not have?

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

This is a mathematical perspective on mathematical properties only,
not simply on program text.  In a computer program, you write

  + (1, 2)
  ∫ (f'access, a, b)

How is ∫ special?  I'm *not* suggesting ∫ should be specially present in a
general purpose programming language. But, by the same token, I think
that + should trigger the same restraint as do ∫ or ∪.

At the very least, an operator such as + should not be predefined to
the maximum extent possible. The operator should convey that it
will not perform high school addition but computer addition. We
would be getting better programs, because programmers are better
informed.


> Sorry, people can be unaware of anything.

We typically assume that we are aware of the meaning of expressions.
But we frequently aren't, and more so when the language obfuscates actual
differences by painting them all in the same mathematical color (syntax),
such as in the pointer(), array(), and function() examples.
Makes them all look the same, even though they behave differently.
There wouldn't be different mechanism in a language otherwise,
would there?

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

The study by McIver & Conway explains a number of reasons,
all having to do with programmers.

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

I still don't want most programs to overflow. Mistakes are
not mandated behavior, unless you share Microsoft's office
sales strategy.


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

Which, I guess, can be reduced to

"()" : N_|_ -> N_|_

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

To me, it matters what programmers think about +, and about
how + works, and about what happens to the operands. Thus,
what they think about what happens in x + y - z, and how
a language's syntax helps with understanding what actually
happens.


> That does not change the semantics of +.

The symbol + has no semantics of its own, like you explain later.


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

Not + alone, but a suitably defined language allowing programmers
to express their expectations, and be given clear and simple indications
of its effects.  If a language mandates the use of grouping, (x + y)
not x + y, then this rule draws attention to the effects of association
in a computer.

A simple example, also related to "the semantics of symbols":

  a = a + 1

The hypothetical student sees this statement when she is
first exposed to programming in her life (BASIC).  She then reads
all the gibberish about storage locations, accumulators
and whatnots, but stills has no idea just how a number can be equal
to its successor!  `=' is very unmathematical in most programming
languages, yet programmers fervently defend its choice.  The + case
is lighter I think, but otherwise not much different.

What can aid understanding?

The Semitic languages, when written and read by specialists,
leave out the vowels.  Similarly, trained readers can understand
a text written in shorthand. Likewise, cryptographers will have
little difficulty assigning meaning to hexadecimal gobbledegook.

If the three groups of specialists write diacritics for vowels,
write in "normal hand", or don't encrypt their messages,
respectively, then this is a first step towards understanding.

Revert the removal of subjectively felt redundancy.