Re: Operators Questions

Re: Operators Questions

[Robert Dewar]

"if   aTimeInterval encloses anotherTimeInterval
then -- It is clear which interval encloses which."

Are there reasons to forbid this sort of thing? Yes indeed, it is a common
idea, there are some languages  that follow this idea (e.g. ABC), but it
is a bad idea for a language like Ada, for all sorts of reasons, and it is
not something that I have ever heard anyone seriously consider.

Operators Questions

[Richard Irvine]

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

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? 

Are there languages which do allow defintion of 
new operators?

Re: Operators Questions

[Norman H. Cohen]

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

Re: Operators Questions

[Fergus Henderson]

Richard Irvine <Richard.Irvine@eurocontrol.fr> writes:

>Are there languages which do allow defintion of 
>new operators?

Yes.  For example, Prolog and Haskell both allow this.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: Operators Questions

[Matthew Heaney]

In article <3275D478.5952@eurocontrol.fr>, Richard Irvine
<Richard.Irvine@eurocontrol.fr> wrote:

Put this on my wish list for the next revision of the language: the ability
to overload the membership operator "in".  That way I can say

generic
   type T is private;
package Sets is

   type Set is private;

   function "in" (Left : T, Right : Set) return Boolean;
...
end;

package Integer_Sets is new Sets (Integer);
subtype Integer_Set is Integer_Sets.Set;
use Integer_Sets;

   The_Set : Integer_Set;
begin
   ...
   if 4 in The_Set then
      ...


I think that that's much hipper than

   if Is_Member_Of (The_Set, Item => 4) then
      ...

But of course your mileage may vary.  

Language designers: any reason overloading of "in" is too difficult for
inclusion in the language?  Why can't you do this already?  This exclusion
of the ability to overload "in" seems rather odd and unexpected.

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
mheaney@ni.net
(818) 985-1271

Re: Operators Questions

[Jon S Anthony]

In article <mheaney-ya023180003010961903550001@news.ni.net> mheaney@ni.net (Matthew Heaney) writes:

> Language designers: any reason overloading of "in" is too difficult for
> inclusion in the language?  Why can't you do this already?  This exclusion
> of the ability to overload "in" seems rather odd and unexpected.

It's a reserved word...

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: Operators Questions

[Michael F Brenner]

M. Heaney said:
    > Put this on my wish list for the next revision of the language: the 
    > ability to overload the membership operator "in".  
     
This would be a very good syntactic idea, because it not only opens up 
the example Matt gave (if member in Set), but also an obvious loop iterator
(for member in Set). The first language to do this was Jack Schwartz's
SETL language, which is still one of the fastest ways to prototype 
complex data structures. The most notable difference between the current
version of SETL and Ada-95 is that, because of the extremely high
generality of IN and FORALL, a typical SETL algorithm runs two orders
of magnitude slower than an Ada-95 program. Typically, there are two
levels of interpretation, an algorithmic interpretor and a data
structure interpretor, each of which add up an order of magnitude of 
execution time to a program. SETL does not declare the type of its objects,
so an object could be an integer or a recursive structure of sets within
sets within sets. 

The ideal would be to have both a typeless prototype language and a 
strongly typed implementation language. Because the typeless language
would definitely use the more mathematical notation of IN and FOR, it
would be a very positive step for Ada-000X to permit strongly typed
overloading of IN and FOR, so that both languages could use the 
identical algorithmic form.  

Re: Operators Questions

[Adam Beneschan]

jsa@alexandria (Jon S Anthony) writes:
 >In article <mheaney-ya023180003010961903550001@news.ni.net> mheaney@ni.net (Matthew Heaney) writes:
 >
 >> Language designers: any reason overloading of "in" is too difficult for
 >> inclusion in the language?  Why can't you do this already?  This exclusion
 >> of the ability to overload "in" seems rather odd and unexpected.
 >
 >It's a reserved word...

