Re: What would you like in Ada202X?

[Brian Drummond <brian@shapes.demon.co.uk>]

On Sat, 30 Jun 2012 11:51:51 -0400, Robert A Duff wrote:

> Brian Drummond <brian@shapes.demon.co.uk> writes:
> 
>> We can overload existing operators (+,-,etc)
...
>> But we can't define new ones, e.g. // to denote the value of electronic
>> components connected in a parallel circuit)
>> One obvious problem with an extensible set of operators, in an operator
>> precedence grammar, is assigning the precedence level of new operators.

> ... But
> "and" and "or" have neither higher, lower, nor equal precedence.  That
> last possibility is important to allow, and in fact should be the
> default -- perhaps call it "unrelated precedence".

... and that may help here.

>> Lingo resolved that dilemma by assigning the same precedence to all
>> operators! 
> And some other languages, such as Smalltalk.  Yes, it's simple.
> But it's a bad idea, because it violates maths conventions.
> I could tolerate a+b*c being illegal, but I can't tolerate it being
> legal and meaning (a+b)*c.

While agreeing it's a bad idea, I think it's a fair compromise IF it's 
clearly understood from the beginning, that that is what the language 
does, in order to allow major simplification in other aspects; in Lingo's 
case (and I believe Smalltalk's), sidestepping the precedence problem. 

Other bad ideas abound in computing; some languages violate the 
conventions by making assignment an operator...

I am happy to see neither of these ideas in Ada!

>> Given that ways can be found to assign precedence to new operators, why
>> are extensible operators not found in more languages that allow
>> overloading?
> 
> Perhaps because dealing with precedence adds complexity.
> What happens if package P1 declares that "//" has higher precedence than
> "\\\", and P2 declares the opposite,
> and you say "with P1, P2;"?  The obvious answer is that they then have
> unrelated precedence within the scope of that "with".  But it definitely
> adds complexity.

Conflicting precedences are a problem I hadn't considered. There seems to 
be some parallel with the diamond problem in multiple inheritance. 
If P1."//" and P2."//" apply to different types, does it really matter 
that they have different precedences, unless the base type is the same?
Possibly yes, from the perspective that the expression parser now has to 
take the operand types as well as the operator symbol into consideration. 

"+" by contrast, has the same precedence for integer, real, string, and 
foobar types (whether or not that precedence is appropriate for the 
semantics of e.g. string processing, it's what you get).

Perhaps a simple rule - e.g. all user-defined operators have unrelated 
precedence to ALL other operators - could cut through the complexity. 
But, like the simple rules in Modula-2, that may prove inconveniently 
restrictive.

> Anyway, I don't think I want programs to look like maths textbooks.
> Programming isn't the same as maths.  I kind of like reading words, as
> in "Union(Intersection(This_Set, That_Set), The_Other);" rather than the
> usual maths symbols.  On the other hand, I wish ASCII had proper symbols
> for <= and >=.

Agree that it could be over-used. But in some domains it would be useful. 
After all, I doubt you would want to see too much 
"Add(A,Multiply(B,C))"...

- Brian.