Overloading "and"

Overloading "and"

[Mike Linnig]

Here's something that I thought was illegal.  

We've all seen Ada programs that overloaded the standard operators
("+","-","*","/"). We've also seen people overload the concatination
operator "&".  But I didn't think it was possible to overload the
"AND" and "OR" operators.  

The following compiles without error on DEC Ada:

     PACKAGE test is

       function "and"(l,r: integer) return integer;

     END test;
     ----------------------------------------------------------------------
     WITH test; USE test;

     PROCEDURE mytest IS

     a, b,c : integer;

     BEGIN
       a := b AND c;		-- a call to the function TEST."AND" 
     END mytest;
     ----------------------------------------------------------------------

Many thanks to Renzo Bianchi and Gary Smith of TI, Colorado Springs for
bringing this to my attention.

Live and learn.

	-- Mike Linnig, 
	   Texas Instruments

Re: Overloading "and"

[stt]

It is illegal to overload "and then" and "or else" (as these
are "operations" but not "operators"), but it is
perfectly legal to overload the logical operators "and,"
"or," and "xor."

The only restriction about overloading operators has to
do with "=" and "/=."  You may not separately overload "/=,"
and you may only define "=" for limited types, or by renaming
another "=."   Thanks to generics, you can in fact
define "=" for any type by doing so in an instantiation
of a generic passing the type as the actual matching a formal
limited private type.

Re: Re: Overloading "and"

[jeff]

> Nf-ID: #R:ucbvax.berkeley.edu:-114600:ada-uts:4700083:000:555
> Nf-From: ada-uts!stt    Nov  6 10:47:00 1986
> 
> 
> It is illegal to overload "and then" and "or else" (as these
> are "operations" but not "operators"), but it is
> perfectly legal to overload the logical operators "and,"
> "or," and "xor."
> 
> The only restriction about overloading operators has to
> do with "=" and "/=."  You may not separately overload "/=,"
> and you may only define "=" for limited types, or by renaming
> another "=."   Thanks to generics, you can in fact
> define "=" for any type by doing so in an instantiation
> of a generic passing the type as the actual matching a formal
> limited private type.

Pardon me, no flames intended to the poster, but I just HAD to bring up
a point with such a good example available. I know that somebody somewhere,
with nothing better to do, decided what the "correct" method of punctuating
near (") quotation marks would be. The poster has "correctly" followed the
"rules", and I am not finding any fault with the poster.

My point is this: why put (,) commas and (.) periods, or any other 
punctuation for that matter, within a technical quotation?

       for example:

> perfectly legal to overload the logical operators "and,"
> "or," and "xor."

Am I to assume that the poster is referring to (and,), (or,) and (xor.) ?

> do with "=" and "/=."  You may not separately overload "/=,"
>  ...
> another "=."   Thanks to generics, you can in fact

Likewise, are we looking at (/=.) and (/=,) ?

Context and careful re-reading help the reader to understand what is really
being communicated, but is it REALLY necessary?

I admit, in this particular case, the above assumptions are rediculous.
There are, however, many topics that could be discussed, including a few
languages, where these assumptions would be quite reasonable.

Again, there are absolutely NO FLAMES INTENDED toward the poster, just
FLAMES for the rules.


Thanks for listening.
I feel better now.