So are "and" and "or" . . .

                                -- Adam

Re: Operators Questions

[Adam Beneschan]

mheaney@ni.net (Matthew Heaney) writes:
 
 >Language designers: any reason overloading of "in" is too difficult for
 >inclusion in the language?  Why can't you do this already?  This exclusion
 >of the ability to overload "in" seems rather odd and unexpected.

It's not really odd, since overloading pertains to operators, and "in"
isn't an operator.  The overloadable operators all take one or two
expressions as arguments (loosely speaking); "in" takes an expression
on the left and a range or type mark on the right.

This doesn't mean "in" couldn't be overloaded, if this feature were
really desired in the language; but making the compiler handle this
wouldn't be as simple as adding "in" to its list of overloadable
operators.  Suppose the compiler sees

    A in B

where A and B are variables; it would have to look ahead and see if
the next lexeme is ".." to determine whether "in" is being used as a
membership test or as an overloadable operator with A and B as
arguments.  I'd bet that most compilers would need extra code to
handle this case, unless perhaps they're already treating ".." like an
operator internally.  Even worse: Would "in" have a higher or lower
precedence than, say, "+"?  If higher, the compiler would have a nasty
time dealing with both

    A in B + C                which means (A in B) + C

and 

    A in B + C .. D + E       which means A in (B+C)..(D+E)

How far ahead does the compiler have to look to determine what
operator applies to what arguments? 

In any case, it appears that the benefit would not be worth the cost.

                                -- Adam

Re: Operators Questions

[Robert Dewar]

Jon Anthony gives as a reason for not overloading IN

"It's a reserved word..."

this is a bogus reason, MOD can be overloaded

The real issue is that it has very special semantics, involving ranges,
which cannot be passed as parameters, to make extensions that allow
ranges to be passed as parameters is a big mess for little gain.

Re: Operators Questions

[Jon S Anthony]

In article <55b9mb$kk6@krusty.irvine.com> adam@irvine.com (Adam Beneschan) writes:

> jsa@alexandria (Jon S Anthony) writes:
>  >In article <mheaney-ya023180003010961903550001@news.ni.net> mheaney@ni.net (Matthew Heaney) writes:
>  >
>  >> Language designers: any reason overloading of "in" is too difficult for
>  >> inclusion in the language?  Why can't you do this already?  This exclusion
>  >> of the ability to overload "in" seems rather odd and unexpected.
>  >
>  >It's a reserved word...
> 
> So are "and" and "or" . . .

Wow.  You really have to be pretty darn stupid to check that "in" is a
reserved word and then not bother to see (on the very same page) that
"and", "or", "xor" are too...  I mean, really.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: Operators Questions

[Jon S Anthony]

In article <dewar.846951467@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:

> Jon Anthony gives as a reason for not overloading IN
> 
> "It's a reserved word..."
> 
> this is a bogus reason, MOD can be overloaded

That's being generous.  It is one of the stupidist things I have said here...


> The real issue is that it has very special semantics, involving ranges,
> which cannot be passed as parameters, to make extensions that allow
> ranges to be passed as parameters is a big mess for little gain.

Aha....

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: Operators Questions

[William Frye]

Norman H. Cohen (ncohen@watson.ibm.com) wrote:
: 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
 I disagree totally here.  IMNSHO named notation here only serves to make
a strained, unnatural construction enven more strained and more ridiculously
long winded.  With code and comments for any usable size module already pushing reasonable limits in size we need extra characters in our code like we need a
"new edition of the Wpanish Inquisition."  (Incidentally, from my background
in maintainence programming I have developed a rule of thumb,  If a module
doesn't fit on two pages(which is the limit I can get to spreading a listing
on a table) then the developer had better give GOOD reasons for the length.)
: -- 
: Norman H. Cohen
: mailto:ncohen@watson.ibm.com
: http://www.research.ibm.com/people/n/ncohen