TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy

TEAM-ADA@LISTSERV.ACM.ORG

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Content-Transfer-Encoding:
7bit
Sender:
"Team Ada: Ada Advocacy Issues (83 & 95)" <[log in to unmask]>
Subject:
From:
Nick Roberts <[log in to unmask]>
Date:
Thu, 22 Apr 1999 17:21:04 +0100
Content-Type:
text/plain; charset="iso-8859-1"
MIME-Version:
1.0
Reply-To:
Nick Roberts <[log in to unmask]>
Parts/Attachments:
text/plain (65 lines)
Tucker Taft <[log in to unmask]> wrote on 22 April 1999 00:24:


|Speaking as a compiler writer, I would say the implementation
|issues are minor, compared to everything else we already support.


I would second this, speaking from my own point of view; I suspect you'll
get other compiler writers who disagree. It could well make some tools
significantly trickier.

|The key issue in my view is the Ada design philosophy.  Extensible syntax
|is inconsistent with the principle that Ada programs are intended
|to be readily shared, read, understood, and enhanced by other
|programmers.  Extensible syntax is great for a "personal" programming
|language, but not great for a "group" or "team" or "enterprise"
|or "international" programming language.


I think it's interesting to compare languages such as POP, APL, Prolog (one
of my favourites), various derivatives thereof, and various other languages,
which permit unlimited definition of 'user' operators; in practice, such
special operators are used heavily in some languages (notably POP), but only
sparingly in most.

Personally, I find the ability to define a small selection of my own
operators in Prolog to be incredibly useful. There's no doubt that, without
care, you can reduce your code to something resembling the output of a
spaghetti machine on steroids; so the point is you have to take care not to
do this. The facility is otherwise tremendously useful, e.g. instead of (in
Ada):

   X := Max(Max(Max(Max(23.0-6.5*Y,Y),Y+Z),Y-Z,Limit);

I could define a 'max' operator, and put (in Prolog):

   X is 23.0-6.5*Y max Y max Y+Z max Y-Z max Limit,

and, I think most readers will agree, this is more readable rather than
less: the operator says what it means; it is associative, so its direction
of precedence doesn't matter; it is defined, fairly naturally I think, at a
lower precedence than the arithmetic operators.

However, I think it would also be fair---if rather blunt---to suggest that,
in a typical programming shop, you're always going to get a few programmers
who would be likely to abuse such a facility so badly that it's better to
take it away from everyone.  You could say that the danger of spaghetti
outweighs the danger of stodge.

|For what that's worth...

Ada was always designed as a thoroughly practical, workmanlike programming
language.  It had to be: the DoD would not have accepted anything less.  My
own opinion is that Tuck et al did a great job of continuing that
practicality, while updating the language to increase its flexibilty and
expressive power.  I feel, on balance, that introducing user-defined
operators would have decreased the practicality more than it would have
increased the power.

|-Tuck

-------------------------------------
Nick Roberts
-------------------------------------

ATOM RSS1 RSS2