From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,3bf50ede73cff892
X-Google-Attributes: gid103376,public
From: "Norman H. Cohen" <ncohen@watson.ibm.com>
Subject: Re: Operators Questions
Date: 1996/10/29
Message-ID: <32766B6F.3C37@watson.ibm.com>#1/1
X-Deja-AN: 192992954
references: <3275D478.5952@eurocontrol.fr>
content-type: text/plain; charset=us-ascii
organization: IBM Thomas J. Watson Research Center
mime-version: 1.0
reply-to: ncohen@watson.ibm.com
newsgroups: comp.lang.ada
x-mailer: Mozilla 3.0 (Win95; I)
Date: 1996-10-29T00:00:00+00:00
List-Id: <comp.lang.ada>


Richard Irvine wrote:
> 
> Ada allows overloading of the predefined operators
> but not definition of new operators.
> Sometimes code could be made more readable if it
> were possible to define new operators, e.g.
> 
> if   aTimeInterval encloses anotherTimeInterval
> then -- It is clear which interval encloses which.
>      ...
> 
> instead of
> 
> if   encloses(aTimeInterval, anotherTimeInterval)
> then -- Which interval enclosed which?
>      -- One has to look at the declaration of
>      -- the function.
>      -- One could use formal parameters, but
>      -- then things start to get long-winded.
>      ...

Named notation helps:

   if Encloses (Outer => A_Time_Interval, Inner =>
Another_Time_Interval) then

The names before the arrows are the formal parameter names declared in
the function declaration.  The compiler checks them.  The programmer
does not have to remember the order in which the formal parameters are
declared, since actual parameters are associated with formal parameters
based on names rather than positions when this notation is used.

> I guess that allowing the programmer to define his
> own operators creates difficulties for the compiler
> writer, or is there some other reason why definition
> of new operators is not allowed in Ada?

It complicates the language definition, both for the compiler writer and
the programmer.  You need rules to specify the role of each operator in
the expression grammar.  In some languages this is expressed in terms of
precedence level and left or right associativity.  Ada has no
right-associative operators, so that issue can be ignored, but Ada has
syntax rules requiring parentheses when combining certain operators of
the same precedence level, e.g.

   (A and B) or C

   (abs X) ** 3

I suppose a simple rule would be to allow a special form of expression
consisting of two primaries separated by a user-defined operator.  This
would mean that parentheses would be required to combine a user-defined
operator with any other operator:

   W := X myop Y;  -- okay
   W := X myop Y myop Z;  -- illegal
   W := (X myop Y) myop Z; -- okay
   W := X myop (Y myop Z); -- okay
   W := X * Y myop Z; -- illegal
   W := (X * Y) myop Z; -- okay
   W := X * (Y myop Z); -- okay
   if X < Y myop Z then ... -- illegal
   if X < (Y myop Z) then ... -- okay
   if (X < Y) myop Z then ... -- okay
 
> Are there languages which do allow defintion of
> new operators?

EL1, a language developed at Harvard (thats the digit one, not the
letter 'I' as the Yalies would have you believe!) in the 1970s had such
a feature.  You could define not only infix (binary) and prefix (unary)
operators, but also pairs of "matchfix" operators such as "<[" and "]>"
or "[)" and "(]".  Any number of arguments separated by commas could be
listed between these brackets, resulting in a list being passed to the
called subprogram.

I vaguely recall a SIGPLAN Notices article long ago about a language
named ABC that allowed a call to consist of arbitrary sequences of
tokens with arguments interspersed, e.g.

   Insert Item (X) in Hash Table (T) Using Key (K);

-- 
Norman H. Cohen
mailto:ncohen@watson.ibm.com
http://www.research.ibm.com/people/n/ncohen