Re: Problems with 'class, help anyone?

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

Robert A Duff wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> Well, strictly speaking "+" is also not the mathematical +. Who cares.
> 
> You mean because it can overflow?  And because (for floats), it can give
> a "close-but-wrong" answer?
> 
> Or do you mean, because the user can redefine it to do something else,
> including having side effects?

Both and more. Any computer objects at best only simulate mathematical ones. 
They never *are* mathematical objects.

> I can assure you that if the ARG changed the syntax in this way,
> they would be tarred and feathered (or at least ignored)!  ;-)

Alas

>> But we still need some keywords for:
>> 
>> 1. Subroutine (=procedure)
>> 2. Subroutine with no side-effects other than on the arguments (=?)
>> 3. Subroutine with only one side-effect on the result (=?)
> 
> I think 2 and 3 should use the same syntax on the declaration.
> To me, it's a minor point whether a subroutine returns results
> via a "function result" vs out parameter(s).

OK

> I would advocate a notation at the call site that indicates
> out-parameterness.
> 
>> "function" in Ada is sort of 1. dressed as 3. (:-()
>> 
>> {1,2,3} is multiplied to:
>> 
>> A. Subroutine with no queue
>> B. Subroutine with a queue (entry)
> 
> I am not convinced that these need a syntactic distinction.

So let's allow timed and conditional entry calls for all kinds of 
subroutines! Let's allow results for entries.

>> Well together it makes 3x2=6 different variants!
>> 
>> And not to forget the "notation" axis:
>> 
>> i.   operational x+y
>> ii.  prefix (subroutines of protected objects, tasks, attributes)
> 
> I don't much like the prefix notation.

OO-people would not give it away. They like to write comical things like 
"x.sin". It is almost as sacral as only-in-parameters-for-functions (:-))

If we want to abolish postfix notation, then we should consequently allow 
protected operations on multiple objects and entries of multiple tasks. 
[and multiple dispatch, of course]

>> iii. functional A(x,y)
>> iv.  aggregated (x,y,z) (should Ada have user-defined ones?)
> 
> I don't know about Ada,

Surely it is not about C++#* (:-))

> but if I were designing a language from scratch,
> I think I would include user-defined aggregates.  Also, user-defined
> semantics for various other notations, like literals, "in", indexing,
> and maybe a few others.

Yes

> I would not go so far as Lisp, where you can redefine the meaning of
> 'if' statements, and you can even redefine the lexical rules of the
> language.

Agreed. The problem of Ada is not in lexical rules, they are almost perfect 
in my view. The problem is that ADT implementation is far incomplete in 
Ada. One cannot create a record and expose it as an array. One cannot 
define a constructor for every new type. One cannot have discriminants for 
every type. One cannot override implementation of a type while deriving 
from it, etc.

-- 
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de