Re: Ada self-referential operators

Re: Ada self-referential operators

[Brian Hanson]

In article e64@gnat.cs.nyu.edu, dewar@cs.nyu.edu (Robert Dewar) writes:
>but this needs to be balanced by a concern for keeping the language simple.
                                                                     ^^^^^^^
Not quite the word I would use to describe Ada.  Uniform, Consistant may be
better but NOT simple.

-- Brian Hanson
-- brh@cray.com

-- 
----
-- Brian Hanson
-- brh@cray.com

Re: Ada self-referential operators

[Thomas G. Coles (1W0)]

On 23 Feb 95 11:45:33 CST, Brian Hanson (brh@cray.com) wrote:
: In article e64@gnat.cs.nyu.edu, dewar@cs.nyu.edu (Robert Dewar) writes:
: >but this needs to be balanced by a concern for keeping the language simple.
:                                                                      ^^^^^^^
: Not quite the word I would use to describe Ada.  Uniform, Consistant may be
: better but NOT simple.

I may not be the best judge, but I wouldn't dispute the use of `simple' to
describe Ada.  Perhaps I'm not tackling quite such difficult problems, but it
seems pretty reasonable to me.

What WOULD you consider a simple language, Brian? (Chap sitting next to me
says `English' !)

Thomas

-  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -
Thomas Coles                    tgc102@ugrad.cs.york.ac.uk
Goodricke College             or tgc102@minster.york.ac.uk
University of York                   "God preserve us from 
York, YO1 5DD, UK                       religious nutters"

Ada self-referential operators

[R.A.L Williams]

In article <3grqrf$jkd@gnat.cs.nyu.edu> Robert Dewar wrote:
: A couple of things Bill, first you would like to see := be overloaded, but
: this is notoriously difficult to define cleanly, and people's first naive
: thoughts quickly founder on very tricky semantic rocks.

C++ seems to manage. Does Eiffel? I can't offhand remember.

OK, in Ada I can see that ":=" may have some implicit semantics not
present with other operators. For example, I believe constraint checking
is expected at this stage of the execution of a statement and not
before. In C++ this would be approached by inheriting from some base
operator.

Optimisation is obviously another problem. Optimisation is just not 
possible if the compiler doesn't understand the semantics of the
operators. After all, I could define something wierd like

procedure ":="(lhs : out Integer; rhs : in Integer) is
begin
  if rhs = 2 then
    lhs := 5;
  else
    lhs := 6;
  end if;
end;

Obviously, any compiler which tried to optimise a basic block containing
that would be in for a nasty surprise! So, OK, we disable statement level
optimisation where overloaded assignment is used. Caveat emptor (I don't
know the latin for programmer) -- if you use this construct, don't expect
optimisation.

: As I assume you know, Ada 95 does allow for the effect of user defined
: assignment, but not via providing a definition for the := "operator",
: which of course is not an operator at all.

My knowledge of Ada 95 is currently rudimentary, but improving. I did
a lot of Ada 83 code some years ago. I wasn't aware of 'User Defined
Assignment and Finalisation' (RM 7.6) until you pointed it out. I assume
from the LRM that to make use of this facility I need to derive the
types I want to perform 'adjustment' etc. on from 'Controlled'. 

Well, OK, with this model for assignment I can see that overlaoding ":="
is going to be inelegant. In fact, the equivalent that Ada 95 provides
*is* inelegant (IMO :-) Effectively, Ada 95 imposes a 'tree' view of
inheritance, and rules out the possibilty of a 'forest' if user defined
init/final/adj is needed. This is because, as I understand it, all classes
(sorry, object speak) must be inherited from Controlled or, presumably,
Limited_Controlled. Probably not a problem, but the sort of minor
irritation that we could do without.

BTW, I don't understand your assertion that ':= [...] of course not an
operator'. Perhaps not in Ada 95, with the semantics of package 
Ada.Finalization behind it, but the assignment operator is as good an 
operator as any other to my way of thinking. Can you explain your
reasoning here?

: Labor saving devices are indeed a good idea, PROVIDING that they save
: labour in the right places. In particular, I regard labor saving devices
: for code writers to be pretty unimportant. The only thing that is important
: is the ease of code reading, and it is CERTAINLY not the case that anything
: that makes code more compact makes it easier to read (if that were true,
: then as Bob Eachus points out, everyone would program everything in APL!)

Yes, but... (moderation in all things! Ada, sometimes makes us go to 
unnecessary lengths to do trivial operations; eg. bit shift in Ada 83
implemented with arrays of 1 bit variables! Let's face it, in a language
promulgated specifically for *embedded* applications, this was nonsense!)

: It is not that I think :+= is peculiar because it is not in the RM, rather
: +:= is not in the RM because it is peculiar, i.e. it would be VERY difficult
: to put it in without running into nasty semantic ramifications.

I'm sorry, I still don't see that. The trouble is that we still disagree
on the status of ":=" I think. If 'procedure ":=" (....)' were acceptable,
and I still don't understand why not, then I can't see anything wrong with
'procedure ":+="(...)' (although I think that "+=" looks nicer).

: I don't know how skilled you are as a language designer. Often it is 
: frustrating to plain users of the language that something that seems
: like it should be simple to do is not there, when it seems so simple
: to put it in.

I have designed a language and led the team writing a compiler for a 
specialist event driven application. Not a great deal of experience, and
not at all like Ada, but I have spent some time thinking about the
implementation of such features in C++. I still don't see where the 
problem is.

[delete]

: Indeed it was very nearly the case that Ada 95 ended up with no user
: defined assignment, since we couldn't find a way to do it. Then quite
: late in the process someone suggested the current approach, and that
: turned out to be tricky but practical, so it was put in.

I would be interested in seeing a discussion about these design decisions.
Some years ago I read the book "Engineering a Compiler" by some engineers
at Digital. Fascinating stuff, but I haven't seen much similar discussion
by language designers. I remain to be convinced, but I have an open mind
(honest).

Thanks for your comments.

Bill Williams

Re: Ada self-referential operators

[Keith Thompson]

In <3hg6gj$mkt@miranda.gmrc.gecm.com> bill@valiant (R.A.L Williams) writes:
[...]
> Obviously, any compiler which tried to optimise a basic block containing
> that would be in for a nasty surprise! So, OK, we disable statement level
> optimisation where overloaded assignment is used. Caveat emptor (I don't
> know the latin for programmer) -- if you use this construct, don't expect
> optimisation.

Optimization isn't really an issue.  Optimizers typically operate on
some intermediate form (or sometimes on machine code).  A call to a
user-defined operator (assignment or otherwise) would appear to the
optimizer as an ordinary subprogram call, which it could optimize or
not just as if it were written explicitly using call notation.  If the
optimizer has access to the body of the subprogram (e.g., if it's declared
inline), it may be able to do something with it.

As for user-defined assignment, (as in

    procedure ":="(Target: in out Some_Type; Source: in Some_Other_Type);

) I'd love to see it in the language myself, but defining it really is
more complicated than it looks.  I don't claim to understand all the
issues, so I'll leave it to others to address them.

-- 
Keith Thompson (The_Other_Keith)  kst@thomsoft.com (kst@alsys.com still works)
TeleSoft^H^H^H^H^H^H^H^H Alsys^H^H^H^H^H Thomson Software Products
10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2718
When you're a nail, every problem looks like a hammer.

Ada self-referential operators

[R.A.L Williams]

In article <3g9nir$fpl@gnat.cs.nyu.edu> RobertDewar wrote:
: "The "+=" operator is MADE for this statement, but its ONLY benifit is
: to save me 11 characters in my source file."

: that's going a little far, the purpose of += is much more than saving
: characters, it abstracts the operation to be an increment instead of
: a computation and assignment that just happens to be an increment. 

[long and convincing rationale for += deleted]

: but still I think it is the right choice not to complicate the language to
: add these peculiar forms. Note that in C, where + cannot in any case be
: redefined, they are cleaner, and in algol-68, where parameters are strong
: enough (using ref) to describe variables, they are also cleanly addable.

You seem to be saying that 'because the LRM doesn't have these operators
there is something peculiar about them'. Forgive me if that was not your
intent. 

I'm very much in favour of these concise representations of what the
programmer really intends. I was recently a team leader on a project
(written in C, but that is not really relevant) where, because of constraints
on the target hardware, there was 100% code inspection before attempting
to integrate. Now when you're faced with the quantities of code that
we had and the task of verifying it against design specs and Yourdon
analysis (the design methodology retained p-specs into the coding stages
as design information) then you *really* appreciate every labour saving
device that the coder can introduce!

: Often in a lanuage there are things that would be nice but don't fit very 
: well. If nice is *very* nice, then sometimes we are willing to accept a
: complex wart in the language, but if nice is only a *little* nice, it's
: better to opt for cleanliness, and this is such a case I think in Ada 95.

So far as I can see, the main reason that allowing "+=" etc. to be
overloaded does not fit in with the rest of Ada is that ":=" cannot
be overloaded. Well, this again is an unfortunate oversight. In linear
algebra packages, for example, it is frequently desirable to have
an implicit garbage collection mechanism for temporary results. The
assignment operator is a good place to put this. In C++ the overloaded
assignment operator is often used to implement constraint checking.
While this is not as valuable in Ada, I know of at least one military
C3I system where a particular type, TX frequency, must be constrained
into three non-contiguous bands. This would be hard to represent
without an explicit test in Ada. (Since most of the code for that
particular system was originally written in Fortran I suppose the
issue never arose!)

Admittedly, the situation in C++ is different from Ada. In C++ every
expression has a value, and an assignment counts as an expression. It 
is therefore logical to allow overloading the assignment operator
as a function. In Ada, OTOH, ":=" would need to be overloaded by a
procedure, making it unique amongst the 'predefined operators'. I don't
see any other reason why this is not a 'clean' extension. Perhaps
":=" wouldn't stick out so much if it had "+=" etc. to keep it company?

Still, I suppose we must accept the consensus view on Ada9x. Perhaps
in Ada0x....?

Bill Williams

Re: Ada self-referential operators

[Kenneth Almquist]

Robert Dewar <dewar@cs.nyu.edu> wrote:
> It is not that I think :+= is peculiar because it is not in the RM, rather
> +:= is not in the RM because it is peculiar, i.e. it would be VERY difficult
> to put it in without running into nasty semantic ramifications.

Perhaps I'm missing them.  What about the following rules?

1.  For each function of the form

          function "+"(L: type_1; R: type_2) return type_1;

    where type_1 is not limited, implicitly define:

          procedure "+:=" (L: in out type_1; R: in type_2) is
          begin
              L := L + R;
          end "+:=";

    These implicit definitions should behave similarly to the implicit
    definitions of "/=" which occur in Ada 83 and Ada 95.  Explicit
    defintions of "+:=" are illegal.

2.  If a statement of the form "A +:= B;" is encountered, treat it as
    the procedure call "+:="(A, B).
					Kenneth Almquist

Re: Ada self-referential operators

[John Volan]

ka@socrates.hr.att.com (Kenneth Almquist) writes:

>Robert Dewar <dewar@cs.nyu.edu> wrote:
>> It is not that I think :+= is peculiar because it is not in the RM, rather
>> +:= is not in the RM because it is peculiar, i.e. it would be VERY difficult
>> to put it in without running into nasty semantic ramifications.
>
>Perhaps I'm missing them.  What about the following rules?
>
>1.  For each function of the form
>
>          function "+"(L: type_1; R: type_2) return type_1;
>
>    where type_1 is not limited, implicitly define:
>
>          procedure "+:=" (L: in out type_1; R: in type_2) is
>          begin
>              L := L + R;
>          end "+:=";
>
>    These implicit definitions should behave similarly to the implicit
>    definitions of "/=" which occur in Ada 83 and Ada 95.  Explicit
>    defintions of "+:=" are illegal.
>
>2.  If a statement of the form "A +:= B;" is encountered, treat it as
>    the procedure call "+:="(A, B).
>					Kenneth Almquist

First of all, what you're proposing is not quite analogous to the
relationship between "=" and "/=". In the case of equality and
inequality, both are functions, so one function is derived from
another.  In the case of "+" and "+:=", the first is a function while
the latter is a procedure, so you're proposing to have a procedure be
implicitly derived from a function.  A bit of a conceptual leap...
Well, okay, that's a minor point.

However, who says that implicitly deriving one subprogram from another
is a *good* thing?  Who says that doing *anything* implicitly is a
good thing?  Isn't it a fundamental tenet of the design of Ada to *avoid*
"implicitness" as much as possible?

Realize that the relationship between "=" and "/=" is *unique* within
Ada.  Isn't it possibile that this is because there is something
special about these functions, something which should not necessarily
set a precedent?  The notion of "equality" has some particularly
loaded conceptual baggage to it, and there may be important reasons
for guaranteeing the meaning of "inequality".  (I'll defer to others
with more language-lawyer experience to take up this point.)

But just because it's desirable to have a strong relationship between
"=" and "/=" doesn't mean that it's desirable to establish strong
relationships between other operator symbols.  For instance, why
bother defining binary "-" (subtraction)?  Can't it just be derived
from from binary "+" (addition) and unary "-" (negation)?  In fact, by
this argument, shouldn't we *prohibit* overloading of subtraction and
*require* it to be automatically defined as:

    function "-" (Left : in Type_1; Right : in Type_2) return Type_3 is
    begin
      return Left + (- Right);
    end "-";

whenever the following are available:

    function "+" (Left : in Type_1; Right : in Type_2) return Type_3;
    function "-" (Right : in Type_2) return Type_2;

pragma Flame (On);
pragma Implicit_Smiley (On);

But here's my *real* objection to all this talk about "self-
referential operators": A symbol like "+:=" is a YAFO -- Yet Another
Funky Operator!  (You can replace "Funky" with something ruder if
you're so inclined. :-) Why do we need YAFOs like "+:=" and "*:=" when
you can write perfectly good procedures with perfectly readable names
like "Increment" and "Multiply"?  If you want such procedures to be
automatically supplied by the language, consider building them in as
attributes of numeric types, as I suggested a few posts back, e.g.:

    procedure T'Increment (X : in out T; By : in T);
    procedure T'Multiply  (X : in out T; By : in T);

What's so hard about saying something like:

    Integer'Increment (Long_Complex_Name_Of_An_Integer_Varable, By => 2);

What tremendous advantage do we gain by being able to say something like:

    Long_Complex_Name_Of_An_Integer_Variable +:= 2;

I never cease to be amazed (and disgusted) at how enamored some people
in this industry seem to be about using arbitrary sequences of special
characters for just about everything under the sun.  Who says it's
*desirable* to load up a language with a lot of cryptic
"mathematicalese"?  Doesn't anyone remember how *hard* it was to learn
math, way back in grade school?

IMHO, the operators that Ada currently supplies ought to be considered
a grudging concession to the algebraic indoctrination we all suffered
as children.  The only reason they are there at all is because they've
been beaten into our heads for so long that it is impossible to escape
them.  The last thing they should be viewed as is as a precedent for
yet more operators.

Consider a related issue: Doesn't anyone remember what a struggle it
was to internalize things like arithmetic precedence rules?  If
precedence rules are so easy to digest, then why did the designers of
Ada refuse to establish different precedence levels for logical "and"
and "or", by analogy with the precedence distinction between "+" and
"*"?  Why are we *forced* to use parentheses in any expression that
mixes "and" and "or"?  Answer: Because nobody back in grade school
indoctrinated us in Boolean algebra!  If you think about it, the fact
that multiplication takes precedence over addition is really a very
arbitrary rule.  It is perfectly possible to devise a completely
self-consistent algebraic system in which addition has higher
precedence.  Likewise, it is possible to devise two completely
self-consistent Boolean algebra systems, one in which "and" takes
precedence over "or", and another in which "or" takes precedence over
"and".  There's no a priori reason for favoring one system over the
other.

However, the precedence of multiplication over addition is so
ingrained in our culture that you can guarantee that every Ada
programmer will automatically understand the meaning of

	A + B * C

without having to insert any parentheses.  On the other hand, there is
no such cultural bias distinguishing "and" and "or", so there is no
guarantee that a programmer will automatically understand the meaning of

	A and B or C

without clarifying it with parentheses.

By the same token, most educated people don't come with a built-in,
ingrained understanding that, for instance "<<" sometimes means
bitwise left-shift, but other times means write-to-a-stream.  Or that
"*" sometimes means multiply, sometimes means declare-a-pointer, and
other times means dereference-a-pointer.  Or that "&" sometimes means
a reference but other times means bitwise-"and"-on-an-integer, whereas
"&&" means logical-"and"-on-a-boolean.  Ad nauseum.

Look, if you want to be able to write gobbledegook like:

	A<<B* *C^=D>>(--E[F++],G)-H%(!I:J=K?L=M,N);

then go get yourself a C/C++ [sic] compiler.  Heck, why go half-way --
why don't we all just program in APL?

Ada, on the other hand, was designed for *readability*.  

YAFOs -- JUST SAY NO!!!!

pragma Implicit_Smiley (Off);
pragma Flame (Off);

Oh boy, now I've done it!  Here come the language-wars! :-)

--------------------------------------------------------------------------------
 Me : Person :=
   (Name => "John G. Volan",  E_Mail_Address => "jgv@swl.msd.ray.com",
    Employer => "Raytheon",   Affiliation => "Enthusiastic member of Team-Ada!",
    Shameless_Controversial_Marketing_Slogan_For_Favorite_Language =>
      "<<<< Ada95: The World's *FIRST* Internationally-Standardized OOPL >>>>" &
      "Inheritance, hierarchical name-space, generic templates, type-safety, " &
      "readability, C/C++/COBOL/FORTRAN interoperability, numeric precision, " &
--    ^^^^^^^^^^^^^  a n d   n o   Y A F O s ! ! !  :-)
      "multi-threading, distributed systems, real-time, safety-critical ...  " &
      "<< A d a 9 5  :  Y o u   n a m e   i t ,  i t ' s   i n   t h e r e >>",
    Humorous_Language_Lawyerly_Disclaimer =>
      "These opinions are undefined by my employer, so using them would be "  &
      "totally erroneous ... or would that be a bounded error? :-) ");
--------------------------------------------------------------------------------

Re: Ada self-referential operators

[Jay Martin]

Brilliantly said (John Volan)!  This gets saved in my language design directory.

>cryptic "mathematicalese"

More like crypitic PSEUDO "mathematicalese" since we don't want to
give it any mathematical validity because it has none.

Its sickening how C has brain-damaged so many programmers out there.
"Where's my increment operators? I got to have my increment operators!
 Convenience Or Death!".  

Conjecture: (Software Engineering /= Programming Convenience)

Well maybe they are smart. Every time you add a crazy operator,
idiom, unchecked or bizarre syntactic feature, you make it harder for
outsiders to program the language.  This makes the experts in the
language more valuable, thus they get more $$$ and power!  It also
gives them that a feeling of superiority because only programmers in
their elite club are "brilliant" enough to understand their sacred
code!

Jay

Re: Ada self-referential operators

[Brian Rogoff]

John G. Volan writes:
    I never cease to be amazed (and disgusted) at how enamored some people
    in this industry seem to be about using arbitrary sequences of special
    characters for just about everything under the sun.  Who says it's
    *desirable* to load up a language with a lot of cryptic
    "mathematicalese"?  Doesn't anyone remember how *hard* it was to learn
    math, way back in grade school?

In some problem domains it is very useful to have concise operators. 
MATLAB, for example, even makes up new "YAFOs" to represent common 
matrix manipulations. While I agree that overuse of special operators 
could lead to highly unreadable code, tasteful use of such operators 
makes reading math, and by extension, mathematical code, easier (IMO). 
People could also choose bad names for functions and variables and make 
code unreadable that way, yet I've never heard it suggested that we should 
program in the untyped lambda calculus!

    IMHO, the operators that Ada currently supplies ought to be considered
    a grudging concession to the algebraic indoctrination we all suffered
    as children.  The only reason they are there at all is because they've
    been beaten into our heads for so long that it is impossible to escape
    them.  The last thing they should be viewed as is as a precedent for
    yet more operators.

Eiffel 3 allows one to make up new "binary operator" names, although 
without true function overloading this is probably not too complicated. 
Any Eiffelists feel that this is bad/good? Also, I am pretty sure that 
Axiom, and probably other computer math systems, aloow one to define 
new operators. Maybe it's just something that math folks like?

-- Brian

Re: Ada self-referential operators

[John DiCamillo]

rogoff@sccm.Stanford.EDU (Brian Rogoff) writes:

>John G. Volan writes:
>    I never cease to be amazed (and disgusted) at how enamored some people
>    in this industry seem to be about using arbitrary sequences of special
>    characters for just about everything under the sun.  Who says it's
>    *desirable* to load up a language with a lot of cryptic
>    "mathematicalese"?  Doesn't anyone remember how *hard* it was to learn
>    math, way back in grade school?

>In some problem domains it is very useful to have concise operators. 
>MATLAB, for example, even makes up new "YAFOs" to represent common 
>matrix manipulations. While I agree that overuse of special operators 
>could lead to highly unreadable code, tasteful use of such operators 
>makes reading math, and by extension, mathematical code, easier (IMO). 
>People could also choose bad names for functions and variables and make 
>code unreadable that way, yet I've never heard it suggested that we should 
>program in the untyped lambda calculus!

>    IMHO, the operators that Ada currently supplies ought to be considered
>    a grudging concession to the algebraic indoctrination we all suffered
>    as children.  The only reason they are there at all is because they've
>    been beaten into our heads for so long that it is impossible to escape
>    them.  The last thing they should be viewed as is as a precedent for
>    yet more operators.

Yeah! In fact, let's spell *everything* out!

function add
   taking integer lhs and integer rhs
   giving integer is
   begin return lhs plus rhs end

function smiley
   taking nothing
   giving sarcasm is
   begin return quote colon dash rightparen quote end

smiley smiley smiley

No offence John, I know you didn't mean to take it this
far!

>Eiffel 3 allows one to make up new "binary operator" names, although 
>without true function overloading this is probably not too complicated. 
>Any Eiffelists feel that this is bad/good? Also, I am pretty sure that 
>Axiom, and probably other computer math systems, aloow one to define 
>new operators. Maybe it's just something that math folks like?

At the risk of getting completely off the subject (whatever
it was :-) I would add that user-definable infix operators
are hardly unheard of in newer languages.  Cecil and Self
both use the convention (a'la Smalltalk? its been a while)
that any function name beginning with a letter uses prefix
syntax, while any function beginning with a punctuation
character uses binary infix syntax.  Standard ML allows for
functions to be named with either letter combinations or
special character combinations; regardless of name, any
function can be specified as prefix or infix (but not both).

So no, it's not just something that "math folks" like.
And no, I'm not suggesting that Ada would be better if
only it had cool overloaded operator syntax like SML.

But they really are cool, y'know?

-- 
    ciao,
    milo
================================================================
    John DiCamillo                        Pinin' for the fjords?
    milod@netcom.com                  What kind of talk is that?

Re: Ada self-referential operators

[David Weller]

This has all been a very interesting discussion (as well as the
Subtract C, Add Ada thread).  One thing we seem to leave out is how
we _read_.  The issue isn't whether we can resolve a symbol, but
whether our minds can successfully integrate the symbol into
something meaningful as we read.  That's part of the reason why Ada
shuns clever stuff like in C (the ever present while(*p++=*q++) comes
to mind).  It's not that we can understand what's going on -- the
above example is obvious to anybody who has a half-assed knowledge of
C -- the issue is, what's the chance of us skipping or
misinterpreting a symbol?  The more closely aligned a computer
language is to our natural language, the higher the chance of
"complete" comprehension.  Mind you, I"m not equating "complete"
comprehension with verification of logical paths (which is another
matter entirely).

Ada, because it typically avoids symbols, has a higher "readability"
level than C (not to mention the fact that Ada is case insensitive, a
another critical "readability" issue).  This doesn't imply that Ada
is automatically _more_ readable than a C (or C++) program, merely
that it _can_ be (and typically is) more readable.  Modula is another
language that leans in this direction.

Ah, well, enough cognitive philosophy for one day.

-- 
      Frustrated with C, C++, Pascal, Fortran?  Ada95 _might_ be for you!
	  For all sorts of interesting Ada95 tidbits, run the command:
"finger dweller@starbase.neosoft.com | more" (or e-mail with "finger" as subj.)
	

Re: Ada self-referential operators

[pang]

In article <ROGOFF.95Feb8090424@sccm.Stanford.EDU>,
Brian Rogoff <rogoff@sccm.stanford.edu> wrote:
>John G. Volan writes:
>    I never cease to be amazed (and disgusted) at how enamored some people
>    in this industry seem to be about using arbitrary sequences of special
>    characters for just about everything under the sun.  Who says it's
>    *desirable* to load up a language with a lot of cryptic
>    "mathematicalese"?  Doesn't anyone remember how *hard* it was to learn
>    math, way back in grade school?
>
>In some problem domains it is very useful to have concise operators. 
>MATLAB, for example, even makes up new "YAFOs" to represent common 
>matrix manipulations. While I agree that overuse of special operators 
>could lead to highly unreadable code, tasteful use of such operators 
>makes reading math, and by extension, mathematical code, easier (IMO). 
>People could also choose bad names for functions and variables and make 
>code unreadable that way, yet I've never heard it suggested that we should 
>program in the untyped lambda calculus!

the problem is the keyboard/ascii character set. it's not rich/expressive
enough! 

what does it take to use symbol/graphics to represent operators and other 
language constructs/elements?

Re: Ada self-referential operators

[Robert I. Eachus]

In article <D3ruwC.GoF@world.std.com> pang@world.std.com writes:

  > the problem is the keyboard/ascii character set. it's not rich/expressive
  > enough! 

  > what does it take to use symbol/graphics to represent operators and other 
  > language constructs/elements?

   An APL keyboard of course.  ;-)

   (Exit smiley mode.)  APL has been called a "write only" language,
and I tend to use it exactly that way.  If I ever expect to need to be
able to read the code (even the day I write it), I use Ada.  This only
emphasizes the point others have been making that lots of operator
symbols may may code easier to write, but they certainly make it a LOT
harder to read.


--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Ada self-referential operators

[Norman H. Cohen]

In article <D3nsJJ.6qz@swlvx2.msd.ray.com>, jgv@swl.msd.ray.com (John
Volan) writes:

|> Realize that the relationship between "=" and "/=" is *unique* within
|> Ada.

Sad but true.  I wish the ordering operators worked analogously:  For two
operands of a given type T and a result of type Boolean, you would be
allowed to define (or override a predefinition) of exactly one of "<",
">", "<=", or ">=", and the others would be implicitly defined for you.
If the programmer chose to define "<", the others would be implicitly
defined as follows:

   function ">" (Left, Right: T) return Boolean is
   begin
      return Right < Left;
   end ">";

   function "<=" (Left, Right: T) return Boolean is
   begin
      return Left < Right or Left = Right;
   end "<=";

   function ">=" (Left, Right: T) return Boolean is
   begin
      return Right < Left or Right = Left;
   end ">=";

If the programmer chose to define "<=", the others would be implicitly
defined as follows:

   function "<" (Left, Right: T) return Boolean is
   begin
      return Left <= Right and Left /= Right;
   end "<";

   function ">" (Left, Right: T) return Boolean is
   begin
      return Right <= Left and Right /= Left;
   end ">=";

   function ">=" (Left, Right: T) return Boolean is
   begin
      return Right <= Left;
   end ">=";

This would only be allowed for types with an "=" operator (nonlimited
types and limited types with programmer-defined "=").

(For some relations it may be most straightforward to define "<"
explicitly, but for others, such as set containment, it is more
straightforward to define "<=" explicitly.  Note that we do NOT define
A>=B, for example, to be equivalent to not(A<B).  That relationship does
not hold for partial orders such as the set containment relation.)

The advantages of this approach would be:

   - Guaranteed consistency among the ordering operators.
   - Avoidance of tedious, redundant work to provide a complete set of
       ordering operators.
   - Ability to declare a single ordering operator to a generic formal
       function but to have operator clearest in a given context
       available anywhere in the generic template.

--
Norman H. Cohen    ncohen@watson.ibm.com

Re: Ada self-referential operators

[Robert Dewar]

Maybe we can decide that the business of < generating other operators
automatically is merely a source representation issue? :-)

Re: Ada self-referential operators

[Larry Kilgallen, LJK Software]

In article <3id9qi$a7m@usenet.srv.cis.pitt.edu>, sparre+@pitt.edu (Jacob S. Andersen) writes:

> A really useful feature (for math) in a programming language would be the
> ability to explain algebraic relations (is this the right words?). Something
> like:
>
>     operator Complex "*" Complex precedes Complex "+" Complex ;
>     operator Complex "-" Complex equivalent with Complex "+" Complex ;
>     operator "-" Complex precedes Complex "*" Complex ;
>
>     relation Complex.Left "*" Complex.Right equivalent with
>              Complex.Right "*" Complex.Left ;
>     relation Complex.Left "+" Complex.Right equivalent with
>              Complex.Right "+" Complex.Left ;
>     relation Complex.Left "-" Complex.Right equivalent with
>              Complex.Left "+" ( "-" Complex.Right ) ;

I don't know math, but I do know software maintenance, and I think
this would be a perfectly horrible addition to Ada.  (I don't mind
if you make the change to C.)

I suppose flexible precedence declarations would be ok so long as
they could only be used on symbols which are _not_ in the standard
precedence scheme for the language.

> I think it might help optimizing the code, but I'm not sure.

For write-only source code, I supposed it might make the source
shorter, but readability is paramount in a program which is to
be dealt with on two or more days.

For "optimizing" machine instructions, there are lots of things
which can be done with the innards of compilers, independent of
the exact syntax of source language.  Some of them, of course,
fare better with a high level language like Ada, and nothing
you propose would affect high quality optimizers one way or the
other.

I don't mean to be hostile to research mathematicians, but I
presume the reason you brought it up for discussion is to get
the perspective of others.

Larry Kilgallen
Using Ada since 1988 without a government mandate

Re: Ada self-referential operators

[Val Kartchner]

In article <3id9qi$a7m@usenet.srv.cis.pitt.edu>,
Jacob S. Andersen <sparre+@pitt.edu> wrote:
>Some comments to the proposal about the proposal for automatic generation of 
>relational operators (">", "<", ">=" and "<=").
>
>I too would like this in Ada [....]

This would mean that the compiler would be behaving in a reasonable,
predictable way, but not under the explicit command of the programmer.
This would be akin to automatic type conversions.  It is not the Ada way
to do something implicitly just for the convenience of the programmer.

-- 
|================= #include <stddisclaimer.h> ================/// KB7VBF/P11 =|
| "AMIGA: The computer for the creative mind" (tm) Commodore /// Weber State  |
| "Macintosh: The computer for the rest of us"(tm) Apple \\\///   University  |
|=== "I think, therefore I AMiga" -- val@cs.weber.edu ====\///= Ogden UT USA =|