Re: Overloading parentheses and type expectations

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

On Fri, 02 Sep 2011 18:08:49 +0200, Georg Bauhaus wrote:

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

Obviously this study has little to do with science. I have no idea how such
stuff passes peer reviews...

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

No, it should not.

> The point is: the language does not draw attention to +
> as a source of errors induced by school think.

No, the semantics of + is defined pretty clear and it is consistent with
the school mathematics. + does not mean the group operation of Z. Computers
do not handle Z. + means "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 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?

How so? Bot µ and U represent absolutely no problem, so long sets are
finite, which is 99.9% of all cases modeled using computer programs.

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

Integration is special, because incomputable. The approximations of, done
by computers, are too implementation-dependent to be abstracted in the way
used in mathematics. On the contrary, the implementations of model numbers
are much more simpler and closer to their mathematical counterparts. No
less important is that model numbers indeed form the structures (rings etc)
of same nature (properties) as the corresponding mathematical structures.

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

No. E.g. + of mod 2**16 means exactly same, the mathematical + does.

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

I don't buy such "studies" on methodological grounds. Whatever explanations
they give, that is an urban myth. You, me and anybody else here is capable
to produce tons of such stuff. Meanwhile the hard facts are impossible to
gather in any statistically relevant form, because such experiments would
cost billions of bucks and require very sophisticated methods to develop.
For the rest see Ernest Rutherford about science and stamp collecting.

We could only be happy that guys "studying" programming languages have not
a ounce of influence on the governments, the "climatologists" have. Lysenko
is dead, but his cause lives.

>> 1. Overflow is not an error it is a valid, mandated behavior.
> 
> I still don't want most programs to overflow.

Then they should not let overflow happen.

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

I am not against manifested contracts, as you probably know. But the idea
that syntax should convey contract is all wrong. It won't work, it never
worked. The contracts belong to the types.

> What can aid understanding?

The language should convey the idea at different levels of abstraction. It
is like a good movie or a good book. Anybody can find there something at
his level of depth or shallowness. Understanding works by recognition of
common concepts and patterns with an ability to go deeper, gradually down
to the bottom, but only when felt needed. This makes a good language. C is
bad because it does what you wanted, it requires full, persistent,
concentrated attention to each tinny piece of the code written or read.

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