From: pcm
Subject: What is the most "Elegant" Language?
Date: 
Message-ID: <01bcc53d$2d9ef3c0$2f2d11cb@pc1>
Does anyone want to venture an opinion on what is the most elegant
programming language in the world today?  

And has there been any recent languages especially noted for their
elegance?

- Peter.

(Personally, my vote would go for Scheme with the latest ANSII standard C++
a close second, but I'm certainly open to suggestions)

From: Ulrich Mayring
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <5vuv46$33e$1@News.CoLi.Uni-SB.DE>
"pcm" <···@mira.net> writes:


>Does anyone want to venture an opinion on what is the most elegant
>programming language in the world today?  

What do you mean by elegant? I can think of these criteria:

1) clear and conceptually well founded semantics. I guess Prolog and LISP 
would do well in this area, as would many other logic and functional 
programming languages.
2) as little syntax as possible. Prolog, LISP score high again.
3) as little keyboard-typing as possible during development - I would pick 
something like Prograph.
4) similarity to human thinking. You would have to look at neuronal nets, 
frame-based systems, rules-based systems or whatever else you think 
actually resembles human thinking. I guess you could make a point for OOP 
here, too.
5) scalability to any project-size. This is probably still unresolved, 
no language that I know of does that well. If that is important to you, I 
would not so much look at the language itself, but at the actual tools 
available.
6) personal anti-stress factor. Pick your favorite language ;-)

Ulrich

BTW, does anyone have any electronic documentation for LPA MacProlog? I 
have a demo version here and need some kind of list of built-in predicates 
and GUI documentation.
--
Ulrich Mayring
                                           Please reply to:  u @ 123 . org
==========================================================================
You can also use ulim @ addict . de  or  ulim @ freebsd . first . gmd . de
From: pcm
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <01bcc5b1$58090280$682d11cb@pc1>
Ulrich Mayring <····@127.0.0.1> wrote in article
<············@News.CoLi.Uni-SB.DE>...
> "pcm" <···@mira.net> writes:
> 
> 
> >Does anyone want to venture an opinion on what is the most elegant
> >programming language in the world today?  
> 
> What do you mean by elegant? I can think of these criteria:
> 
> 1) clear and conceptually well founded semantics. I guess Prolog and LISP

> would do well in this area, as would many other logic and functional 
> programming languages.

I think Lisp has become far too bloated.  Scheme seems to be an elegant
improvement.  

> 3) as little keyboard-typing as possible during development - I would
pick 
> something like Prograph.

Prograph?  Never heard of that.  Is it some form of drag and drop based
programming tool?

> 4) similarity to human thinking. You would have to look at neuronal nets,


I think this depends on *who's* human thinking.  I'm sure a zen master
would have a far more elegant mental landscape than, for example, any
typical politition or manager.

> 6) personal anti-stress factor. Pick your favorite language ;-)

I like this!

- Peter.
From: Ulrich Mayring
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <6035j6$kjo$1@News.CoLi.Uni-SB.DE>
"pcm" <···@mira.net> writes:

>I think Lisp has become far too bloated.  Scheme seems to be an elegant
>improvement.  

Yes, I was implying the "old" Prolog and LISP standards, as far as clear 
semantic concepts are concerned. Prolog and LISP both have become 
"cluttered" with meta-predicates/functions and other useful things that 
you need to do some real-world programming. However, both languages are 
IMHO not half as cluttered as C++ ;)  Can't say much about Scheme, but I 
always tend to think OO languages distribute their functionality over a 
too large area of code to be really elegant. Which brings me to another 
good criterion for elegance:

7) amount of source code needed to solve a problem. A language that needs 
less source code to solve a problem than any other can't be all unelegant.

>> 3) as little keyboard-typing as possible during development - I would
>pick 
>> something like Prograph.

>Prograph?  Never heard of that.  Is it some form of drag and drop based
>programming tool?

Yes, you can get a demo version for Macintosh. Basically it shows you an 
object on the screen and you connect it to other objects. Then you define 
the interfaces between objects, by dragging e.g. a button to it. Then, 
whenever you press that button on the first object, the second one is 
invoked. This sounds like a pure GUI builder, but it isn't. You can not 
only drag and drop GUI elements, but also real code (like predefined or 
self-made functions). I haven't actually done anything in Prograph, but 
there is a newsgroup comp.lang.prograph, where people will give you 
detailed information or an FAQ.

>I think this depends on *who's* human thinking.  I'm sure a zen master
>would have a far more elegant mental landscape than, for example, any
>typical politition or manager.

This probably is debatable, until you clearly define "elegant mental 
landscape" ;-)  But I also like to think a Zen master's brain is much 
simpler to understand and visualize than a regular person's.

Ulrich
--
Ulrich Mayring
                                           Please reply to:  u @ 123 . org
==========================================================================
You can also use ulim @ addict . de  or  ulim @ freebsd . first . gmd . de
From: Mark Carroll
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <6078k1$hqk$1@news.cis.ohio-state.edu>
Hmmm... personally, I think elegance in a language comes from having
compact but expressive syntax and semantics: the language definition
is small, but you can write pretty much anything you want fairly
concisely and naturally and your source code is readily comprehensible
by others.

I think Modula-3 is quite elegant, considering you can do systems
programming in it. But, I'll probably find a functional language
I consider more elegant once I've learned more better.

Followups trimmed to comp.lang.misc.

-- Mark
From: Joachim Hoffmann
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <60e1li$ocp@fstgal00.tu-graz.ac.at>
····@127.0.0.1 (Ulrich Mayring) wrote:
>"pcm" <···@mira.net> writes:
>>Does anyone want to venture an opinion on what is the most elegant
>>programming language in the world today?  

I vote for J. (http://www.jsoftware.com)

>What do you mean by elegant? I can think of these criteria:

>1) clear and conceptually well founded semantics. I guess Prolog and  LISP 
>would do well in this area, as would many other logic and functional 
>programming languages.
J: very short grammar; no exceptions, consistent.
Pure functional and also explicit programming style possible.

>2) as little syntax as possible. Prolog, LISP score high again.
IMHO J also, see above.

>3) as little keyboard-typing as possible during development - I would pick 
>something like Prograph.
Ervery primitive in J is a (composite) ASCII symbol of max. 2 chars.
No reserved words.
No memory allocation nor variable declarations.

>4) similarity to human thinking. You would have to look at neuronal nets, 
>frame-based systems, rules-based systems or whatever else you think 
>actually resembles human thinking. I guess you could make a point for OOP 
>here, too.
J is devoloped following the English language and
is also descibed in terms of a natural language,
e.g. nouns, verbs, adverbs, gerunds, copula ...

Nevertheless it's a very powerful mathematical notation and
practical progamming language.

>5) scalability to any project-size. This is probably still unresolved, 
>no language that I know of does that well.
>...
No limit on object size in J. Higly modular and OO-oriented.
Easy access to other software.

>6) personal anti-stress factor. Pick your favorite language ;-)
Developing in J is fun, because your problems are solved very
quickly and productively, without overhead imposed by the language
itself.
In relation to the effort of learning J,
my expressivity (ability to solve problems)
was raised exponentially.




JoHo
From: David Ness
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <342A9A28.325E284E@ibm.net>
Joachim Hoffmann wrote:
> 
> <snip>
>
> Ervery primitive in J is a (composite) ASCII symbol of max. 2 chars.
>

Not that it matters much, but this is no longer quite true. V3.02 introduced `map fetch' represented
by `{::'. Of course, this doesn't invalidate anything you were saying ...
From: Kevin Albrecht
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <01bcc54a$d93f7e40$82bc2599@default>
> Does anyone want to venture an opinion on what is the most elegant
> programming language in the world today?  
> 
> And has there been any recent languages especially noted for their
> elegance?
> 
> (Personally, my vote would go for Scheme with the latest ANSII standard
C++
> a close second, but I'm certainly open to suggestions)

IMHO, C++ is one of the most _useful_ languages, and I'm sure I'll always
use it, but it is one of the most unelegant languages.  I like languages
that don't ever look cluttered, like Visual Basic, but VB is definitely not
half as useful as C++.  My vote goes to Icon.

Kevin Albrecht
······@earthlink.net
http://home.earthlink.net/~kevalb/
From: Dann Corbit
Subject: TROLL BAITING STUFF:  WasRe: What is the most "Elegant" Language?
Date: 
Message-ID: <01bcc54f$96fbbda0$90d6a826@DCorbit.products.solutionsiq.com>
The most elegant language is whichever one you like the best.  Now please
go away.  In news:comp.lang.c we like the posts to be topical.
-- 
C-FAQ ftp sites: ftp://ftp.eskimo.com ftp://rtfm.mit.edu
Hypertext C-FAQ: http://www.eskimo.com/~scs/C-faq/top.html
C-FAQ Book: ISBN 0-201-84519-9.
Want Software?  Algorithms?  Pubs? http://www.infoseek.com

pcm <···@mira.net> wrote in article <··························@pc1>...
> 
> Does anyone want to venture an opinion on what is the most elegant
> programming language in the world today?  
> 
> And has there been any recent languages especially noted for their
> elegance?
> 
> - Peter.
> 
> (Personally, my vote would go for Scheme with the latest ANSII standard
C++
1.  There is no ANSI standard for C++, it is still an ARM only
2.  It's ANSI (one I)
3.  ISO would be world-wide, while ANSI is only for USA.
4.  Trolls of this nature should cover a wider area, you left out ML and
FORTRAN, among other things.

> a close second, but I'm certainly open to suggestions)
Suggestion:
Spam, trolls and flames are considered rude.  Please go away and don't come
back until you figure out how to be topical.
From: pcm
Subject: Re: TROLL BAITING STUFF:  WasRe: What is the most "Elegant" Language?
Date: 
Message-ID: <01bcc5b2$88cb32c0$682d11cb@pc1>
> The most elegant language is whichever one you like the best.  Now please
> go away.  In news:comp.lang.c we like the posts to be topical.

Well thanks for that.  Now you can put your head back into the sand and
stop bothering people trying to have a sensible discussion.  

> Spam, trolls and flames are considered rude.  Please go away and don't
come
> back until you figure out how to be topical.

And self appointed moral leaders of the internet are a total
pain-in-the-arse.  If you don't have the intellectual capacity to
contribute then please keep your pathetic mouth shut.
From: Mark Wilden
Subject: Re: TROLL BAITING STUFF:  WasRe: What is the most "Elegant" Language?
Date: 
Message-ID: <3423DDBF.140D@mWilden.com>
Torkel Franzen wrote:
> 
>   The contribution you complain of was profound and to the point.
> Questions about "the most elegant language" are inane or disingenuous
> or both.

Bollocks. Such a question leads to discussing the definition of
"elegance" and how this quality applies to different languages.

Of course, if you aren't interested in this, ignore it (as I do most of
the cruft around here).
From: Alicia Carla Longstreet
Subject: Re: TROLL BAITING STUFF:  WasRe: What is the most "Elegant" Language?
Date: 
Message-ID: <34243CBB.75F5@ici.net>
Mark Wilden wrote:
 
> Torkel Franzen wrote:

> >   The contribution you complain of was profound and to the point.
> > Questions about "the most elegant language" are inane or disingenuous
> > or both.
 
> Bollocks. Such a question leads to discussing the definition of
> "elegance" and how this quality applies to different languages.

So please take your discussion to alt.elegance
 
> Of course, if you aren't interested in this, ignore it (as I do most of
> the cruft around here).

It is so much better if these types of discussions were taken to a place
where people are interested in them.

-- 
************************************************
* Alicia Carla Longstreet     ·····@ici.net    *
*     Remove NO_SPAM when replying to me.      *
************************************************
My compassion for someone is not limited
to my estimate of their intelligence.
      Dr Gillian, Star Trek IV, The Voyage Home
************************************************
My opinion is a view I hold until - well - until
I find out something that changes it.
                                Luigi Pirandello
From: Bill Coderre
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <bc-1909971622060001@17.127.18.74>
In article <··························@pc1>, "pcm" <···@mira.net> wrote:
|  Does anyone want to venture an opinion on what is the most elegant
|  programming language in the world today?  
|  
|  And has there been any recent languages especially noted for their
|  elegance?
|  
|  - Peter.

Will someone PLEASE create comp.lang.advocacy?

Pretty please?

bc
who KNOWS that the most "elegant" language is obviously TECO, because you
can make a self-replicating program in the fewest bytes.
From: Martin Rodgers
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <MPG.e8df2b017d5183b989a93@news.demon.co.uk>
Bill Coderre wheezed these wise words:

> Will someone PLEASE create comp.lang.advocacy?

I've suggested this myself, once or twice. ;)
 
> Pretty please?

I'll get my coat.
-- 
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
              Please note: my email address is gubbish
                         assert(got(coat)).
From: Ian Collier
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <11911-goldenrod.imc@comlab.ox.ac.uk>
In article <···················@17.127.18.74>, ··@wetware.com (Bill Coderre) wrote:
>bc
>who KNOWS that the most "elegant" language is obviously TECO, because you
>can make a self-replicating program in the fewest bytes.

Not necesarily, since there are many languages in which the empty program
is self-replicating.
-- 
---- Ian Collier : ···@comlab.ox.ac.uk : WWW page below
------ http://www.comlab.ox.ac.uk/oucl/users/ian.collier/imc.html
From: Ron Natalie
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <342316C7.1B46@sensor.com>
pcm wrote:
> 
> Does anyone want to venture an opinion on what is the most elegant
> programming language in the world today?
> 
"When I am working on a problem I never think about beauty. I only
 think about how to solve the problem. But when I have finished,
 if the solution is not beautiful, I know it is wrong."

      - Buckminster Fuller (1895-1983)
From: Alicia Carla Longstreet
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <34235061.70F9@ici.net>
Ron Natalie wrote:
 
> pcm wrote:

> > Does anyone want to venture an opinion on what is the most elegant
> > programming language in the world today?

> "When I am working on a problem I never think about beauty. I only
>  think about how to solve the problem. But when I have finished,
>  if the solution is not beautiful, I know it is wrong."
> 
>       - Buckminster Fuller (1895-1983)

Right, there is no such thing as a elegant programming language, only
elegant programs. Your question is like asking, what company makes the
most elegant hammer.

Now go away and stop bothering people with foolish questions.

-- 
************************************************
* Alicia Carla Longstreet     ·····@ici.net    *
*     Remove NO_SPAM when replying to me.      *
************************************************
My compassion for someone is not limited
to my estimate of their intelligence.
      Dr Gillian, Star Trek IV, The Voyage Home
************************************************
My opinion is a view I hold until - well - until
I find out something that changes it.
                                Luigi Pirandello
From: pcm
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <01bcc5b0$9d29a780$682d11cb@pc1>
Alicia Carla Longstreet <·····@ici.net> wrote in article 

> 
> Now go away and stop bothering people with foolish questions.
>

Haven't you heard the saying that there are no foolish questions, just
foolish answers?  It seems you have demonstrated this quite well.
 
> My compassion for someone is not limited
> to my estimate of their intelligence.
>       Dr Gillian, Star Trek IV, The Voyage Home

How ironic to see this in your message.  
From: Alicia Carla Longstreet
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <3423D8FF.1FE5@ici.net>
pcm wrote:
 
> Alicia Carla Longstreet <·····@ici.net> wrote in article
 
> > Now go away and stop bothering people with foolish questions.
 
> Haven't you heard the saying that there are no foolish questions, just
> foolish answers?  It seems you have demonstrated this quite well.

Haven't you heard about trolls, they hide in the deep dark recesses of
the NG's waiting to spring some apparently reasonable question to
confound and confuse others, a question that is foolish and designed
only to foment unrest among the denizens of the NG's.

Trolls can be identified by the following criteria: (although a post
meeting any or all of these criteria is not necessarily a troll)

1.) Posting to multiple newsgroups, often incompatible newsgroups.
2.) A question where the response is a matter of opinion.
3.) An area of opinion where persons are likely to have entrenched
feelings.
 
> > My compassion for someone is not limited
> > to my estimate of their intelligence.
> >       Dr Gillian, Star Trek IV, The Voyage Home
> 
> How ironic to see this in your message.

Compassion does not mean suffering the foolishness of those whose only
amusment in life is to make others angry and hurt.

-- 
************************************************
* Alicia Carla Longstreet     ·····@ici.net    *
*     Remove NO_SPAM when replying to me.      *
************************************************
My compassion for someone is not limited
to my estimate of their intelligence.
      Dr Gillian, Star Trek IV, The Voyage Home
************************************************
My opinion is a view I hold until - well - until
I find out something that changes it.
                                Luigi Pirandello
From: Mark Wilden
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <3423E847.705D@mWilden.com>
Alicia Carla Longstreet wrote:
> 
> Trolls can be identified by the following criteria: (although a post
> meeting any or all of these criteria is not necessarily a troll)

In other words, those criteria don't "identify" a troll at all. Sounds
like you need more criteria.

> 1.) Posting to multiple newsgroups, often incompatible newsgroups.

That's reasonable, but these newsgroups aren't incompatible with the
subject.

> 2.) A question where the response is a matter of opinion.

That criterion applies to 90% of all newsgroup posts.

> 3.) An area of opinion where persons are likely to have entrenched
> feelings.

I find others' opinions interesting on occasion, entrenched or not.

> Compassion does not mean suffering the foolishness of those whose only
> amusment in life is to make others angry and hurt.

If you can infer all that from a single question, you're not only
compassionate, you're telepathic. :)
From: Dennis Weldy
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <KZ4U671x8GA.64@news2.ingr.com>
 Do understand that Alicia is a veteran of the "Nudds Flamewars", and may
have a low tolerance for that which could start another ;-)

Dennis

pcm wrote in article <··························@pc1>...

>
>
>Alicia Carla Longstreet <·····@ici.net> wrote in article 
>
>> 
>> Now go away and stop bothering people with foolish questions.
>>
>
>Haven't you heard the saying that there are no foolish questions, just
>foolish answers?  It seems you have demonstrated this quite well.
> 
>> My compassion for someone is not limited
>> to my estimate of their intelligence.
>>       Dr Gillian, Star Trek IV, The Voyage Home
>
>How ironic to see this in your message.  
>
>
>.
> 
From: Mark Wilden
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <3423DE40.24C5@mWilden.com>
Alicia Carla Longstreet wrote:
> 
> Right, there is no such thing as a elegant programming language, only
> elegant programs. Your question is like asking, what company makes the
> most elegant hammer.

You obviously don't use hammers often. :) A good workman may not blame
his tools, but he can certainly distinguish elegance, usefulness,
strength, durability and fitness among them.
From: Bryant Brandon
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <40D05E52D2264238.3A2A8F29224D0147.6C231C212126D348@library-proxy.airnews.net>
In article <·············@ici.net>, ············@ici.net wrote:

[...]

>Now go away and stop bothering people with foolish questions.

   You're wrong here.  There are no foolish questions, only foolish
answers.  For example, to the subject of this thread I would have to say:
   I know nothing about elegance.  I also know nothing about assembly. 
Therefore, assembly is the most elegant.

B.B.                 --Actually, on Jeopardy, there are foolish questions.
From: David Fox
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <y5azpp6pu6f.fsf@graphics.cat.nyu.edu>
········@airmail.net (Bryant Brandon) writes:

> In article <·············@ici.net>, ············@ici.net wrote:
> 
> >Now go away and stop bothering people with foolish questions.
> 
>    You're wrong here.  There are no foolish questions, only foolish
> answers.  For example, to the subject of this thread I would have to say:
> 
> B.B.                 --Actually, on Jeopardy, there are foolish questions.

There are also foolish questions in journalism.
(And lots of other places, including here.)
From: Mark Wilden
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <3423E927.93A@mWilden.com>
Alicia Carla Longstreet wrote:
> 
> Right, there is no such thing as a elegant programming language, only
> elegant programs.

A programming language is implemented by programs. The syntax is its
user interface. Saying that there is no such thing as an elegant
programming language is like saying there is no such thing as an elegant
natural language, only elegant sentences.
From: Alexander Backlund
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <01bcc5f0$2871c9a0$LocalHost@default>
Mark Wilden <····@mWilden.com> wrote in article
<············@mWilden.com>...
> Alicia Carla Longstreet wrote:
> > 
> > Right, there is no such thing as a elegant programming language, only
> > elegant programs.
> 
> A programming language is implemented by programs. The syntax is its
> user interface. Saying that there is no such thing as an elegant
> programming language is like saying there is no such thing as an elegant
> natural language, only elegant sentences.

Which happens to be true.
From: Rijn Buve
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <3426667D.315FDBF4@cmg.nl>
Mark Wilden wrote:
> 
> Alicia Carla Longstreet wrote:
> >
> > Right, there is no such thing as a elegant programming language, only
> > elegant programs.
> 
> A programming language is implemented by programs. The syntax is its
> user interface. Saying that there is no such thing as an elegant
> programming language is like saying there is no such thing as an elegant
> natural language, only elegant sentences.

Questions like "what's the most elegant language" occasionally lead to
Style Wars and Deep Thoughts about what beauty and elegance really are.
These threads, although amusing at times, usually lead nowhere. My "most
elegant" language will probably not be yours.

Regards,
-Rijn

-- 

.______________.----------------------------+
|              |  CMG Den Haag BV (NL)      |
| Rijn W. Buve |  Div. Advanced Technology  |
|______________|  E-mail: ·········@cmg.nl  |
 | Any views expressed here are my own and  |
 | not represent my employers or customers  |
 +------------------------------------------+
From: Bill Coderre
Subject: Stop it! (was Re: What is the most "Elegant" Language?)
Date: 
Message-ID: <bc-0210971711530001@17.127.18.199>
Why is there no Usenet newsgroup comp.lang.advocacy? If there were, we
could all avoid a whole lot of noisy, repetitious BS.

I mean, what else can you call a thread like this? You certainly are not
going to change anyone's mind about Lisp or C, and you haven't even
bothered to include the Java and Ada and Modula-3 and PERL people at all.

There are only two reasons I can see for starting such a loaded thread:
1) You want a stick to beat up people who prefer a different language.
2) You want to reassure yourself that you are better than those other guys.

If the reason is 1, then you should find a better stick. For instance, the
C people have pretty effectively quoted program size and speed at the Lisp
people for, oh, a decade or so now. And the Lisp people have often quoted
lack of features and power at the C people for at least as long. 

Or you could go read "Expert C programming: Deep C Secrets" by Peter van
der Linden, which details some really NASTY C behaviors that all C
programmers should be aware of. (Besides which, it has lots of funny
stories and is utterly engrossing to read.)

Both of those sticks are much more effective, because they are not based
on terms that can only be spoken of in "quotation marks." You can
objectively, factually, proveably say, "Gee, your programming language has
these major problems. Ha ha, you suck."

If the reason is 2, you should go learn some self-esteem. After all, you
are not to be entirely judged by your programming language. It's quite
possible to write icky programs in any language, and good programs in
most.

I use Lisp, C, C++, and shell scripting every day.

I've shipped code, written while in the employ of a Major Computer Company
With A Three-Letter Acronym Name, written in BASIC. It went fast enough,
and was much shorter and much less bug-prone than the equivalent in C.
Took a lot less time to design, write, and debug, too. I'd say it was
well-designed, but it was so short that there wasn't really anything TO
design.

I've made astonishing amounts of money writing Hypertalk. My code was done
so quickly that we used it to debug the "real" client and server code
written in the "real" languages. (And of course, it was just as "elegantly
written" as anything else. Had all those fancy buzzwords like OO and data
structures and whatnot.)

And of course, like everyone else, I've written some truly shameful shell
scripts, the kind of stuff that no one should look at.

But just because I happen to prefer writing in one particular language
doesn't mean I'm a bad person. But try telling that to some programmers --
they'll shoot you for having a different INDENTATION STYLE. Sheesh.

bc
From: Martin Rodgers
Subject: Re: Stop it! (was Re: What is the most "Elegant" Language?)
Date: 
Message-ID: <MPG.e9eb3c753a0ea59989ac2@news.demon.co.uk>
Bill Coderre wheezed these wise words:

> There are only two reasons I can see for starting such a loaded thread:
> 1) You want a stick to beat up people who prefer a different language.
> 2) You want to reassure yourself that you are better than those other guys.

Wise words indeed. I've only one thing to add, as I agree so much with 
what you've said. I don't know who said this, but it goes something 
like this: "There are only two things wrong with the human race. Our 
intelligence and our need to organise ourselves into heirarchies."

I'll get my coat.
-- 
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
              Please note: my email address is gubbish
                         assert(got(coat)).
From: Charles Fiterman
Subject: Re: Stop it! (was Re: What is the most "Elegant" Language?)
Date: 
Message-ID: <34351B3F.4E4C@geodesic.com>
Bill Coderre wrote:
> 
> Why is there no Usenet newsgroup comp.lang.advocacy? If there were, we
> could all avoid a whole lot of noisy, repetitious BS.
> 
> I mean, what else can you call a thread like this? You certainly are not
> going to change anyone's mind about Lisp or C, and you haven't even
> bothered to include the Java and Ada and Modula-3 and PERL people at all.
> 
> There are only two reasons I can see for starting such a loaded thread:
> 1) You want a stick to beat up people who prefer a different language.
> 2) You want to reassure yourself that you are better than those other guys.

I've been reading this and find it usefull as I'm a language designer
who wants to know how people feel about various features. People flame
about things they feel strongly about. You may think that means
disinformation
but I think the opposite. People will buy things they feel strongly
about.
From: Martin Rodgers
Subject: Re: Stop it! (was Re: What is the most "Elegant" Language?)
Date: 
Message-ID: <MPG.e9ff2803028dc6f989ac7@news.demon.co.uk>
Charles Fiterman wheezed these wise words:

> I've been reading this and find it usefull as I'm a language designer
> who wants to know how people feel about various features. People flame
> about things they feel strongly about. You may think that means
> disinformation
> but I think the opposite. People will buy things they feel strongly
> about.

Then why isn't there are a comp.lang.advocacy newsgroup, so that the 
rest of us don't need to read this crap? I don't mind opinions, and I 
don't mind people expressing their peeves, but I _do_ object when such 
things are presented as "facts".

All too often, it's just wishful thinking. Consider the Peaceman 
thread. What value to you are the "arguments" (more like trolling) of 
someone who failed CS and who then tries to argue that the language 
used to teach CS, which he totally failed to understand? For several 
weeks, we refuted his every statement, until he finally gave up. What 
did he acheive, apart from dumping on the language which he blames for 
is failure? It's possible that he just had a poor teacher.

In case anyone missed it, I've archived the thread at:
<URL:http://www.wildcard.demon.co.uk/archives/slow.ZIP>

We really need a comp.lang.advocacy newsgroup.
-- 
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
              Please note: my email address is gubbish
                         assert(got(coat)).
From: Torkel Franzen
Subject: Re: Stop it! (was Re: What is the most "Elegant" Language?)
Date: 
Message-ID: <TORKEL.97Oct3083821@theseus.sics.se>
In article <···················@17.127.18.199> ··@wetware.com (Bill Coderre) writes:

   >Why is there no Usenet newsgroup comp.lang.advocacy? If there were, we
   >could all avoid a whole lot of noisy, repetitious BS.

  Nah. It's a lot more fun to pollute comp.lang.* with questions of
this sort. People fall for it every time.
From: Dale Gerdemann
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <34265D9C.47CA@sfs.nphil.uni-tuebingen.de>
Tom I Helbekkmo wrote:
> ...
>
> Of course there are elegant programming languages.  I don't think you
> can name a "most elegant" one, though -- the intended problem domain
> has to be a part of the evaluation.  Scheme is elegant, and so is APL,
> but for different reasons.
> 
I certainly agree that Scheme is elegant, but on the other hand, I've
seen some pretty ugly code written in it. Part of the problem is the
idea of "functions as first class citizens". If this is used too much,
then functions will be passed around in all different directions. It's
like a bunch of spagetti to trace backwards and find where all the
functions come from.

One thing that definitely does make Scheme elegant is the fact that
there is a very elegant book that's been written about the language.
Perhaps it's a more reasonable question to ask: for language X what
is the most elegant introductory book that's been written for that
language. I'll take the first crack at it and say that C is a very
elegant language, at least when it's presented by Eric Roberts in 
"The Art and Science of C". I'm really looking forward to seeing the 
new second volume of this book.

Dale Gerdemann
From: Mike Powers
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <3426AA64.1982@tad-centre.co.uk>
Dale Gerdemann wrote:
> 
> Tom I Helbekkmo wrote:
> > ...
> >
> > Of course there are elegant programming languages.  I don't think you
> > can name a "most elegant" one, though -- the intended problem domain
> > has to be a part of the evaluation.  Scheme is elegant, and so is APL,
> > but for different reasons.
> >
<snip functional language bit>

> Dale Gerdemann

Functional languages make my head hurt...

Well, one of my hobbies is collecting old, unsupported languages that
have no third-party developer tools and basically leave you stranded
with a text editor and a command line compiler as your development
environment. Which, of course, is my idea of heaven. Anyhow, on my
travels I've seen a couple of languages that struck me as being
'elegant', the first of which is TCL (Tool Command Language) which I've
seen on Acorn RISCOS and Unix X-Windows. It's a scripting language that
lets you do all sorts of windowing type stuff without doing all the
housekeeping that goes with it. It also has a really nice viewer for
troff-style documentation. A noughts-and-crosses game can be done in as
little as 50 lines of code.

The other 'elegant' language was a little one called Icon, which is a
cross (I suppose) between C and Pascal, but is neither. Its forte is
string handling, and its nice dynamic memory allocation means that all
the lurking horrors of pascal are gone. It's pretty loosely typed, so
you have to be careful.

On a slightly different note - is there still anyone out there who
thinks that Pascal is actually any good? I had a play with Delphi (I do
a lot of VC++ coding and wanted something to make life easier) and was
so disappointed it was based on pascal. Ah well. 

Peter.
From: ·······@bottom.of.message
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <607066$8p3@falcon.ccs.uwo.ca>
In article <··············@athene.nhh.no>, Tom I Helbekkmo  <···@nhh.no> wrote:
>Damn -- I can't remember their name.  It's an American company, and
>the hammer I'm thinking of has a beautiful, warm golden brown handle
>and a delicious sheen to the metal.  The head is not all that special;
>it's just clean and functional, but that's part of the beauty of it.

<homer>
     Mmmm, hammers.
</homer>

     But seriously, please take this out of comp.lang.prolog at
least... discussions like this come around at least twice a year.

--Jamie.
` andrews at csd.uwo.ca
From: Martin Rodgers
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <MPG.e9aba74498a8bba989ab6@news.demon.co.uk>
Alicia Carla Longstreet wheezed these wise words:

> C is a wonderful langauge.

It's a wonderful "assembly language". Look at all the compilers that 
produce C code. Even cfront. It's a very old idea, predating C. There 
are compilers that produce Fortran code, too.

If you look hard, you can still find people advocating the use of 
assembly language. Perhaps they mean assembly language is great for 
writing things like MPEG drivers. Not all of us write MPEG drivers, 
nor do all of us need that kind of control over the hardware. For most 
software, it would be highly inappropriate.

At some point in a discussion like this someone will say, "If your 
only tool is a hammer, everything looks like a nail." Perhaps someone 
else said, and I missed it. Anyway, I said it anyway. All the 
arguments I've seen for low level languages, like C, also work for 
assembly language. Let's balance them with a few arguments for high 
level languages, too. 20 years ago, C may have looked "high level", 
but it's looking rather different today, even to the marketing droids 
to define reality for many people.

Not that any of this matters. Ever since I started using computers, in 
the early 80s, I've seen people making arbitrary choices and then 
rationalising their choices. Eg, buying a first machine, discovering 
that the CPU is a 6502 (early 80s, remember), and then deciding that 
this is the most elegant CPU in the world. Maybe some people have had 
the same experience with programming languages?

Martketing may be playing a part in this. Ego, too. The former tells 
you what to use, while the latter says that _you_ can't be wrong. The 
result is a curious breed of fanatics that insist on telling us all 
what a great language C++ is. Even more strange, they often do it by 
dumping on other languages, like Lisp!

Please note the followups. (I just wish there was a comp.lang.advocacy 
newsgroup, coz this is where this _really_ belongs.)
-- 
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
              Please note: my email address is gubbish
                         assert(got(coat)).
From: Tak To
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <34314DB8.3762@aspentech.com.->
Gavin E. Mendel-Gleason wrote:
 
> I fail to see how anyone can think that a language that has 15
> different levels of precedence and must be read in different
> direction for different operators in its syntax is elegant. ie:
> 
> char (*(*x[3])())[5]       (example from ANSI C the programming
> language)
> 
> read as:
> 
>  x: array[3] of pointer to function returning pointer to array[5]
>  of char.

I think you may have missed an important point here.  To wit,
C uses the _same_ operators and the _same_ precedence rules
for both procedural specification and data declaration.  Isn't
this more orthogonal than languages that use two completely
different sets of operators and precedence rules? 

As to elegance, some people do value orthognality more than
readability (which is a more subjective matter).

[Note1]  Well, some of the operators do not have same semantics
in the two domains.  For example, the operator "...[...]" indicates
indexing in a procedure, but size in a declaration.  Also,
counter part of the "." operator in a declaration is really the
"{...}..." operator.  However, all in all, it is quite orthogonal.

[Note2]  Question: syntactically, how does one classify the type
of operators such as "...[...]"?  Null infix + circumfix?  Infix +
postfix? 

> While this code is not that likely to occur, it does point out the
> problems with c's infix operators, wich can be both difficult to
> use, and hellish to debug.
           ^^^^^^^^^^^^^^^^

Which infix operators?  (Not "+", I hope.)  Than what?  Examples?

Tak

----------------------------------------------------------------------
Tak To                                                  (617) 949-1377
Aspen Technology, Inc                              Fax: (617) 949-1030
10 Canal Park, Cambridge, Ma 02141.             ······@aspentech.com.-
----------------------------------------------------------------------
Disclaimer: I do no speak for Aspen Technology. [taode takto ~{LU5B~}]
From: Gavin E. Mendel-Gleason
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <m2afgutqvn.fsf@mail.unm.edu>
>> While this code is not that likely to occur, it does point out the
>> problems with c's infix operators, wich can be both difficult to
>> use, and hellish to debug.
           ^^^^^^^^^^^^^^^^
>Which infix operators?  (Not "+", I hope.)  Than what?  Examples?

Yes!

x = f() + g();

Tell me what order is this being evaluated in???

If either f or g is destructive to a variable on which the other depends then
the outcome is implementation specific (ie. it might work 'til ported).


-- 
_____________________________________________________
Gavin E. Gleason      | "If you ain't busy bein' born,
·········@tvi.cc.nm.us| You's busy dien'." -somebody
_____________________________________________________
From: Kaz
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <60tcur$1pf$1@latte.cafe.net>
In article <··············@mail.unm.edu>,
Gavin E. Mendel-Gleason <········@tvi.cc.nm.us> wrote:
>>> While this code is not that likely to occur, it does point out the
>>> problems with c's infix operators, wich can be both difficult to
>>> use, and hellish to debug.
>           ^^^^^^^^^^^^^^^^
>>Which infix operators?  (Not "+", I hope.)  Than what?  Examples?
>
>Yes!
>
>x = f() + g();
>
>Tell me what order is this being evaluated in???

The order is unspecified. So what? It's not specified in mathematics either.
If you were asked to evaluate the sum of the two functions, you might
start with g, or you might start with f.

If you specified the evaluation order, you would seriously hamper a compiler's
freedom to optimize! Part of optimization involves finding a good evaluation
order. Sometimes this may even require that two subexpressions are evaluated
in an interleaved fashion.

>If either f or g is destructive to a variable on which the other depends then
>the outcome is implementation specific (ie. it might work 'til ported).

You deserve what you get for such sloppy engineering.
-- 
From: Daniel Neri
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <x8fg1ql2mqc.fsf@chagall.nada.kth.se>
···@latte.cafe.net (Kaz) writes:
> In article <··············@mail.unm.edu>,
> Gavin E. Mendel-Gleason <········@tvi.cc.nm.us> wrote:
> >x = f() + g();
> >
> >Tell me what order is this being evaluated in???
> 
> The order is unspecified. So what? It's not specified in mathematics either.
> If you were asked to evaluate the sum of the two functions, you might
> start with g, or you might start with f.

Yeah, right! But in mathematics there are no side effects, so the
order is not important. In C, the outcome could depend on the order of
evaluation.

This is why pure functional languages, such as Haskell, were invented.

/Daniel
-- 
Daniel Neri <·······@nada.kth.se> (8 bits, please)
Correspondence in swedish, english or french welcome
From: David Chase
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <3433B200.2F08@world.std.com>
Kaz wrote:

> The order is unspecified. So what? It's not specified in mathematics either.
> If you were asked to evaluate the sum of the two functions, you might
> start with g, or you might start with f.

> If you specified the evaluation order, you would seriously hamper a compiler's
> freedom to optimize!

Hey, have you got any references for that claim?  Can you name
any research, anywhere, showing that freedom of evaluation order
for function calls yields a significant performance benefit?
You must be really sure of yourself (worked on any optimizing
compilers lately?) or else you would not have used that exclamation
point.

I know of one such paper, for Scheme, but I don't know of any
similar result for any other language (and note that Scheme is
heavily loaded with things that look like "function calls", so
this freedom might be more meaningful there than in C or C++).

In the optimizing compilers that I have worked on or studied,
the front end picked the evaluation order for f()+g(), and
the optimizer took the order of function calls as being written
in stone.

Seems to me your claim is unsupported by any research.  Feel
free to cite references that prove me wrong.

-- 
David Chase, ·····@world.std.com
From: Ron Natalie
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <3433B848.49F2@sensor.com>
David Chase wrote:

> In the optimizing compilers that I have worked on or studied,
> the front end picked the evaluation order for f()+g(), and
> the optimizer took the order of function calls as being written
> in stone.

What kind of braindead compiler is this?  Even the pcc (not
the worlds model of efficiency) let the code generator decide
this.  While two simple void function calls returing int
are not likely to have a compilation issue, somethign complex
with accesses to memory certainly is.  On some compilers
diddling registers can be done free in between memory
loads, but an attempt to access the target of the load
will stall until the load completes.
From: David Chase
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <3434084E.74CB@world.std.com>
> David Chase wrote:
> > In the optimizing compilers that I have worked on or studied,
> > the front end picked the evaluation order for f()+g(), and
> > the optimizer took the order of function calls as being written
> > in stone.

Ron Natalie wrote:
> What kind of braindead compiler is this?

Sun's compilers, in the early 1990s, at least given
my understanding of the behavior of the "iropt" phase.
I think they're not the only compilers out there to work
this way; it would not surprise me in the least to find
that IBM's RISC compilers work like this, given the
papers I've seen on compiler design coming out of IBM.

  Front-end generates low-level intermediate code,
  optimizer manipulates LLIC.  Sequence point boundaries
  are often turned into slush.  One very good reason to
  not reorder function calls is that if the optimizer is
  allowed to make changes to (legal) program behavior,
  then determining and maintaining any confidence in the
  compiler's correctness over time is a a much harder
  task (life is much simpler if there is only one right
  answer).

Note that this was true during a period of time when the
quality of the code generated improved by perhaps 100%
(0.0 -> 1.0 was +20%, 1.0 -> 2.0.1 was +15%, 2.0.1 -> 3.0
was +something, 3.0 -> 4.0 was +some more, I think +60%
on floating point).

It's also not true if you turn on dependence-driven
transformations, but at the time that only made sense
for Fortran.  (Dependence-driven transforations might
autoparallelize a loop, which rather dramatically
reorders expression evaluation, and yields evaluation
orders not consistent with any serial execution of the
program.  Parallelization is typically inhibited by
calls to functions whose mathematical purity is not
known.)

Nobody has yet provided any evidence that this is, in
fact, "brain dead" for serial compilation of languages
like C.  I know of no reference to any paper measuring
an increase in performance provided by giving the optimizer
freedom to reorder function calls within an expression's
evaluation.  Sure, some compilers do it, but if anyone's
measured the improvement, they have not bothered to
publish their results.  We had this discussion on
comp.compilers about a year ago, the only paper that
anyone turned up was one for Scheme; none for C.  Note
that the depedence-driven transformation that allow
Fortran programs to be made so much faster are typically
not legal for C; they reorder execution (load and stores
and floating point arithmetic) across "sequence points"
(there is some hope for getting this right given
interprocedural analysis).

I think it is at least as braindead for a compiler
to gratuitously fiddle the semantics of the code from compile
to compile (i.e., based on unrelated changes) without
any evidence that this freedom to fiddle yields any
actual performance increase.  What is this, lucky-rabbits-
foot language and compiler design?  Consistent behavior
is braindead, superstitious behavior is not?

-- 
David Chase, ·····@world.std.com
From: Ron Natalie
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <34342BAA.6A1@sensor.com>
David Chase wrote:

> 
> Nobody has yet provided any evidence that this is, in
> fact, "brain dead" for serial compilation of languages
> like C.  I know of no reference to any paper measuring
> an increase in performance provided by giving the optimizer
> freedom to reorder function calls within an expression's
> evaluation. 

We sem to be arguing different points here.  Are you
saying that reordering expressions (forget function
calls for the time being) doesn't get you anything
performance wise?  This certainly is not true.
reordering

	double* x;
	double y, z;

	z = y + *++x;

will certainly give you better performance if you deref
x before you load y (on the i860 at least, last processor
besides the Pentium Pro I got down and dirty with).

If you're saying that optizimation accross function calls
isn't useful in C/C++, I probably would agree.  But if you
are going to say that the semantics of the language is
such that it's free to reorder the expression to achieve
what it needs.  You want funtion calls to be sequence
points?
From: Tyson Richard DOWD
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <6124pk$8pb@mulga.cs.mu.OZ.AU>
David Chase <·····@world.std.com> writes:

>Sun's compilers, in the early 1990s, at least given
>my understanding of the behavior of the "iropt" phase.
>I think they're not the only compilers out there to work
>this way; it would not surprise me in the least to find
>that IBM's RISC compilers work like this, given the
>papers I've seen on compiler design coming out of IBM.

>  Front-end generates low-level intermediate code,
>  optimizer manipulates LLIC.  Sequence point boundaries
>  are often turned into slush.  One very good reason to
>  not reorder function calls is that if the optimizer is
>  allowed to make changes to (legal) program behavior,
>  then determining and maintaining any confidence in the
>  compiler's correctness over time is a a much harder
>  task (life is much simpler if there is only one right
>  answer).

This is basically saying "don't reorder function calls because
it's too difficult to get right". With a language like C, that's
fair enough. Doesn't mean that it's not a good idea if you _can_
get it right.

>[deletia]

>I think it is at least as braindead for a compiler
>to gratuitously fiddle the semantics of the code from compile
>to compile (i.e., based on unrelated changes) without
>any evidence that this freedom to fiddle yields any
>actual performance increase.  What is this, lucky-rabbits-
>foot language and compiler design?  Consistent behavior
     ^^^^^^^^^^
You aren't talking about language design, you're talking about
compiler design. You've already got a language in mind, it's C,
and it's absolutely horrible to optimize because you have no
idea what sort of side effects a function contains.

If you want to design a language that is very ameanable to
program transformations that have vast effects upon execution
behaviour, but no effect upon program semantics, you should look
at something a lot more pure than C.

If you're using compilers that change the program behaviour from
one run to the next, without the user intending this to happen, I'd be
very afraid.
From: Tyson Richard DOWD
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <61242k$894@mulga.cs.mu.OZ.AU>
David Chase <·····@world.std.com> writes:

>Kaz wrote:

>> The order is unspecified. So what? It's not specified in mathematics either.
>> If you were asked to evaluate the sum of the two functions, you might
>> start with g, or you might start with f.

>> If you specified the evaluation order, you would seriously hamper a compiler's
>> freedom to optimize!

>Hey, have you got any references for that claim?  Can you name
>any research, anywhere, showing that freedom of evaluation order
>for function calls yields a significant performance benefit?

A large amount of automatic parallelization research relies upon this.
If f() and g() can be evaluated in any order, they can be evaluated
in parallel. If the language specifies the order, you have to work
a lot harder to show that it is still safe to do this optimization.
(In fact, you have to prove that order of evaluation is not important,
or your parallelization scheme has to somehow be arranged so that
it isn't important).

Also, optimizations where the necessity to evaluate f depends upon
the results of g can benefit immensely from the freedom to evaluated in
any order. Lazy languages take advantage of this, and don't evaluated
anything until it is needed. If execution order were specified,
they would be unable to do this -- laziness means that computation of
f and g can be interleaved. This can be very efficient, particularly if
the program doen't need all of the computation in f and g.

>You must be really sure of yourself (worked on any optimizing
>compilers lately?) or else you would not have used that exclamation
>point.

>I know of one such paper, for Scheme, but I don't know of any
>similar result for any other language (and note that Scheme is
>heavily loaded with things that look like "function calls", so
>this freedom might be more meaningful there than in C or C++).

In many languages that have built-in-search (or even just
boolean expressions), being able to reorder such expressions
allows you to move a commonly unsuccessful expression to the
start of a conjunction. (You could never do this sort of thing
in a language like C, where order-of-evaluation is strictly defined, 
and relied upon).

If your language supports tabling of evaluated calls, conjunctions
can be evaluated by first seeing whether any of the conjuncts is tabled,
and using the tabled result, then computing if necessary.

eg   f() && g()

becomes   if f and g are tabled    tabled(f) && tabled(g)
	  if f is tabled	   tabled(f) && calculated(g)
	  if g is tabled	   tabled(g) && calculated(f)
	  if neither is tabled	   calculated(f) && calculated(g)

This too, requires freedom to evaluate in any order.

>In the optimizing compilers that I have worked on or studied,
>the front end picked the evaluation order for f()+g(), and
>the optimizer took the order of function calls as being written
>in stone.

The Mercury compiler, a modern optimizing compiler, only sets the
evaluation order according to actual dataflow requirements (if g
needs a result from f, it needs to go after f).  Even this evaluation
order isn't necessarily written in stone, if one of the program
transformations or optimizations can do it's thing while retaining those
dataflow requirements, it would be allowed.

>Seems to me your claim is unsupported by any research.  Feel
>free to cite references that prove me wrong.

References, references, references... since when did people use
references on USENET? ;-)
From: Fergus Henderson
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <613ckv$37i@mulga.cs.mu.OZ.AU>
···@mundook.cs.mu.OZ.AU (Tyson Richard DOWD) writes:

>David Chase <·····@world.std.com> writes:
>
>>Kaz wrote:
>
>>> If you specified the evaluation order, you would seriously hamper a
>>> compiler's freedom to optimize!
>
>>Hey, have you got any references for that claim?  Can you name
>>any research, anywhere, showing that freedom of evaluation order
>>for function calls yields a significant performance benefit?
>
>A large amount of automatic parallelization research relies upon this.
[...]
>Also, optimizations where the necessity to evaluate f depends upon
>the results of g can benefit immensely from the freedom to evaluated in
>any order. Lazy languages take advantage of this, and don't evaluated
>anything until it is needed.
>
>In many languages that have built-in-search (or even just
>boolean expressions), being able to reorder such expressions
>allows you to move a commonly unsuccessful expression to the
>start of a conjunction.
>
>If your language supports tabling of evaluated calls, conjunctions
>can be evaluated by first seeing whether any of the conjuncts is tabled,
>and using the tabled result, then computing if necessary.

All true.

>>In the optimizing compilers that I have worked on or studied,
>>the front end picked the evaluation order for f()+g(), and
>>the optimizer took the order of function calls as being written
>>in stone.
>
>The Mercury compiler, a modern optimizing compiler, only sets the
>evaluation order according to actual dataflow requirements (if g
>needs a result from f, it needs to go after f).

Right, but it is the front-end that sets this evaluation order.
And the order that the front-end sets is the (unique) ordering
mandated by the "strict sequential" semantics.

>Even this evaluation
>order isn't necessarily written in stone, if one of the program
>transformations or optimizations can do it's thing while retaining those
>dataflow requirements, it would be allowed.

True.

But in practice, the Mercury compiler currently does not do any
reordering that would not be allowed under the strict sequential
semantics.

The Mercury compiler has a couple of `--no-reorder' options, but
currently none of the optimization phases of the Mercury check the
settings of those options, since the optimizations they perform do not
affect the ordering.  They sometimes reorder parts of the
computation, but only in ways that are guaranteed not to affect
the semantics.

So the Mercury compiler is not a counter-example to David Chase's claim,
at least not yet.

--
Fergus Henderson <···@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 ···@128.250.37.3         |     -- the last words of T. S. Garp.
From: Tyson Richard DOWD
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <619b4g$gm0@mulga.cs.mu.OZ.AU>
···@mundook.cs.mu.OZ.AU (Fergus Henderson) writes:

>···@mundook.cs.mu.OZ.AU (Tyson Richard DOWD) writes:

>>>In the optimizing compilers that I have worked on or studied,
>>>the front end picked the evaluation order for f()+g(), and
>>>the optimizer took the order of function calls as being written
>>>in stone.
>>
>>The Mercury compiler, a modern optimizing compiler, only sets the
>>evaluation order according to actual dataflow requirements (if g
>>needs a result from f, it needs to go after f).

>Right, but it is the front-end that sets this evaluation order.
>And the order that the front-end sets is the (unique) ordering
>mandated by the "strict sequential" semantics.

>>Even this evaluation
>>order isn't necessarily written in stone, if one of the program
>>transformations or optimizations can do it's thing while retaining those
>>dataflow requirements, it would be allowed.

>True.

>But in practice, the Mercury compiler currently does not do any
>reordering that would not be allowed under the strict sequential
>semantics.

>The Mercury compiler has a couple of `--no-reorder' options, but
>currently none of the optimization phases of the Mercury check the
>settings of those options, since the optimizations they perform do not
>affect the ordering.  They sometimes reorder parts of the
>computation, but only in ways that are guaranteed not to affect
>the semantics.

>So the Mercury compiler is not a counter-example to David Chase's claim,
>at least not yet.

Sorry, I didn't mean to give this impression, just to say that it
isn't "written in stone" the way it is with David's compiler.
From: Dennis Weldy
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <GQYIwynz8GA.125@news2.ingr.com>
 And if the ordering were specified, most likelyu you'd be here complaining
that they used an evaluation method which is not as efficient on your
specific architecture. 

It is rather nice of the language definition to explicitly state what is
implementation defined, so that the programmer is aware of these and can
avoid them. It's better than remaining silent on the issue, in which case
y'get bit with hidden "gotchas".

Besides, if either f(() or g() is destructive to a variable, this means
a) the programmer was clueless about what the functions do
b) the author of the functions did not document their behavior properly
c) use of globals (either static or not) may not be the best way to solve
the problem. Since f and g accept no parameters, the only shared variable
between them would be a global.
d) functions which cause side-effects like that are best avoided, IMHO.
Although sometimes necessary

If, for some reason the programmer MUST have an order of evaluation, then
{
    int t ;
    t = f() ;
    x = t + g() ;
}
or
{
     t = g() ;
    x = f() + t ;
}



Gavin E. Mendel-Gleason wrote in article ...

>>> While this code is not that likely to occur, it does point out the
>>> problems with c's infix operators, wich can be both difficult to
>>> use, and hellish to debug.
>           ^^^^^^^^^^^^^^^^
>>Which infix operators?  (Not "+", I hope.)  Than what?  Examples?
>
>Yes!
>
>x = f() + g();
>
>Tell me what order is this being evaluated in???
>
>If either f or g is destructive to a variable on which the other depends
then
>the outcome is implementation specific (ie. it might work 'til ported).
>
>
>-- 
>_____________________________________________________
>Gavin E. Gleason      | "If you ain't busy bein' born,
>·········@tvi.cc.nm.us| You's busy dien'." -somebody
>_____________________________________________________
>.
> 
From: Thant Tessman
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <3432B3DA.41C6@signature.below>
Dennis Weldy wrote:


[...about the unpredictable behavior of f() + g() if 'f' or 'g'
modify shared state, due to the fact that evaluation order is
implementation-dependent...]

> Besides, if either f(() or g() is destructive to a variable, 
> this means
>
> a) the programmer was clueless about what the functions do

Is this categorically a bad thing?  So what if 'g' triggers 
housework or optimizations on the assumption that 'f' has 
already been evaluated?  This work may genuinely be something 
the programmer shouldn't want to know anything about.

[...]

> d) functions which cause side-effects like that are best 
> avoided, IMHO.  Although sometimes necessaryIf, for some 
> reason the programmer MUST have an order of evaluation, 
> then 
>
> {
>     int t ;
>     t = f() ;
>     x = t + g() ;
> }
>
> [...]

I've read that Fortran's most important contribution to 
computer programming was that it automatically did the 
work of introducing temporary variables to hold the values
of subexpressions--a job previously and laboriously done 
by the programmer.  I guess there will always be some C 
programmers who lament for the good ol' days when 
programming was done by hand using traditional 
craftsmanship and only the finest raw ingredients.

Speaking of avoiding side effects, the mostly functional
programming language Standard ML defines an explicit order 
of evaluation.  But in SML imperative values are explicitly 
declared as such, so the compiler can know which expressions 
will have side-effects and which won't.  If the expressions 
don't have side-effects, the compiler is free to evaluate 
them in any order it wants.  This is the right answer.

(I think another right answer is monads, but I'm not sure yet.)

-thant

--
thant at acm dot org
From: John  Bayko
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <60ujcf$ioc$1@sue.cc.uregina.ca>
In article <·············@signature.below>,
    Thant Tessman  <·······@signature.below> wrote:
>Dennis Weldy wrote:
>
>[...about the unpredictable behavior of f() + g() if 'f' or 'g'
>modify shared state, due to the fact that evaluation order is
>implementation-dependent...]
>
>> Besides, if either f(() or g() is destructive to a variable, 
>> this means
>>
>> a) the programmer was clueless about what the functions do
>
>Is this categorically a bad thing?  So what if 'g' triggers 
>housework or optimizations on the assumption that 'f' has 
>already been evaluated?  This work may genuinely be something 
>the programmer shouldn't want to know anything about.

    This sounds like a really convoluted way of doing... well,
anything. If two functions *really* had to depend on each other like
that, the programmer would use a flag that one sets and the other
reads. I can't envision any such situation would occur which couldn't
be handled a lot better some other way.

>[...]
>> {
>>     int t ;
>>     t = f() ;
>>     x = t + g() ;
>> }
>> [...]
>
>I've read that Fortran's most important contribution to 
>computer programming was that it automatically did the 
>work of introducing temporary variables to hold the values
>of subexpressions[...] I guess there will always be some C 
>programmers who lament for the good ol' days when 
>programming was done by hand using traditional 
>craftsmanship and only the finest raw ingredients.

    Sigh.
{
    x = f();
    x += g();
}

>(I think another right answer is monads, but I'm not sure yet.)

    I don't think I've had monads. My brother had mumps once though.

--
John Bayko (Tau).
·····@cs.uregina.ca
http://www.cs.uregina.ca/~bayko
From: Gavin E. Mendel-Gleason
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <m2k9fxq9xm.fsf@mail.unm.edu>
>(I think another right answer is monads, but I'm not sure yet.)

Thats funny you should say that, I was just rereading the Monadology by 
Leibniz yesterday.  What does it mean in a programming context?

			Gavin E. Gleason
From: Thant Tessman
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <3433BBB6.41C6@signature.below>
[...followups redirected...again...]

John Bayko wrote:

>     This sounds like a really convoluted way of doing... 
> well, anything. If two functions *really* had to depend on 
> each other like that, the programmer would use a flag that 
> one sets and the other reads. I can't envision any such 
> situation would occur which couldn't be handled a lot better 
> some other way.

Since I'm reading this from comp.lang.scheme...

I've been playing with Elk.  Elk stands for Extension Language
Kit.  It's a marvelous way to add a Scheme interpreter to your
C or C++ application.

  http://www-rn.informatik.uni-bremen.de/software/elk/elk.html

One of the nice things about it is that you can call Scheme
primitives directly from C.  The danger is that some Scheme
primitives may trigger garbage collections.  There are many 
subtle ways to hurt yourself involving things being in 
registers and not properly guarded on the stack when a 
garbage collection happens.  The problem is exacerbated by 
the fact that the order of evaluation is undefined in C.  So 
something that works on one machine might break on another.

The only better way I can see to deal with this problem is
not to deal with C, but I currently don't have much of
a choice in the matter.

>    Sigh.
> {
>     x = f();
>     x += g();
> }

Oh yeah, MUCH better.

-thant

--
thant at acm dot org
From: William Clodius
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <3432E392.41C6@lanl.gov>
Thant Tessman wrote:
> <snip>
> 
> > d) functions which cause side-effects like that are best
> > avoided, IMHO.  Although sometimes necessaryIf, for some
> > reason the programmer MUST have an order of evaluation,
> > then
> >
> > {
> >     int t ;
> >     t = f() ;
> >     x = t + g() ;
> > }
> >
> > [...]
> 
> I've read that Fortran's most important contribution to
> computer programming was that it automatically did the
> work of introducing temporary variables to hold the values
> of subexpressions--a job previously and laboriously done
> by the programmer.  I guess there will always be some C
> programmers who lament for the good ol' days when
> programming was done by hand using traditional
> craftsmanship and only the finest raw ingredients.
> <snip>

Actually in this case Fortran is more convoluted than C. If the
execution of f can have side effects that must not be optimized away it
should be made into a SUBROUTINE, i.e., a Fortran programmer should
write

INTEGER :: t, x
CALL f(t)
x = t + g()

Ideally the point at which all significant side effects in the code can
occur should be explicit. Side effects that only change the efficiency
of the calculation (i.e., caching previously calculated results as
starting points for searches, reading a file the first time the function
is called to create a table of data) are allowed. Unfortunately the set
of all side effects that can be optimized away is a superset of the set
of all side effects that will be optimized away and many users write
code according to what they believe they can get away with. Of course
the set of all side effects that will be optimized away varies from
processor to processor so such users are often eventually burned.

The main contributions of IBM's FORTRAN I/II was to show that a compiler
for a higher level language could approach the efficiency of an
assembler with high portability almost instantly making higher level
languages widely popular. However, the optimizations it used to make
this possible were soon forgotten for 10+ years because of their
detrimental effect on the compile/run/debug cycle.

-- 

William B. Clodius		Phone: (505)-665-9370
Los Alamos Nat. Lab., NIS-2     FAX: (505)-667-3815
PO Box 1663, MS-C323    	Group office: (505)-667-5776
Los Alamos, NM 87545            Email: ········@lanl.gov
From: Mark Wilden
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <34315BE8.7B9D@mWilden.com>
Tak To wrote:
> 
> To wit,
> C uses the _same_ operators and the _same_ precedence rules
> for both procedural specification and data declaration.  Isn't
> this more orthogonal than languages that use two completely
> different sets of operators and precedence rules?

The latter would be more orthogonal. Orthogonal doesn't mean
"consistent," it means "independent."
From: Tak To
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <3433DB07.6764@aspentech.com.->
Mark Wilden wrote:
> 
> Tak To wrote:
> >
> > To wit,
> > C uses the _same_ operators and the _same_ precedence rules
> > for both procedural specification and data declaration.  Isn't
> > this more orthogonal than languages that use two completely
> > different sets of operators and precedence rules?
> 
> The latter would be more orthogonal. Orthogonal doesn't mean
> "consistent," it means "independent."

Is that a facetious statement?  If not, pardon me for asking and
let me spell it out.

First of all, consistence is a necessary part of orthogonality.
If a feature F _cannot_ be used in the same fashion in situations
X and Y, then F is _not_ independent of X and Y.

For example, if a language has two operators for addition: "+" for
integers and "plus" for floating points, then the syntax for
expressing an addition operation is dependent on the type of
the operands.  To wit, "syntax for addition" is _not_ orthogonal to
"type of operand".  On the other hand, if there is only one operator,
then "syntax for addition" is orthogonal to "type of operand".

Also take the most often cited case of Fortran's interative DO
statement, in which one cannot use an arbitary expression to
indicate the boundary value of loop variant.  One must instead use
an expression consisting of a single variable.  Do you agree that
this is an example of low orthogonality?  (I.e., "how to express
a value" is not orthogonal to "how the value is used".)

Back to the original case.  I contend that in C, "how to express
component relationship" is orthogonal to "where this relationship
is used (in procedural specification or data declaration)".

I was not saying that this meant elegance; I was merely saying that
a lot of people missed this point entirely.

[Note] One may argue that procedural specification and data
  declaration are two completely different domains and that
  strictly speaking, there is no such "common feature" as
  "component relationship".  I agree that the semantics do not
  match exactly.  (E.g., the "...[...]" operator indicates indexing
  in procedural specification and size in data declaration.)
  However, there is substantial overlap on both sides (e.g.,
  deferencing and function invocation are common to both) and
  by and large one can make a good case that it is a single
  feature.

Tak
----------------------------------------------------------------------
Tak To                                                  (617) 949-1377
Aspen Technology, Inc                              Fax: (617) 949-1030
10 Canal Park, Cambridge, Ma 02141.             ······@aspentech.com.-
----------------------------------------------------------------------
Disclaimer: I do no speak for Aspen Technology. [taode takto ~{LU5B~}]
From: Richard A. O'Keefe
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <611o44$72e$1@goanna.cs.rmit.edu.au>
Tak To <······@aspentech.com.-> writes:
>Also take the most often cited case of Fortran's interative DO
>statement, in which one cannot use an arbitary expression to
>indicate the boundary value of loop variant.  One must instead use
>an expression consisting of a single variable.

There is no such restriction in the current Fortran standard,
in the standard before that, or the standard before _that_.
Sounds like you're about 20 years out of date on Fortran.

>Back to the original case.  I contend that in C, "how to express
>component relationship" is orthogonal to "where this relationship
>is used (in procedural specification or data declaration)".

Untrue.  Take a look at structs some time.
The _use_ of a struct field is
	variable.Field
The _declaration_ of a field is
	struct ... { ...; Type Field; ... }

>I was not saying that this meant elegance; I was merely saying that
>a lot of people missed this point entirely.

Sounds like you may have missed the paper by Sethi about this.

Now Algol 68, _the_ language most noteworthy for having been designed
with 'orthogonality' as a guiding principle, indeed, for introducing
the term into common use, does _not_ have any such parallel between
declarations and (a very limited subset of) uses.  It is a pity that
C copied Algol 68's worst mistakes (this whole long/short business)
and managed to avoid most of its virtues.  (There's a book with a
title something like 'Mes Premiers Pas en Programmation' which uses
Algol 68 as the introductory language.  It gets nearly a third of the
way through the book, having introduced arithmetic, ifs, cases, structs,
functions, &c, before it mentions assignment.  Lovely.)

-- 
John �neas Byron O'Keefe; 1921/02/04-1997/09/27; TLG,TLTA,BBTNOTL.
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.
From: Naoyuki Tai
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <naoyuki_tai-ya02408000R3009971157240001@news.avid.com>
In article <············@nntp.Stanford.EDU>, ······@wishbone.stanford.edu
(Jeremy Brinkley) wrote:

> On Mon, 29 Sep 1997 16:19:02 -0400, Alicia Carla Longstreet
(·····@ici.net) put forth:
> > Thant Tessman wrote (edited):
> > > 
> 
> > > C's appeal is that it was part of the computer
> > > virus known as the UNIX operating system.
> 
> C appeals due to many things, among which are its close relationship
> with Unix, its simplicity, elegance and a number of other factors
> including:

 When you say C, you probably include C preprocessor which I
think very ugly language. Its confused language definition has
a lot to do with incompatible implementation of C preprocessors
especially recursive macro expansion. Also, such an incomplete 
definition left as is for years is the sure sign of unixism where
the elegance is neglected, attacked and discarded.

 Simplicity is not a synonim to elegance.
 Consistency and artful inconsistency is.
 
> -- 
>   Jeremy Brinkley                      ······@wishbone.stanford.edu
>   System Administrator                 finger for PGP key (2.6.2) or
>   Stanford Blood Center                http://wishbone.stanford.edu/~jeremy

-- ···········@avid.com
 I do not speak for Avid.
From: Kaz
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <60qe73$pu7$1@latte.cafe.net>
In article <·······································@news.avid.com>,
Naoyuki Tai <···········@avid.com> wrote:
> When you say C, you probably include C preprocessor which I
>think very ugly language. Its confused language definition has
>a lot to do with incompatible implementation of C preprocessors
>especially recursive macro expansion. Also, such an incomplete 
>definition left as is for years is the sure sign of unixism where
>the elegance is neglected, attacked and discarded.

That is nonsense. The ANSI/ISO C language standard provides a sound and
adequate requirement specification for what the preprocessing stage must do.
It is very precise in defining how repeated rescanning works and which
identifiers are eligible.

Deviations from these requirements are implementation bugs.  If you are going
to deride the C language for bugs in its implementations, why don't you also
balance your view by looking at bugs in the implementations of other
languages?
-- 
From: P Murray
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <60sf6a$iul$1@cdn-news.telecom.com.au>
Gavin E. Mendel-Gleason (········@tvi.cc.nm.us) wrote:

: I fail to see how anyone can think that a language that has 15
: different levels of precedence and must be read in different 
: direction for different operators in its syntax is elegant. ie:

: char (*(*x[3])())[5]       (example from ANSI C the programming language)

This just goes to show that with a bit of effort crap code
can be written in even the most elegant of languages!

: read as: 

:  x: array[3] of pointer to function returning pointer to array[5] of char.
From: Erik Westlin
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <3431F2FF.68F0@msi.se>
P Murray wrote:
> 
> Gavin E. Mendel-Gleason (········@tvi.cc.nm.us) wrote:
> 
> : char (*(*x[3])())[5]       (example from ANSI C the programming language)
> 
> This just goes to show that with a bit of effort crap code
> can be written in even the most elegant of languages!
> 
> : read as:
> 
> :  x: array[3] of pointer to function returning pointer to array[5] of char.

I once had the idea that it would be better if c had the following
syntax.

  char[5]()*[3] x;

but i don't suppose they will change it now ...

- Erik Westlin
From: James L. Preston
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <tusoukiea0.fsf@apti.com>
In article <············@cdn-news.telecom.com.au> ···@vus002.telecom.com.au (P Murray) writes:

>   Gavin E. Mendel-Gleason (········@tvi.cc.nm.us) wrote:
>
>   : I fail to see how anyone can think that a language that has 15
>   : different levels of precedence and must be read in different 
>   : direction for different operators in its syntax is elegant. ie:
>
>   : char (*(*x[3])())[5]       (example from ANSI C the programming language)
>
>   This just goes to show that with a bit of effort crap code
>   can be written in even the most elegant of languages!
>

Unfortunately, I cannot remember the source of this quote:

"There has never been a computer programming language invented in
which it is the least bit difficult to write bad programs."

(correct corrections welcome)
jlp
From: Chris Bitmead
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <m3lo0cttkd.fsf@thepla.net>
······@wishbone.stanford.edu (Jeremy Brinkley) writes:

> C is elegant because of its close and simple relationship to the first
> principles upon which computerized operations are based.  I'm not
> talking about bit operations here; I put forth the example of C's
> elegantly simple relationship with memory, that allows the elegant
> manipulation of complex and/or large data objects by manipulating
> pointers to those objects.

Dear me. C is NOT an elegant language. All you are saying here is that
the language exposes the memory architecture of common computers to
the programmer. While this tends to guarantee efficiency, it is
neither particularly helpful nor necessary for efficiency.

In any case there are far more simple memory models in other
programming languages, and there is far more to having a good language
than having a clear memory model. In fact that is the least of your
worries.

I was going to say that C was good at one time, but is now obsolete. I
can't even say that though because lisp preceded C by many years. And
while C is a passable portable assembly language, I would hardly call
it good in that either. For one thing it's not that portable, and for
another it isn't that good at representing all the things that a
processor can do. Just one example. If you've got a pointer to a
function that takes a variable number of arguments, you can't set up
an argument vector at runtime to pass to the function.

-- 
Chris Bitmead
http://www.thepla.net/~chrisb
From: Fred Gilham
Subject: Elegant solutions (was Re: What is the most "Elegant" Language?)
Date: 
Message-ID: <u7u3eyzsmh.fsf_-_@japonica.csl.sri.com>
I suppose an elegant language is one that permits you to arrive at
elegant solutions to a problem.

I've got an example that I think is interesting.

A while back Louis Howell posted a comparison of many free languages
that used the `count-change' problem from STRUCTURE AND INTERPRETATION
OF COMPUTER PROGRAMS.  He gave timings for versions of this program
ported to many different (free) programming languages.  (There's even
a version in INTERCAL!).  People interested in this can look at the
web page http://www.webcom.com/nazgul/change.html.

One comment he made was the following:


	A much more powerful optimization is to eliminate repeated
	evaluation of subproblems. The recursive strategy solves small
	problems (like changing 10 cents with only nickels and
	pennies) over and over many times. The only implementation
	that avoided the repeats was g++ solving a template
	metaprogram---that is why a compiler solving the problem as a
	side effect was able to beat optimized C code!


At first I was very impressed with this.  I was also probably a victim
of the fallacy that anything a bit arcane and difficult to understand
must be pretty good.  (The template metaprogram version IS both of
those.)

Then I realized that there's a standard Lisp technique called
memoization that can be applied to this problem.  There is an ftp site
with memoization code and papers describing the technique at
ftp.cs.umbc.edu:/pub/Memoization.

The interesting thing about this is that it's transparent.  Here's a
session (all this done on a Pentium Pro 200 running CMUCL under
FreeBSD:


* (load "change")
; Loading #p"/carnelian/homes/gilham/lisp/memoization/change.x86f".
T

< First do it without memoization.  Note that repeating the problem
doesn't effect the time. >

* (tim 500)
(59576 . 3.1)
* (tim 500)
(59576 . 3.1399999)

< Now memoize >

* (memo:memoize 'cc)
CC
* (tim 500)
(59576 . 0.01)
* (memo:memoized-function-call-count 'cc)
Function CC was invoked 1457 times. 
15% were memo table lookups, and 85% were calls to the original function.
(223 1234)
* (tim 700)
(207530 . 0.01)
* (memo:memoized-function-call-count 'cc)
Function CC was invoked 2042 times. 
15% were memo table lookups, and 85% were calls to the original function.
(316 1726)
* (tim 1000)
(801451 . 0.02)
* (memo:memoized-function-call-count 'cc)
Function CC was invoked 61314 times. 
16% were memo table lookups, and 84% were calls to the original function.
(9642 51672)
* (memo:clear-memo-table 'cc)
#<EQUAL hash table, 0 entries {9088925}>
* (tim 1200)
(1612925 . 0.03)
* (memo:memoized-function-call-count 'cc)
Function CC was invoked 64815 times. 
16% were memo table lookups, and 84% were calls to the original function.
(10187 54628)
* 

On the other hand, the C++ version creates problems because it
overruns the maximum template instantiation depth of the compiler.  (I
don't know if this problem is specific to g++ or to all C++
compilers.)  So you either have to patch the compiler or have it do
intermediate problems.  I.e. I did the following to the C++ program to
get it to do larger problems:


main()
{
  cout << cc<300,5>::retval << endl;
  cout << cc<600,5>::retval << endl;
  cout << cc<800,5>::retval << endl;
  cout << cc<1000,5>::retval << endl;
  cout << cc<1200,5>::retval << endl;
}

Timing for C++ version:

japonica:~/change > time ./change
9590
116727
343145
801451
1612925
0.000u 0.033s 0:00.02 150.0% 2+44k 0+0io 1pf+0w


Basically the same---but the C++ version is just printing out
pre-compiled results.

It's interesting to note that some optimizations --- tail-call
optimization, for instance :-) --- can make memoization fail because
the function call gets eliminated.  I used the default optimization
settings for the lisp compiler in the above.

The point is that the particular optimization discussed by Louis
Howell can be done very easily in Lisp but only with difficulty in
C++.  I'd say that, for this problem, Lisp is a more elegant language.


-- 
Fred Gilham                                       gilham @ csl . sri . com
King Christ, this world is all aleak, / And life preservers there are none,
And waves that only He may walk / Who dared to call Himself a man.
-- e. e. cummings, from Jehovah Buried, Satan Dead
From: Christopher Eltschka
Subject: Re: Elegant solutions (was Re: What is the most "Elegant" Language?)
Date: 
Message-ID: <3450A975.2D177127@physik.tu-muenchen.de>
Fred Gilham wrote:
> 
> I suppose an elegant language is one that permits you to arrive at
> elegant solutions to a problem.
> 
> I've got an example that I think is interesting.
> 
> A while back Louis Howell posted a comparison of many free languages
> that used the `count-change' problem from STRUCTURE AND INTERPRETATION
> OF COMPUTER PROGRAMS.  He gave timings for versions of this program
> ported to many different (free) programming languages.  (There's even
> a version in INTERCAL!).  People interested in this can look at the
> web page http://www.webcom.com/nazgul/change.html.
> 
> One comment he made was the following:
> 
>         A much more powerful optimization is to eliminate repeated
>         evaluation of subproblems. The recursive strategy solves small
>         problems (like changing 10 cents with only nickels and
>         pennies) over and over many times. The only implementation
>         that avoided the repeats was g++ solving a template
>         metaprogram---that is why a compiler solving the problem as a
>         side effect was able to beat optimized C code!
> 
> At first I was very impressed with this.  I was also probably a victim
> of the fallacy that anything a bit arcane and difficult to understand
> must be pretty good.  (The template metaprogram version IS both of
> those.)
> 
> Then I realized that there's a standard Lisp technique called
> memoization that can be applied to this problem.  There is an ftp site
> with memoization code and papers describing the technique at
> ftp.cs.umbc.edu:/pub/Memoization.
> 
> The interesting thing about this is that it's transparent.  Here's a
> session (all this done on a Pentium Pro 200 running CMUCL under
> FreeBSD:
> 
> * (load "change")
> ; Loading #p"/carnelian/homes/gilham/lisp/memoization/change.x86f".
> T
> 
> < First do it without memoization.  Note that repeating the problem
> doesn't effect the time. >
> 
> * (tim 500)
> (59576 . 3.1)
> * (tim 500)
> (59576 . 3.1399999)
> 
> < Now memoize >
> 
> * (memo:memoize 'cc)
> CC
> * (tim 500)
> (59576 . 0.01)
> * (memo:memoized-function-call-count 'cc)
> Function CC was invoked 1457 times.
> 15% were memo table lookups, and 85% were calls to the original function.
> (223 1234)
> * (tim 700)
> (207530 . 0.01)
> * (memo:memoized-function-call-count 'cc)
> Function CC was invoked 2042 times.
> 15% were memo table lookups, and 85% were calls to the original function.
> (316 1726)
> * (tim 1000)
> (801451 . 0.02)
> * (memo:memoized-function-call-count 'cc)
> Function CC was invoked 61314 times.
> 16% were memo table lookups, and 84% were calls to the original function.
> (9642 51672)
> * (memo:clear-memo-table 'cc)
> #<EQUAL hash table, 0 entries {9088925}>
> * (tim 1200)
> (1612925 . 0.03)
> * (memo:memoized-function-call-count 'cc)
> Function CC was invoked 64815 times.
> 16% were memo table lookups, and 84% were calls to the original function.
> (10187 54628)
> *
> 
> On the other hand, the C++ version creates problems because it
> overruns the maximum template instantiation depth of the compiler.  (I
> don't know if this problem is specific to g++ or to all C++
> compilers.)  So you either have to patch the compiler or have it do
> intermediate problems.  I.e. I did the following to the C++ program to
> get it to do larger problems:
> 
> main()
> {
>   cout << cc<300,5>::retval << endl;
>   cout << cc<600,5>::retval << endl;
>   cout << cc<800,5>::retval << endl;
>   cout << cc<1000,5>::retval << endl;
>   cout << cc<1200,5>::retval << endl;
> }
> 
> Timing for C++ version:
> 
> japonica:~/change > time ./change
> 9590
> 116727
> 343145
> 801451
> 1612925
> 0.000u 0.033s 0:00.02 150.0% 2+44k 0+0io 1pf+0w
> 
> Basically the same---but the C++ version is just printing out
> pre-compiled results.
> 
> It's interesting to note that some optimizations --- tail-call
> optimization, for instance :-) --- can make memoization fail because
> the function call gets eliminated.  I used the default optimization
> settings for the lisp compiler in the above.
> 
> The point is that the particular optimization discussed by Louis
> Howell can be done very easily in Lisp but only with difficulty in
> C++.  I'd say that, for this problem, Lisp is a more elegant language.

While I don't know what memoization is, from the above I conclude
that it is simply storing function arguments already calculated.
This is easy enough to do in C++:

#include <map>

struct pairless
{
  bool operator()(pair<int, int> x, pair<int, int> y)
  {
    return x.first<y.first || (x.first==y.first && x.second<y.second);
  }
};

int cc(int i, int j)
{
  typedef map<pair<int, int>, int, pairless> value_map;
  static value_map values;
  value_map::iterator iter=values.find(make_pair(x,y));
  if(iter!=values.end())
    return *iter.second;
  int retvalue=// however cc is calculated 
  values[make_pair(x,y)]=retvalue;
  return retvale;
}

BTW, it would also be possible to include this as optimization
into the compiler (so it would be completely transparent, except for
a way telling the compiler which functions to optimize).

In addition, if you want to save memory, you could (even more easyly)
set up an array where you store the values, reusing the place of the
oldest result when the list is full (this is useful if f.ex. you
know that the function will typically be called with the same
arguments as one of the latest calls). This also gives a speedup
for the single function call (no implicit memory management required,
especially no dynamic allocations needed), at the cost of potentially
lost hits for previously cached values now "expired".
From: David Hanley
Subject: Re: Elegant solutions (was Re: What is the most "Elegant" Language?)
Date: 
Message-ID: <34512D77.54C2944E@netright.com.delete.me.silly>
Christopher Eltschka wrote:


> While I don't know what memoization is, from the above I conclude
> that it is simply storing function arguments already calculated.

    More arracurately, it stores the results of a results of a
function'sinvocation in a table, in a transparent fashion.

[c implementation deleted]

    That would achieve a similar result, but I'm not sure if I'd
consider
it 'simple' or elegant.  It can be completely trnasparent in lisp.

> BTW, it would also be possible to include this as optimization
> into the compiler (so it would be completely transparent, except for
> a way telling the compiler which functions to optimize).

    True, but it would be a lot of work, and only possible in the
compiler.You can do it in lisp trivially.

    dave
From: Fred Gilham
Subject: Re: Elegant solutions (was Re: What is the most "Elegant" Language?)
Date: 
Message-ID: <u7wwj37yl7.fsf@japonica.csl.sri.com>
Christopher Eltschka wrote:
----------------------------------------
While I don't know what memoization is, from the above I conclude
that it is simply storing function arguments already calculated.
This is easy enough to do in C++:

#include <map>

struct pairless
{
  bool operator()(pair<int, int> x, pair<int, int> y)
  {
    return x.first<y.first || (x.first==y.first && x.second<y.second);
  }
};

int cc(int i, int j)
{
  typedef map<pair<int, int>, int, pairless> value_map;
  static value_map values;
  value_map::iterator iter=values.find(make_pair(x,y));
  if(iter!=values.end())
    return *iter.second;
  int retvalue=// however cc is calculated 
  values[make_pair(x,y)]=retvalue;
  return retvale;
}

BTW, it would also be possible to include this as optimization
into the compiler (so it would be completely transparent, except for
a way telling the compiler which functions to optimize).

In addition, if you want to save memory, you could (even more easyly)
set up an array where you store the values, reusing the place of the
oldest result when the list is full (this is useful if f.ex. you
know that the function will typically be called with the same
arguments as one of the latest calls). This also gives a speedup
for the single function call (no implicit memory management required,
especially no dynamic allocations needed), at the cost of potentially
lost hits for previously cached values now "expired".

----------------------------------------

All the above is true.  But my point was that the Lisp programmer
doesn't have to worry about any of the above, or modify the original
code at all.  Just invoke the memoization on whatever you've already
written for instant high-performance (assuming the problem is one that
does a lot of redundant computations).  You don't have to do anything
ad-hoc.

In other words, the flexibility of Lisp allows one to arive at a more
elegant solution to the problem of avoiding redundant computation than
(in my original example) template metaprogramming did, and (I'd argue)
the example above did.

(BTW, I'm informed that XSB Prolog has built-in memoization.)

-- 
Fred Gilham                                       gilham @ csl . sri . com
King Christ, this world is all aleak, / And life preservers there are none,
And waves that only He may walk / Who dared to call Himself a man.
-- e. e. cummings, from Jehovah Buried, Satan Dead
From: Kaz
Subject: Re: Elegant solutions (was Re: What is the most "Elegant" Language?)
Date: 
Message-ID: <62toei$q4s$1@latte.cafe.net>
In article <··············@japonica.csl.sri.com>,
Fred Gilham  <······@japonica.csl.sri.com> wrote:
>
>Christopher Eltschka wrote:
>----------------------------------------
>While I don't know what memoization is, from the above I conclude
>that it is simply storing function arguments already calculated.

Memoization means the caching of the results of a calculation so that if the
same operands appear again, the result is simply retrieved rather than
recalculated.
-- 
From: Robert White
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <343B0E6F.74FE4AB9@pobox.com>
Gavin E. Mendel-Gleason wrote:

> I fail to see how anyone can think that a language that has 15
> different levels of precedence and must be read in different
> direction for different operators in its syntax is elegant. ie:
>
> char (*(*x[3])())[5]       (example from ANSI C the programming language)
>
> read as:
>
>  x: array[3] of pointer to function returning pointer to array[5] of char.

And you don't consider that the ability to express a data construct so complex
(Which I dare you to express in another language 8-) in such a compact but
readable form is, in itself, a form of elegance?

It's like russian, if you don't speak or read it fluently it is all gibberish.

The choice of "x" as the variable name is a tad goche, but when you consider that
if you need that beasty a lot you can

typedef char (*(*x[3])())[5];
x Bob, Ted;

and when you are feeling wordy you can

typedef char ReturnType[5];
typedef ReturnType *CoreFunction();
typedef CoreFunction FunctionGroup[3];

FunctionGroup Bob;
FunctionGroup Ted;

and end up with the same program.

Both have their places and optimal usages and just because you *CAN* build the
body of a 1957 Chevy out of salami doesn't mean that you should consider it a
"good thing", it also does not a-priori melign Salami or an 1957 Chevy.

Give an elegant language to a buffoon and you will likely get buffoonery as a
result...

Rob.
From: pcm
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <01bcc5b2$e3c636c0$682d11cb@pc1>
Ron Natalie <···@sensor.com> wrote in article <·············@sensor.com>...
> pcm wrote:
> > 
> > Does anyone want to venture an opinion on what is the most elegant
> > programming language in the world today?
> > 
> "When I am working on a problem I never think about beauty. I only
>  think about how to solve the problem. But when I have finished,
>  if the solution is not beautiful, I know it is wrong."
> 
>       - Buckminster Fuller (1895-1983)

I was thinking more along the lines that there can be beauty in the process
of creation as well as in the solution.  I'm sure elegant (and relevant)
tools inspire the user to create elegant solutions.

- Peter.
From: Bryant Brandon
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <5816BDF4F1D92242.9D703F159EE7F22B.A8485259A53B7BEB@library-proxy.airnews.net>
In article <··························@pc1>, "pcm" <···@mira.net> wrote:

>Does anyone want to venture an opinion on what is the most elegant
>programming language in the world today?  
>
>And has there been any recent languages especially noted for their
>elegance?
>
>- Peter.

   Well, it depends on what you're doing.  By elegant, I mean "Most closely
matches my goal."  For example, I would use Fortran if I wnated to crunch a
million numbers through an algorithm.  I would use Mathematica for
symbolics.  I would use Lisp for a self-modifying or extremely flexible
program.  I would use C if I was doing very low-level stuff such as
communications among different languages.  I would use C++ for RAD or
experimentation, but it is flexible enough to creep into some of the other
fields.  On C++, I think of it as the Swiss Army Knife of programming
languages.  It can do almost everything, but you would be far better off
knowing how to use a few more specialized tools as well.

>(Personally, my vote would go for Scheme with the latest ANSII standard C++
>a close second, but I'm certainly open to suggestions)

B.B.
From: Jeffrey C. Dege
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <slrn6298o6.5r0.jdege@jdege.visi.com>
On 19 Sep 1997 20:49:56 GMT, "pcm" <···@mira.net> wrote:
>
>Does anyone want to venture an opinion on what is the most elegant
>programming language in the world today?  
>
>And has there been any recent languages especially noted for their
>elegance?

I've recently invented a language that appears to be simpler and more
expressive than any I've seen so far.  It contains no variables, no
functions, and only one statement: "do_what_i_want".  Every program,
no matter how complicated, when translated into my new language,
is represented by this one statement.

I've gone beyond this promising start to write a compiler that translates
the high-level source code into a platform-independent byte code.  Only
one byte-code is defined, 0x01, (usually referred to by its mnemonic,
DWIW).  Compiled programs are always exactly one byte long.

I've started designing a virtual machine that will execute the byte code
generated by this new language, but I haven't gotten very far.  Is anyone
willing to help?

-- 
From briefcase then there comes a list of things we must revise.
    And all but four within the room are taken by surprise.
And all but four are thinking of their last job with remorse:
    The customer, the manager, the doggy and the horse.
From: Erik Naggum
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <3083827834362239@naggum.no>
[somebody asks for the most elegant language]

* Jeffrey C. Dege
| I've recently invented a language that appears to be simpler and more
| expressive than any I've seen so far.  It contains no variables, no
| functions, and only one statement: "do_what_i_want".  Every program,
| no matter how complicated, when translated into my new language,
| is represented by this one statement.

you call _that_ elegant?  underline in the middle of variable names is
ugly, _real_ ugly.  `do-what-i-want' would be vastly more elegant.

#\Erik
-- 
see http://www.naggum.no/emacs/ for Emacs-20-related material.
From: James P. White
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <3424CDCE.A56DDF9@pagesmiths.com>
Jeffrey C. Dege wrote:
> 
> I've recently invented a language that appears to be simpler and more
> expressive than any I've seen so far.  It contains no variables, no
> functions, and only one statement: "do_what_i_want".  Every program,
> no matter how complicated, when translated into my new language,
> is represented by this one statement.
> 
> I've gone beyond this promising start to write a compiler that translates
> the high-level source code into a platform-independent byte code.  Only
> one byte-code is defined, 0x01, (usually referred to by its mnemonic,
> DWIW).  Compiled programs are always exactly one byte long.
> 
> I've started designing a virtual machine that will execute the byte code
> generated by this new language, but I haven't gotten very far.  Is anyone
> willing to help?

Well, I would, but my time is consumed implementing my *more* elegant
language which has as its single statement "do_it".  The benefits of its
more concise syntax and freedom from error in the programmers' wants are
obvious.  Runtime effeciency is vastly superior due to the use of a
single bit to encode the instruction.  Perhaps we will be able to
overcome that incompatibility and combine our efforts into a Universal
Virtual Machine.  Oh drat, I think that name is already trademarked...

jim
-----------------------------------------------------------------------
James P. White                        Netscape DevEdge Champion for IFC
Director of Technology Adventure Online Gaming http://www.gameworld.com
Developers of Gameworld -- Live Action Role-Playing and Strategic Games
···@aognet.net            Pagesmiths' home is http://www.pagesmiths.com
From: Constantine Antonovich:
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <34261D71.1F78@orbotech.co.il>
Jeffrey C. Dege wrote:
> 
> On 19 Sep 1997 20:49:56 GMT, "pcm" <···@mira.net> wrote:
> >
> >Does anyone want to venture an opinion on what is the most elegant
> >programming language in the world today?  
> >
> >And has there been any recent languages especially noted for their
> >elegance?
> 
> [skipped]

    In   my opinion, it's just   interesting that such an innocent
question can yield the enormous amount  of infuriated answers with
no variance: "shut up".
    In  the comp.lang.c++ newsgroup,  I have seen  a lot of stupid
questions which nevertheless  had been diligently discussed and no
one involved didn't seem  to be ashamed.  In the same newsgroup, I
have seen a lot of diligently answered questions regarding buttons
and windows in spite  of absolute absence  of such notions in  the
c++  language and  no one hadn't  been recommended  to  get out to
another groups. I guess the other groups are pretty same.
    Probably a   language  elegance is just   a  matter of  taste. 
Probably  the elegance  can  be  defined in  different terms   and
different ways.   Any  language  exists   not  only in   its   own
boundaries and  there  is  a lot  of   classic algorithms  so, for
example, a language can  be considered according to simplicity and
elegance of the  algorithms implementation.  For  another example,
the  STL idea even influenced the  c++ language (I believe to make
it more elegant).
    The question can be considered as very naive one. The question
can  be   considered   as  extremely  complicated   and   even too
complicated to be discussed in newsgroups. I would consider myself
as a person with not sufficient knowledge of different programming
languages to discuss their cross-elegance and so I can imagine the
question is  worth not to  be answered at all.  But THE ANSWERS... 
    Probably they demonstrates  the  today  world tendency   where
placement of a comma   in a program  is  much more important  than
reasons for the program to exists.   That just reminds  me the old
joke: what is better, a  sandwich or  eternal  bliss? Of course  a
sandwich. Because what can be  better than eternal bliss? Nothing. 
And sure a sandwich is better than nothing.

//------------------------------------------------------------------
// Opinions expressed here are my own only
//
// Constantine Antonovich,               Tel.  : ++972-8-942-3819
// software engineer,                    Fax   : ++972-8-942-3955
// Orbotech Ltd., P.O.Box 215,           Email: ·····@orbotech.co.il
// Yavne 81102, Israel
//------------------------------------------------------------------
From: Alicia Carla Longstreet
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <34266F50.412C@ici.net>
Constantine Antonovich: wrote:
> 
> Jeffrey C. Dege wrote:
> >
> > On 19 Sep 1997 20:49:56 GMT, "pcm" <···@mira.net> wrote:
> > >
> > >Does anyone want to venture an opinion on what is the most elegant
> > >programming language in the world today?
> > >
> > >And has there been any recent languages especially noted for their
> > >elegance?
> >
> > [skipped]
> 
>     In   my opinion, it's just   interesting that such an innocent
> question can yield the enormous amount  of infuriated answers with
> no variance: "shut up".
[snip]

About a year ago someone asked the question "What is the best language?"
the result was a months long argument with everybody vehemently putting
forth their personal opinion.  That discussion brought out some real nut
cases.

The problem here is, there just is no answer, it is purely a metter of
personal opinion.  Some people do get hot under the collar when their
opinion is challenged.  So, to avoid another 'best langauge' debacle a
lot of persons are saysin 'shut up'.

Note: many questions of this nature are just trolls.  The poster is
bored and wants to foment argument since this is more interesting to him
than the normal technical discussions and help responses that you
usually get.

-- 
************************************************
* Alicia Carla Longstreet     ·····@ici.net    *
*     Remove NO_SPAM when replying to me.      *
************************************************
My compassion for someone is not limited
to my estimate of their intelligence.
      Dr Gillian, Star Trek IV, The Voyage Home
************************************************
My opinion is a view I hold until - well - until
I find out something that changes it.
                                Luigi Pirandello
From: Les Carter
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <605l7q$cgo38@netserv.tnt.co.uk>
 Anyone will agree that 'ML' is the most elegant langauge :))

Jeffrey C. Dege wrote in article ...

>On 19 Sep 1997 20:49:56 GMT, "pcm" <···@mira.net> wrote:
>>
>>Does anyone want to venture an opinion on what is the most elegant
>>programming language in the world today?
>>
>>And has there been any recent languages especially noted for their
>>elegance?
>
>I've recently invented a language that appears to be simpler and more
>expressive than any I've seen so far.  It contains no variables, no
>functions, and only one statement: "do_what_i_want".  Every program,
>no matter how complicated, when translated into my new language,
>is represented by this one statement.
>
>I've gone beyond this promising start to write a compiler that translates
>the high-level source code into a platform-independent byte code.  Only
>one byte-code is defined, 0x01, (usually referred to by its mnemonic,
>DWIW).  Compiled programs are always exactly one byte long.
>
>I've started designing a virtual machine that will execute the byte code
>generated by this new language, but I haven't gotten very far.  Is anyone
>willing to help?
>
>--
>From briefcase then there comes a list of things we must revise.
>    And all but four within the room are taken by surprise.
>And all but four are thinking of their last job with remorse:
>    The customer, the manager, the doggy and the horse.
>
From: Christopher Eltschka
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <3450AD36.62776D78@physik.tu-muenchen.de>
Les Carter wrote:
> 
>  Anyone will agree that 'ML' is the most elegant langauge :))

No - the most elegant language is TeX - do you know another language
that does not only allow you to calculate the first n primes,
but in addition allows you to typeset the results in a pretty way
from the same program, without much extra efford?
From: Marco Schramp
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <01bce0a9$af8ab810$daac2ac0@pub00005m>
-- 

Christopher Eltschka <········@physik.tu-muenchen.de> wrote in article
<·················@physik.tu-muenchen.de>...
> Les Carter wrote:
> > 
> >  Anyone will agree that 'ML' is the most elegant langauge :))
> 
> No - the most elegant language is TeX - do you know another language
> that does not only allow you to calculate the first n primes,
> but in addition allows you to typeset the results in a pretty way
> from the same program, without much extra efford?
> 
Yes, Postscript.

Marco.
---------------------
Swearing is the only language spoken proficiently by programmers.
From: Kaz
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <62toac$q3h$1@latte.cafe.net>
In article <··························@pub00005m>,
Marco Schramp <·····@ittpub.nl> wrote:
>
>-- 
>
>Christopher Eltschka <········@physik.tu-muenchen.de> wrote in article
><·················@physik.tu-muenchen.de>...
>> Les Carter wrote:
>> > 
>> >  Anyone will agree that 'ML' is the most elegant langauge :))
>> 
>> No - the most elegant language is TeX - do you know another language
>> that does not only allow you to calculate the first n primes,
>> but in addition allows you to typeset the results in a pretty way
>> from the same program, without much extra efford?
>> 
>Yes, Postscript.

Nice joke. But Postscript is a graphics language, not a typesetting language.

Simple, naive typesetting with Postcript looks like trash.

How do you justify a paragraph in Postscript? How does it handle hyphenation?
What about complex tables? Mathematics formulas?  He did say ``without much
extra effort''. Have you ever looked at the postscript code generated from a
TeX .dvi file? It's write- and execute-only.  Do you actually know anyone who
writes papers using pure PostScript?

How about graphics? PostScript just gives you the primitive operations and a
programming language. But these primitives are not good tools for someone who
wants to create complex diagrams.  For example, suppose you want to draw two
disjoint ciricles, and want to connect them with two lines to suggest that
they are flanges connected by a machine belt. With PostScript, you have to
write a routine to solve for the tangent lines. In a more general figure
drawing language, you would just express the concept and have a built-in
solver figure out how to draw it.

Then you would have the result thunked into PostScript for printing.
-- 
From: lex
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <345EEF03.44C4@natlab.research.philips.com>
OK, I can't resist posting....

Of course, the most "Elegant" Language is "Elegant"!

"Elegant" started as a compiler generator based on attributed grammars
(it stands for Exploiting Lazy Evaluation for the Grammar Attributes
of Non-Terminals) and has grown into a full programming language.
It has been inspired by the abstraction mechanisms found in modern
functional languages, yet Elegant is an imperative langage (you have
assignment).
It is written in Elegant (beware of any language implementation not
written in that same language!)
It has been used for internal use within Philips for about 10 years
now. As we stopped the Elegant development, we will be making it
public domain shortly (I have to do this in my spare cycles, so 
the progress is somewhat slow).

Features

- Subtyping (linear inheritance)
- Polymorphic types
- Polymorphic functions
- Lazy types
- List comprehensions (but the work for many other types as well, 
  including your own)
- Overloading
- Automatic and user definable coercions
- Pattern matching (= sub-type analysis)
- User definable and overloadable operators
- Function (lambda) expressions
- Attribute grammars as part of the language
  Production rules need not parse, but can compute attributes over
  recursive datastructures
- Supports LL(1) and LALR(1) parsing
- Integrating automatic error recovery
- Module system
- Strong typing
- Lots of compile time and run-type checks
- Compiles onto ANSI C
- Interface to C
- Available on SunOS4,5 HP_UX 10, Linux, IRIX, DOS/Windows
- Portable to anything with a descent ANSI C compiler
- Self generating, i.e. written in Elegant (of course!)

- Additional tools for 
  - Lexical scanner generation
  - Bnf syntax diagrams generation
  - Bnf to attribute grammar conversion
  - Elegant makefile generation
  - C makefile generation

Curious? Watch these newsgroup for the announcement of this real 
"Elegant" compiler and additional tools!

Lex Augusteijn

Name: 		dr.ir. Lex Augusteijn
Address:	WL 1.1.13
		Philips Research Laboratories
		Prof. Holstlaan 4
		5656 AA Eindhoven
                The Netherlands
Phone:		(+31 40 27)43938
Fax:		(+31 40 27)44004
E-Mail:		···@natlab.research.philips.com
From: Richard Katz
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <34281E08.135C@nospam.juts.ccc.amdahl.com>
Jeffrey C. Dege wrote:
> 
> On 19 Sep 1997 20:49:56 GMT, "pcm" <···@mira.net> wrote:
> >
> >Does anyone want to venture an opinion on what is the most elegant
> >programming language in the world today?
> >
> >And has there been any recent languages especially noted for their
> >elegance?
> 
> I've recently invented a language that appears to be simpler and more
> expressive than any I've seen so far.  It contains no variables, no
> functions, and only one statement: "do_what_i_want".  Every program,
> no matter how complicated, when translated into my new language,
> is represented by this one statement.
> 
> I've gone beyond this promising start to write a compiler that translates
> the high-level source code into a platform-independent byte code.  Only
> one byte-code is defined, 0x01, (usually referred to by its mnemonic,
> DWIW).  Compiled programs are always exactly one byte long.
> 
> I've started designing a virtual machine that will execute the byte code
> generated by this new language, but I haven't gotten very far.  Is anyone
> willing to help?
> 
> --
> From briefcase then there comes a list of things we must revise.
>     And all but four within the room are taken by surprise.
> And all but four are thinking of their last job with remorse:
>     The customer, the manager, the doggy and the horse.


You're in luck.  A bug-free version of this language was created by one
William Ramage during the mid-1970s.  It's only statement is:

       do_what_i_meant

Even now we're still trying to install the exception handler which
calls:

      do_what_i_forgot



Richard Katz
From: Joel Dinolt
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <34285FB4.349B@pacbell.net>
Richard Katz wrote:
> 
> Jeffrey C. Dege wrote:

> You're in luck.  A bug-free version of this language was created by one
> William Ramage during the mid-1970s.  It's only statement is:
> 
>        do_what_i_meant
> 
> Even now we're still trying to install the exception handler which
> calls:
> 
>       do_what_i_forgot
> 
In the video game industry, there's something very similar.
It's actually a hidden hardware bit in memory, which is often emulated
in software
because game hardware manufacturers never document it's whereabouts(or
if
it is documented, the third party liscencing agreement explicitly
forbids writing to that area of memory in a shipped product), called the
"BMPB",
or the Be My Product Bit.


-- 

Joel Dinolt
·······@pacbell.net
It's more fun to compute.
From: Jesse Paulsen
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <60a3li$45@tower.itis.com>
In article <····················@jdege.visi.com>,
Jeffrey C. Dege <·····@nospam.visi.com> wrote:
>I've recently invented a language that appears to be simpler and more
>expressive than any I've seen so far.  It contains no variables, no
>functions, and only one statement: "do_what_i_want".  Every program,
>no matter how complicated, when translated into my new language,
>is represented by this one statement.

Have you considered implementing a version of your new language
optimized for use in artificial intelligence through the addition
of the statement "do_what_you_want"?
-- 
Jesse Paulsen
········@itis.com

"Imagination is more important than knowledge."   - Albert Einstein
From: Alex Krol
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <34295EFF.521E@scitex.com>
Jesse Paulsen wrote:
> 
> In article <····················@jdege.visi.com>,
> Jeffrey C. Dege <·····@nospam.visi.com> wrote:
> >I've recently invented a language that appears to be simpler and more
> >expressive than any I've seen so far.  It contains no variables, no
> >functions, and only one statement: "do_what_i_want".  Every program,
> >no matter how complicated, when translated into my new language,
> >is represented by this one statement.
> 
> Have you considered implementing a version of your new language
> optimized for use in artificial intelligence through the addition
> of the statement "do_what_you_want"?

 No, the real improvement would be "do_no_what_I_think_I_want_but_
what_I_really_want_but_can't_formulate" :)

	Regards,
		Alex Krol
From: Mike Rubenstein
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <3429e8b7.602396770@nntp.ix.netcom.com>
·····@jdege.visi.com (Jeffrey C. Dege) wrote:

> I've recently invented a language that appears to be simpler and more
> expressive than any I've seen so far.  It contains no variables, no
> functions, and only one statement: "do_what_i_want".  Every program,
> no matter how complicated, when translated into my new language,
> is represented by this one statement.

Unfortunately, this isn't very useful.  I really need a language with
the statement "do_what_i_should_want".

Michael M Rubenstein
From: Charles Fiterman
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <3428FEB9.3E2E@geodesic.com>
Mike Rubenstein wrote:
> ·····@jdege.visi.com (Jeffrey C. Dege) wrote:
> 
> Unfortunately, this isn't very useful.  I really need a language with
> the statement "do_what_i_should_want".

The language do_what_i_want or do_what_i_should_want has a bug.
It eliminates programming jobs which is not what I want. In
fact given the amount of computer control it reduces us to
the level of pets which is really not what I want.
From: Alicia Carla Longstreet
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <34291A95.48E3@ici.net>
Mike Rubenstein wrote:
> 
> ·····@jdege.visi.com (Jeffrey C. Dege) wrote:
> 
> > I've recently invented a language that appears to be simpler and more
> > expressive than any I've seen so far.  It contains no variables, no
> > functions, and only one statement: "do_what_i_want".  Every program,
> > no matter how complicated, when translated into my new language,
> > is represented by this one statement.
> 
> Unfortunately, this isn't very useful.  I really need a language with
> the statement "do_what_i_should_want".

Well gentlemen, I developed a language some time ago that has a single
instruction.  Unfortunaltly, hardware capabilities are still lagging so
the computer I executed my program on is still laboring on the first
instruction.

Oh BTW, the only instruction is		just_do_everthing

-- 
************************************************
* Alicia Carla Longstreet     ·····@ici.net    *
*     Remove NO_SPAM when replying to me.      *
************************************************
My compassion for someone is not limited
to my estimate of their intelligence.
      Dr Gillian, Star Trek IV, The Voyage Home
************************************************
My opinion is a view I hold until - well - until
I find out something that changes it.
                                Luigi Pirandello
From: Dann Corbit
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <60c65j$knj$1@client2.news.psi.net>
Alicia Carla Longstreet wrote in article <·············@ici.net>...


[clip]
>Well gentlemen, I developed a language some time ago that has a single
>instruction.  Unfortunaltly, hardware capabilities are still lagging so
>the computer I executed my program on is still laboring on the first
>instruction.
>
>Oh BTW, the only instruction is just_do_everthing

Unfortunately, Nike felt that this infringed upon a copyright slogan and the
whole thing ended up mired in court.
--
C-FAQ ftp sites: ftp://ftp.eskimo.com ftp://rtfm.mit.edu
Hypertext C-FAQ: http://www.eskimo.com/~scs/C-faq/top.html
C-FAQ Book: ISBN 0-201-84519-9.
Want Software? Algorithms? Pubs? http://www.infoseek.com
From: White Queen
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <3442D805.EBB3E503@emory.edu>
Robert White wrote:

> Mike Rubenstein wrote:
>
> > ·····@jdege.visi.com (Jeffrey C. Dege) wrote:
> >
> > > I've recently invented a language that appears to be simpler and more
> > > expressive than any I've seen so far.  It contains no variables, no
> > > functions, and only one statement: "do_what_i_want".  Every program,
> > > no matter how complicated, when translated into my new language,
> > > is represented by this one statement.
> >
> > Unfortunately, this isn't very useful.  I really need a language with
> > the statement "do_what_i_should_want".
> >
>
> Sorry, *WAY* to obscure, people "want" all sorts of things that are bad,
> dangerous, or lead to criminal prosicution if the sampling of "want" is
> particularly unfortunate.  I think the optimal verb would be
> "do_what_needs_to_be_done_here"...
>

Oh, no.  The optimal verb is "execute".
I make no promises as to the results, mind you...
From: user
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <3425140D.42C5@swbell.net>
pcm wrote:
> 
> Does anyone want to venture an opinion on what is the most elegant
> programming language in the world today?
> 
> And has there been any recent languages especially noted for their
> elegance?
> 
> - Peter.
> 
> (Personally, my vote would go for Scheme with the latest ANSII standard C++
> a close second, but I'm certainly open to suggestions)

CLARION
From: Alicia Carla Longstreet
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <34251DDE.60D4@ici.net>
user wrote:
> 
> pcm wrote:
> >
> > Does anyone want to venture an opinion on what is the most elegant
> > programming language in the world today?
> >
> > And has there been any recent languages especially noted for their
> > elegance?
> >
> > - Peter.
> >
> > (Personally, my vote would go for Scheme with the latest ANSII standard C++
> > a close second, but I'm certainly open to suggestions)
> 
> CLARION

No, FORCE.

-- 
************************************************
* Alicia Carla Longstreet     ·····@ici.net    *
*     Remove NO_SPAM when replying to me.      *
************************************************
My compassion for someone is not limited
to my estimate of their intelligence.
      Dr Gillian, Star Trek IV, The Voyage Home
************************************************
My opinion is a view I hold until - well - until
I find out something that changes it.
                                Luigi Pirandello
From: David Fox
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <y5aiuvuvqr8.fsf@graphics.cat.nyu.edu>
"pcm" <···@mira.net> writes:

> Does anyone want to venture an opinion on what is the most elegant
> programming language in the world today?  

I think everyone will agree that the most elegant programming
language in the world today is Haskell.  Won't they?
-- 
David Fox            http://www.cat.nyu.edu/fox            xoF divaD
NYU Media Research Lab     ···@cat.nyu.edu    baL hcraeseR aideM UYN
From: William Paul Vrotney
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <vrotneyEGw682.6w1@netcom.com>
In article <···············@graphics.cat.nyu.edu> f o x @ c a t . n y u . e
d u (David Fox) writes:

> 
> "pcm" <···@mira.net> writes:
> 
> > Does anyone want to venture an opinion on what is the most elegant
> > programming language in the world today?  
> 
> I think everyone will agree that the most elegant programming
> language in the world today is Haskell.  Won't they?

"Everything should be as simple as possible ... but not simpler." - Albert
Einstein.  In Lisp one can do mostly functional programming but can
occasionally do other things and can use side effects when that seems like a
more correct solution.  I believe it is Knuth that shows even the seemingly
inelegant GOTO is necessary for certain special algorithms.

-- 

William P. Vrotney - ·······@netcom.com
From: Richard A. O'Keefe
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <604ua5$lb$1@goanna.cs.rmit.edu.au>
f o x @ c a t . n y u . e d u (David Fox) writes:
>I think everyone will agree that the most elegant programming
>language in the world today is Haskell.  Won't they?

Close, but Clean has a far better approach to IO (always a problem in
pure functional languages).

-- 
Unsolicited commercial E-mail to this account is prohibited; see section 76E
of the Commonwealth Crimes Act 1914 as amended by the Crimes Legislation
Amendment Act No 108 of 1989.  Maximum penalty:  10 years in gaol.
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.
From: Arthur Gold
Subject: Language elegance (was Re: What is the most "Elegant" Language?)
Date: 
Message-ID: <artiegold-2209971107100001@apm6-147.realtime.net>
In article <··························@pc1>, "pcm" <···@mira.net> wrote:

>Does anyone want to venture an opinion on what is the most elegant
>programming language in the world today?  
>
>And has there been any recent languages especially noted for their
>elegance?
>
>- Peter.
>
>(Personally, my vote would go for Scheme with the latest ANSII standard C++
>a close second, but I'm certainly open to suggestions)

Without ascribing any particular intent to the original poster, this is
obviously a 'troll'-type question--which can sometimes actually be
valuable. What may be gained here (through iterative discussion) is the
answer to a more important question, i.e. "What makes a programming
language elegant?"

I offer a starting point: the elegance of a language is comprised of three
aspects, its expressibility (what meta-concepts can be expressed), its
brevity (how long does it take to express these concepts) and its
readibility (how easily can someone other than the original programmer
deduce what's going on, at a high level).

So there's some grist for the mill. I just truly hope it's useful grist.

--Artie
-- 
Artie Gold -------------------------- Austin, Texas
email: ·········@weirdness.com, ·····@cs.utexas.edu

"I've never liked side effects. They always left me groaning on the floor."
From: Dann Corbit
Subject: Re: Language elegance (was Re: What is the most "Elegant" Language?)
Date: 
Message-ID: <01bcc7a1$39540140$90d6a826@DCorbit.products.solutionsiq.com>
Arthur Gold <·········@weirdness.com> wrote in article
<··························@apm6-147.realtime.net>...
[snip]
> I offer a starting point: the elegance of a language is comprised of
three
> aspects, its expressibility (what meta-concepts can be expressed), its
> brevity (how long does it take to express these concepts) and its
> readibility (how easily can someone other than the original programmer
> deduce what's going on, at a high level).
Brevity and readability are often opposites.  And this arbitrary definition
of elegance is no better or worse than any other.  And now, how do we
define 'expressibility'?  What is 'readability'?

Consider:
MIX {one of Knuth's toys} is probably the ugliest language ever defined {my
opinion}.
Knuth's algorithms, written in MIX, are almost always very elegant {my
definition}.
I have seen million line projects where all the code was elegant {so much
for brevity}
I have seen ten line programs that absolutely made me cringe.
I have seen highly readable code that was highly readable crap.
> 
> So there's some grist for the mill. I just truly hope it's useful grist.
	What is the most <SUPERLATIVE> language?
OR
	What is the most <SUPERLATIVE> operating system?
subject lines never lead to anything useful.  Do a Deja News web search for
megs and megs of proof.  Even if such a topic were useful to come to some
sort of consensus, it would not be useful on comp.lang.c.
-- 
C-FAQ ftp sites: ftp://ftp.eskimo.com ftp://rtfm.mit.edu
Hypertext C-FAQ: http://www.eskimo.com/~scs/C-faq/top.html
C-FAQ Book: ISBN 0-201-84519-9.
Want Software?  Algorithms?  Pubs? http://www.infoseek.com
From: Thant Tessman
Subject: Re: Language elegance (was Re: What is the most "Elegant" Language?)
Date: 
Message-ID: <3426FE53.41C6@signature.below>
Dann Corbit wrote:

> Brevity and readability are often opposites.  [...]

Too often this is nothing more than an excuse made by 
the designers of bad languages.

Particularly annoying is an analogous claim made by Bjarne 
Stroustrup in http://www.research.att.com/~bs/blast.html

"Over the years C++ has been deemed useless because it 
lacked (among other things) type checking, metaclasses, 
multiple inheritance, garbage collection, generics, 
concurrency support, exceptions, co- and contra-variance, 
dynamic linking, typecase switches. Simultaneously, it 
was - often by the same people - deemed useless because 
it was too complicated and had too many features."

So how come there are languages that manage to support
most of the above features without being NEARLY as 
complicated and butt-ugly as C++?

And to add a little weight to my claims, here's yet 
another example of why C++ sucks that I ran across
just last week.  (I have a bunch of these examples.  I 
was thinking of putting together a book of examples of 
why C++ sucks except I hear somebody named Scott Meyers 
already beat me to it.)


struct Base {

  virtual void foo() const = 0;
};


struct ImpLeft : virtual Base {

  virtual void foo() const {}
};


struct ImpRight : virtual Base {

  ImpRight() { 

    foo();
  }

};



struct Derived : ImpLeft, ImpRight {};


main () {

  Derived a;  // Kablooey!  foo is still pure virtual
              // even though ImpLeft is built before 
              // ImpRight
}


--
thant at acm dot org
From: Darin Johnson
Subject: Re: Language elegance (was Re: What is the most "Elegant" Language?)
Date: 
Message-ID: <slrn62e4sm.lq0.darin@connectnet1.connectnet.com>
In article <·············@signature.below>, Thant Tessman wrote:
>So how come there are languages that manage to support
>most of the above features without being NEARLY as 
>complicated and butt-ugly as C++?

Probably because of the way C++ implements the features
it does have.  It's keyword heavy, and there are a lot of
combinations of keywords.

In many places, C++ does not decide upon one way of doing things, but
instead lets the programmer choose between two or more alternatives.
Ie, you have dynamic and static method binding, three levels of
attribute protection, virtual and non-virtual inheritance, etc.  So
even with the feature set it does have, it is still complex.  It's a
tradeoff - more choices allows the programmer to optimize the code
better, but it complicates the code, the compiler, maintenance, etc.

-- 
Darin Johnson
·····@usa.net.delete_me
From: Thant Tessman
Subject: Re: Language elegance (was Re: What is the most "Elegant" Language?)
Date: 
Message-ID: <3427FD38.41C6@signature.below>
[...followups redirected...]

Darin Johnson wrote:
> 
> In article <·············@signature.below>, Thant Tessman wrote:
> >So how come there are languages that manage to support
> >most of the above features without being NEARLY as
> >complicated and butt-ugly as C++?
> 
> Probably because of the way C++ implements the features
> it does have.  It's keyword heavy, and there are a lot of
> combinations of keywords.

Close, but not quite right.  It has nothing to do with 
keywords per se.  The design goal of being based on "C" 
meant that many design features couldn't be added cleanly.  
C++ has many solutions that are only about 80% right.  But 
what's worse, they're not orthogonal to each other, and 
they have all sorts of very subtle and unintuitive 
interactions with each other.  For example, namespaces and 
overloading interact with each other in very peculiar ways.  
And while templates are one of the best things about C++, 
they are an incredible source of not only compiler complexity, 
but a blizzard of truly subtle and bizarre programming 
gotchas.

C++ just simply turned out to be a really bad idea.  But so 
many people have put so much energy into it, no one wants 
to admit it.

-thant

--
thant at acm dot org
From: Dennis Weldy
Subject: Re: Language elegance (was Re: What is the most "Elegant" Language?)
Date: 
Message-ID: <uNpd4wCy8GA.168@news2.ingr.com>
 note: In your example, calling a virtual function from the CONSTRUCTOR,
winds up calling the base class' method. This is expected behavior, if I
recall correctly. 
Note that ImpRight knows nada about ImpLeft's definition of foo. 

Feel free to post more examples of "Why c++ sucks". ;-)

Dennis

Thant Tessman wrote in article <·············@signature.below>...

>Dann Corbit wrote:
>
>> Brevity and readability are often opposites.  [...]
>
>Too often this is nothing more than an excuse made by 
>the designers of bad languages.
>
>Particularly annoying is an analogous claim made by Bjarne 
>Stroustrup in http://www.research.att.com/~bs/blast.html
>
>"Over the years C++ has been deemed useless because it 
>lacked (among other things) type checking, metaclasses, 
>multiple inheritance, garbage collection, generics, 
>concurrency support, exceptions, co- and contra-variance, 
>dynamic linking, typecase switches. Simultaneously, it 
>was - often by the same people - deemed useless because 
>it was too complicated and had too many features."
>
>So how come there are languages that manage to support
>most of the above features without being NEARLY as 
>complicated and butt-ugly as C++?
>
>And to add a little weight to my claims, here's yet 
>another example of why C++ sucks that I ran across
>just last week.  (I have a bunch of these examples.  I 
>was thinking of putting together a book of examples of 
>why C++ sucks except I hear somebody named Scott Meyers 
>already beat me to it.)
>
>
>struct Base {
>
>  virtual void foo() const = 0;
>};
>
>
>struct ImpLeft : virtual Base {
>
>  virtual void foo() const {}
>};
>
>
>struct ImpRight : virtual Base {
>
>  ImpRight() { 
>
>    foo();
>  }
>
>};
>
>
>
>struct Derived : ImpLeft, ImpRight {};
>
>
>main () {
>
>  Derived a;  // Kablooey!  foo is still pure virtual
>              // even though ImpLeft is built before 
>              // ImpRight
>}
>
>
>--
>thant at acm dot org
>.
> 
From: Thant Tessman
Subject: Re: Language elegance (was Re: What is the most "Elegant" Language?)
Date: 
Message-ID: <342809BC.167E@signature.below>
[...followups redirected...]

Dennis Weldy wrote:
> 
>  note: In your example, calling a virtual function 
> from the CONSTRUCTOR, winds up calling the base class' 
> method. This is expected behavior, if I recall 
> correctly.  Note that ImpRight knows nada about 
> ImpLeft's definition of foo.

It's the defined behavior, not the expected behavior.
Note that the only time ImpRight can't see ImpLeft::foo 
is in the constructor and destructor.  ImpRight can legally
call foo any other time and get ImpLeft's implementation.  
And ImpLeft is free to affect values in Base to be seen 
by ImpRight at construction time as well.

What surprised me was that the designers let me get away 
with calling a pure virtual function at all.  But it's 
right there in section 10.4.6 of the 1997 C++ Public 
Review Document:

    Member functions can be called from a constructor (or 
    destructor) of an abstract class; the effect of making 
    a virtual call to a pure virtual function directly or 
    indirectly for the object being created (or destroyed) 
    from such a constructor (or destructor) is undefined.


> Feel free to post more examples of "Why c++ sucks". ;-)

Read through the C++ Public Review Document and look for
occurences of the phrases "behavior is undefined" and 
especially "no diagnostic is required".  

Or here's an even simpler indicator of how much C++ sucks:
Print out the C++ Public Review Document.  Have someone 
hold it about three feet above your head and then drop it.  
Thus you will be enlightened.

-thant
From: Paul Prescod
Subject: Re: Language elegance (was Re: What is the most "Elegant" Language?)
Date: 
Message-ID: <EH2CA3.I58@undergrad.math.uwaterloo.ca>
In article <·············@signature.below>,
Thant Tessman  <·······@signature.below> wrote:
>Dann Corbit wrote:
>
>> Brevity and readability are often opposites.  [...]
>
>Too often this is nothing more than an excuse made by 
>the designers of bad languages.
>
>Particularly annoying is an analogous claim made by Bjarne 
>Stroustrup in http://www.research.att.com/~bs/blast.html

Why are you trying to start a protacted C++-centric flame war in many 
innoncent newsgroups?

 Paul Prescod
From: Thant Tessman
Subject: Re: Language elegance (was Re: What is the most "Elegant" Language?)
Date: 
Message-ID: <342B12A7.41C6@signature.below>
Paul Prescod wrote:

> Why are you trying to start a protacted C++-centric flame war 
> in many innoncent newsgroups?

Because C++ REALLY SUCKS!  And so does anyone who defends it!

[...followups redirected...]

--
thant at acm dot org
From: Ray Dillinger
Subject: Re: Language elegance
Date: 
Message-ID: <342727FE.37EE@sonic.net>
Arthur Gold wrote:
 
> In article <··························@pc1>, "pcm" <···@mira.net> wrote:
> 
> >Does anyone want to venture an opinion on what is the most elegant
> >programming language in the world today?
> >
> >And has there been any recent languages especially noted for their
> >elegance?
> >
> >- Peter.
> >
> >(Personally, my vote would go for Scheme with the latest ANSII standard C++
> >a close second, but I'm certainly open to suggestions)
> 
> Without ascribing any particular intent to the original poster, this is
> obviously a 'troll'-type question--which can sometimes actually be
> valuable. What may be gained here (through iterative discussion) is the
> answer to a more important question, i.e. "What makes a programming
> language elegant?"
> 
> I offer a starting point: the elegance of a language is comprised of three
> aspects, its expressibility (what meta-concepts can be expressed), its
> brevity (how long does it take to express these concepts) and its
> readibility (how easily can someone other than the original programmer
> deduce what's going on, at a high level).
> 
> So there's some grist for the mill. I just truly hope it's useful grist.
> 

I have a counteropinion...  I think that elegance in a language can be 
measured as a ratio of how much expressibility (your definition),
brevity, and efficiency a language buys for how little an investment 
of programmer knowledge. 

Elegant languages don't have as many different statement types as 
inelegant languages. 

Elegant languages don't (necessarily) have as big a standard library 
as inelegant languages. 

Elegant languages don't require the programmer to remember as many 
rules, or as many exceptions to rules, as inelegant languages. 

And yet, despite that, elegant languages tend to express the same 
algorithm in a smaller number of symbols than inelegant languages. 


Of course, the last statement implies the existence of an algorithm -- 
meaning, elegance in some cases is relative to what problem you're 
working on.  

				Bear
From: Bill House
Subject: Re: Language elegance (was Re: What is the most "Elegant" Language?)
Date: 
Message-ID: <01bcc943$b44a6ee0$8602b8cd@micron.dazsi.com>
Arthur Gold <·········@weirdness.com> wrote in article
<··························@apm6-147.realtime.net>...
>
>[snip]
> 
> I offer a starting point: the elegance of a language is comprised of three
> aspects, its expressibility (what meta-concepts can be expressed), its
> brevity (how long does it take to express these concepts) and its
> readibility (how easily can someone other than the original programmer
> deduce what's going on, at a high level).
> 
These are a fine start, but I suggest that different problem domains and user
communities will favor different portions of these ingredients. What seems
elegant to engineers programming CAD/CAM applications might not seem so
wonderful to graphic designers programming Web pages.

For a bit of an anecdote, I was having a debate with a German language designer
and a mathematician friend over the proposed syntax of a programming language.
They favored a Pascal-like declaration syntax, and visible end-of-line tokens
(i.e. semi-colons).  I maintained that this would not be accepted by the
majority of their not-so-technical target audience. The better solution, I
held, was to use the same word order as C, and to dispense with the end-of-line
completely (i.e., CR/LF is end-of-line).  Of course, they thought I was crazy.

Realizing that I was getting nowhere, I suggested that we try a bit of an
experiment -- we corralled the matematician's wife (an Irish RN) and asked her
to choose which style of declaration she preferred:

	Customer MyCust;
	
	MyCust: Customer;

	MyCust As Customer

	Customer MyCust

She chose the last one, citing the lack of puzzling punctuation, brevity and
more "natural" word order as the reasons for her choice. I never did try

	MyCust The Customer

but perhaps I should have. <g>

Bill House
-- 
http://www.housewebs.com
Note: My e-mail address has been altered to confuse spambots
From: Richard A. O'Keefe
Subject: Re: Language elegance (was Re: What is the most "Elegant" Language?)
Date: 
Message-ID: <60f3tj$j9q$1@goanna.cs.rmit.edu.au>
"Bill House" <······@nospam.housewebs.com> writes:
>Realizing that I was getting nowhere, I suggested that we try a bit of an
>experiment -- we corralled the matematician's wife (an Irish RN) and asked her
>to choose which style of declaration she preferred:

>	Customer MyCust;
>	
>	MyCust: Customer;

>	MyCust As Customer

>	Customer MyCust

>She chose the last one, citing the lack of puzzling punctuation, brevity and
>more "natural" word order as the reasons for her choice. I never did try

What you _should_ have done was either
 - to explicitly say that ":" is to be pronounced as "is a" or "is an"
 - to propose Pascal/Ada syntax with the colon spelled out.

I strongly suspect that

    MyCust is a Customer

would have been a clear winner in your test.  That certainly is a _far_
more natural word order in English (the language of your test) than
"Customer MyCust".

This can be combined with a neat hack that was suggested back in the 70s
for Pascal.  In addition to
	<identifier> <isa> <type>
allow
	a/an [<modifier>] <type name>
as the way to declare 
	the [<modifier>] <type name>

For example, one might have

    raise_lecturer_pay(a staff ID, a percentage) is
      the income[the staff ID] :=
	the income[the staff ID] *
	(1.0 + the percentage/100.0)
    end;

equivalent to

    raise_lecturer_pay(the_staff_ID: ID, the_percentage: percentage) is
      the_income[the_staff_ID] :=
	the_income[the_staff_ID] *
	(1.0 + the_percentage/100.0)
    end;



-- 
Unsolicited commercial E-mail to this account is prohibited; see section 76E
of the Commonwealth Crimes Act 1914 as amended by the Crimes Legislation
Amendment Act No 108 of 1989.  Maximum penalty:  10 years in gaol.
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.
From: Bill House
Subject: Re: Language elegance (was Re: What is the most "Elegant" Language?)
Date: 
Message-ID: <01bcca95$40447f60$3678d6ce@micron.dazsi.com>
Richard A. O'Keefe <··@goanna.cs.rmit.edu.au> wrote in article
<············@goanna.cs.rmit.edu.au>...
> 
> I strongly suspect that
> 
>     MyCust is a Customer
> 
> would have been a clear winner in your test.  That certainly is a _far_
> more natural word order in English (the language of your test) than
> "Customer MyCust".
> 
Very good point, and I think you are probably right. If I get up to SF and see
Joan, I'll try it on her!

Bill House
-- 
http://www.housewebs.com
Note: My e-mail address has been altered to confuse spambots
From: Christopher Eltschka
Subject: Re: Language elegance (was Re: What is the most "Elegant" Language?)
Date: 
Message-ID: <3450C1CC.2883F46B@physik.tu-muenchen.de>
Richard A. O'Keefe wrote:
> 
> "Bill House" <······@nospam.housewebs.com> writes:
> >Realizing that I was getting nowhere, I suggested that we try a bit of an
> >experiment -- we corralled the matematician's wife (an Irish RN) and asked her
> >to choose which style of declaration she preferred:
> 
> >       Customer MyCust;
> >
> >       MyCust: Customer;
> 
> >       MyCust As Customer
> 
> >       Customer MyCust
> 
> >She chose the last one, citing the lack of puzzling punctuation, brevity and
> >more "natural" word order as the reasons for her choice. I never did try
> 
> What you _should_ have done was either
>  - to explicitly say that ":" is to be pronounced as "is a" or "is an"
>  - to propose Pascal/Ada syntax with the colon spelled out.
> 
> I strongly suspect that
> 
>     MyCust is a Customer
> 
> would have been a clear winner in your test.  That certainly is a _far_
> more natural word order in English (the language of your test) than
> "Customer MyCust".
> 
> This can be combined with a neat hack that was suggested back in the 70s
> for Pascal.  In addition to
>         <identifier> <isa> <type>
> allow
>         a/an [<modifier>] <type name>
> as the way to declare
>         the [<modifier>] <type name>

What would the modifier do?

> 
> For example, one might have
> 
>     raise_lecturer_pay(a staff ID, a percentage) is
>       the income[the staff ID] :=
>         the income[the staff ID] *
>         (1.0 + the percentage/100.0)
>     end;
> 
> equivalent to
> 
>     raise_lecturer_pay(the_staff_ID: ID, the_percentage: percentage) is
>       the_income[the_staff_ID] :=
>         the_income[the_staff_ID] *
>         (1.0 + the_percentage/100.0)
>     end;

Going even more into this direction, you could also replace the
comma by allowing prepositions to denote (and delimit) the arguments.
Then you could even allow reordering function arguments by giving
the preposition at the call site. Also, as the "is" already
ends the parameter list, you wont need the parentheses (to avoid them
at the call point, you of course have to explicitly end the statement
- but that's done in pascal anyway, either with ; or with end)

So you program could look like this:

raise_lecturer_pay of a staff_ID by a percentage is
  the income[the staff_ID]:=
     the income[the staff_ID] * (1.0 + the percentage/100.0)
end;

(* variable definition, new style here, too *)
Toms_ID is a staff_ID;

begin (* main program *)
  raise_lecturer_pay of Toms_ID by 20.0
end.

Or with spaces in identifiers allowed (parameters _must_ be
started with prepositions in this case, else the end of the
function name could not be recognised)

raise lecturer pay of a stuff ID by a percentage is
  the income[the staff ID]:=
    the income[the staff ID] * (1.0 + the percentage/100.0)
end;

Toms ID is a staff_ID;

begin (* main program *)
  raise lecturer pay of Toms ID by 20.0
end.

BTW, we also should have a way to name arguments, if there are two
or more arguments of the same type. Maybe:

(* type definition *)
a money amount is a real number; (* amount of cents *)

money order from a banc account (account 1) (* name in brackets *)
            to a bank account (account 2)
            about a money amount
is
  reduce account for account 1 by the money amount;
  increase accound for account 2 by the money account
end;

In addition, it would be nice to allow specifying function results
with such a syntax, too, maybe like the following:

square root of a real number (x) giving a real number is
  tmp1 is a real number, initially x;
  tmp2 is a real number;
  repeat
    tmp2:=tmp1;
    tmp1:=0.5*(tmp1+1/tmp1)
  until abs of (tmp1-tmp2) < epsilon;
  the square root:=tmp1
end;

I guess this is becoming a completely new language...
(Would it be elegant?)
From: Alan J. Livingston
Subject: Re: Language elegance (was Re: What is the most "Elegant" Language?)
Date: 
Message-ID: <3450C62C.1ABB@acm.org>
Christopher Eltschka wrote:
> 

<Snip!>


> In addition, it would be nice to allow specifying function results
> with such a syntax, too, maybe like the following:
> 
> square root of a real number (x) giving a real number is
>   tmp1 is a real number, initially x;
>   tmp2 is a real number;
>   repeat
>     tmp2:=tmp1;
>     tmp1:=0.5*(tmp1+1/tmp1)
>   until abs of (tmp1-tmp2) < epsilon;
>   the square root:=tmp1
> end;
> 
> I guess this is becoming a completely new language...
> (Would it be elegant?)

No, it would be Cobol!

-Alan
From: Richard A. O'Keefe
Subject: Re: Language elegance (was Re: What is the most "Elegant" Language?)
Date: 
Message-ID: <633t5a$8jr$1@goanna.cs.rmit.edu.au>
Christopher Eltschka <········@physik.tu-muenchen.de> writes:
>Richard A. O'Keefe wrote:
>> This can be combined with a neat hack that was suggested back in the 70s
>> for Pascal.  In addition to
>>         <identifier> <isa> <type>
>> allow
>>         a/an [<modifier>] <type name>
>> as the way to declare
>>         the [<modifier>] <type name>

>What would the modifier do?

Nothing.  It would just _be_.
    declarations:
	a/an T			=== the_T: T;
	a/an M T		=== the_M_T: T;
    uses:
	the T			=== the_T
	the M T			=== the_M_T

Remember, this isn't a new idea.  It goes back about 20 years.

>BTW, we also should have a way to name arguments, if there are two
>or more arguments of the same type. Maybe:

That is precisely what the modifier does.

>money order from a banc account (account 1) (* name in brackets *)
>            to a bank account (account 2)
>            about a money amount
>is
>  reduce account for account 1 by the money amount;
>  increase accound for account 2 by the money account
>end;

Sticking with otherwise Ada-ish syntax, this would be

    procedure transfer_money(
	a source account;
	a destination account;
	an amount
    ) is
    begin
	increment(the balance(the source account), by => the amount);
	decrement(the balance(the destination acount), by => the amount);
    end;

-- 
John �neas Byron O'Keefe; 1921/02/04-1997/09/27; TLG,TLTA,BBTNOTL.
Richard A. O'Keefe; RMIT Comp.Sci; http://www.cs.rmit.edu.au/%7Eok
From: Steven D. Majewski
Subject: Re: Language elegance (was Re: What is the most "Elegant" Language?)
Date: 
Message-ID: <63iq1m$96r$1@murdoch.acc.Virginia.EDU>
For another perspective on Language Elegance, see my article in
comp.lang.misc on Subject: Programming Language Design Patterns.


---|  Steven D. Majewski   (804-982-0831)  <·····@Virginia.EDU>  |---
---|  Department of Molecular Physiology and Biological Physics  |---
---|  University of Virginia             Health Sciences Center  |---
---|  P.O. Box 10011            Charlottesville, VA  22906-0011  |---
All power corrupts and obsolete power corrupts obsoletely." - Ted Nelson
From: David Hanley
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <3426D9D0.80160B48@nospan.netright.com>
pcm wrote:

> Does anyone want to venture an opinion on what is the most elegant
> programming language in the world today?

    English, but compilers which emit high-quality code are rare.

> - Peter.
>
> (Personally, my vote would go for Scheme with the latest ANSII
> standard C++
> a close second, but I'm certainly open to suggestions)

    Huh.  I don't know if I'd place those two in the same bit-bucket.
and, while I'dcall C++ 'powerful' I'm not sure if I'd call it 'elegant'.

    SML and Haskall are fairly elegant, thought I wouln't qualify them
as
'most elegant', as I have not tried everything....

    dave
From: Alexey Raschepkin
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <342A114D.35C2953D@artelecom.ru>
pcm wrote:

> Does anyone want to venture an opinion on what is the most elegant
> programming language in the world today?
>
> And has there been any recent languages especially noted for their
> elegance?
>
> - Peter.
>
> (Personally, my vote would go for Scheme with the latest ANSII
> standard C++
> a close second, but I'm certainly open to suggestions)

   I think the most elegant languages are ones by Wirth.
But, elegant doesn't mean useful, the most useful languahes I consider C
and C++.
They are general-purpose language and reflect curren computer
architecture instead of, for example, LISP.
From: Dale Gerdemann
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <342A4EF0.4A38@sfs.nphil.uni-tuebingen.de>
On the topic of elegence and computing, the following book notice
caught my eye:

   Machine Beauty : Elegance and the Heart of Computing (Master Minds
   Series)
   by David Hillel Gelernter
   Published by Basic Books
   Publication date: February 1, 1998
   ISBN: 0465045162

I can't say whether or not the book will be any good. But perhaps
Gelernter has something controversial to say since he somehow managed
to get the attention of the Unabomber.

-- Dale Gerdemann
From: Alicia Carla Longstreet
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <342A5B3E.11C2@ici.net>
Alexey Raschepkin wrote:
> 
> pcm wrote:
> 
> > Does anyone want to venture an opinion on what is the most elegant
> > programming language in the world today?
> >
> > And has there been any recent languages especially noted for their
> > elegance?
> >
> > - Peter.
> >
> > (Personally, my vote would go for Scheme with the latest ANSII
> > standard C++
> > a close second, but I'm certainly open to suggestions)
> 
>    I think the most elegant languages are ones by Wirth.
> But, elegant doesn't mean useful, the most useful languahes I consider C
> and C++.
> They are general-purpose language and reflect curren computer
> architecture instead of, for example, LISP.

I disagree, elegant does indeed imply useful, at least as far as
computer programs are concerned.

An elegant solution to a problem is both efficatious and efficient.  It
is beautiful for its simplicity and usefullness of design.  It is a
program that does its job succinctly but completely.  If a language is
not useful it is definitly not elegant.

-- 
************************************************
* Alicia Carla Longstreet     ·····@ici.net    *
*     Remove NO_SPAM when replying to me.      *
************************************************
My compassion for someone is not limited
to my estimate of their intelligence.
      Dr Gillian, Star Trek IV, The Voyage Home
************************************************
My opinion is a view I hold until - well - until
I find out something that changes it.
                                Luigi Pirandello
From: Kaz
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <60qfdr$q1a$1@latte.cafe.net>
In article <··········@omega.gmd.de>, Joerg Hoehle <······@zeus.gmd.de> wrote:
>Alexey Raschepkin (···@artelecom.ru) wrote:
>:    I think the most elegant languages are ones by Wirth.
>: But, elegant doesn't mean useful, the most useful languahes I consider C
>: and C++.
>: They are general-purpose language and reflect curren computer
>: architecture instead of, for example, LISP.
>
>I don't see how C reflects current computer architecture.  You
>probably think about arrays and auto decrement/increment? But:
>
>C function calling sequence imposes the caller to pop arguments off
>the stack.  Imposing such a property does not necessarily reflect

I looked through the ANSI/ISO C standard forwards and backwards but could not
find any references to a stack. The C language leaves calling conventions up
to the implementation. C has no disavantage here compared to any other
language.

You are naively confusing definition and implementation issues, which
makes me wonder what you are doing in a debate about programming languages.

>current computer architecture, as you like to say.  It makes
>tail-calling difficult in C and imposes unfortunate restrictions on
>some programming styles.  Did you never replace a JSR xyz; RTS by a
>JMP xyz in assembly language?  Don't you understand how this is
>extremely useful?

I totally understand why it is useful. I also know C compilers that have
no trouble converting tail recursive functions into loops.

In any case, smart programmers don't write tail recursive functions, because a
C implementation is not required by the ISO standard to recognize and optimize
tail recursion.

In other words, you can do the same replacement in C that you do in assembly
language. Instead of tail recursion, you write a loop, like a real programmer.

You are basically complaining that C implementations don't always compensate
for stupidity.
-- 
From: David Hanley
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <34314122.1F5A68A8@nospan.netright.com>
Kaz wrote:

> In article <··········@omega.gmd.de>, Joerg Hoehle
> <······@zeus.gmd.de> wrote:
> >Alexey Raschepkin (···@artelecom.ru) wrote:
> >:    I think the most elegant languages are ones by Wirth.
> >: But, elegant doesn't mean useful, the most useful languahes I
> consider C
> >: and C++.
> >: They are general-purpose language and reflect curren computer
> >: architecture instead of, for example, LISP.
> >
> >I don't see how C reflects current computer architecture.  You
> >probably think about arrays and auto decrement/increment? But:
> >
> >C function calling sequence imposes the caller to pop arguments off
> >the stack.  Imposing such a property does not necessarily reflect
>
> I looked through the ANSI/ISO C standard forwards and backwards but
> could not
> find any references to a stack. The C language leaves calling
> conventions up
> to the implementation. C has no disavantage here compared to any other
>
> language.

    You are incorrect.  There's somethig called the ABI that is
designedto allow linkage between code produced by different C compilers
on the same platform.  It specifies quite a bit, including calling
convention.
And, yes, the C convention is not necessarily the best for modern
platforms.  That's to be expected, as these ABI's were defined quite
awhile ago,

> You are naively confusing definition and implementation issues, which
> makes me wonder what you are doing in a debate about programming
> languages.

    This kind of statement may come back to haunt you.

> >current computer architecture, as you like to say.  It makes
> >tail-calling difficult in C and imposes unfortunate restrictions on
> >some programming styles.  Did you never replace a JSR xyz; RTS by a
> >JMP xyz in assembly language?  Don't you understand how this is
> >extremely useful?
>
> I totally understand why it is useful. I also know C compilers that
> have
> no trouble converting tail recursive functions into loops.

    Now you're showing you don't know what your're talking about.Tail
recursion is a lot more than a function calling itself; a finction
may return the results of another function, which is very very useful
in a lot of library-style code.

> In any case, smart programmers don't write tail recursive functions,
> because a
> C implementation is not required by the ISO standard to recognize and
> optimize
> tail recursion.

    Groovy.  But if it's the most elegant way to solve a problem,you're
being forced to not use an elegant solution.

> In other words, you can do the same replacement in C that you do in
> assembly
> language.

    No, you can't.

> Instead of tail recursion, you write a loop, like a real programmer.

    Now that's an intelligent argument.  Before you go off making
blanketstatements like that, you should educate youself as to what you
are taking about..

int foo( int code , float blah )
{
   if ( ............. ) return this( code );
  else if  ( .............. ) return that( blah );
  else return the_other( code,blah );
}

    That's tail-recursion, and it's not a loop, and it makes you
look silly for saying that this can be done.

> You are basically complaining that C implementations don't always
> compensate
> for stupidity.

    Apparently, they must.

    dave
From: Dann Corbit
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <01bccdcf$c038bf00$90d6a826@DCorbit.products.solutionsiq.com>
David Hanley <·····@nospan.netright.com> wrote in article
<·················@nospan.netright.com>...
[snip]
>     Now that's an intelligent argument.  Before you go off making
> blanketstatements like that, you should educate youself as to what you
> are taking about..
> 
> int foo( int code , float blah )
> {
>    if ( ............. ) return this( code );
>   else if  ( .............. ) return that( blah );
>   else return the_other( code,blah );
> }
> 
>     That's tail-recursion, and it's not a loop, and it makes you
> look silly for saying that this can be done.
In what way is recursion even involved?  This function does not call
itself.  It calls either a function called this(), a function called
that(), or a function called the_other().  Are we to assume that one of
those calls foo()?  Do you even know what recursion is?

To understand recursion, one must first understand recursion. ;-)
From: Chris Webb
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <ant3019160b0TCVC@riscpc.trin.cam.ac.uk>
In article <··························@DCorbit.products.solutionsiq.com>,
Dann Corbit <··················@solutionsiq.com> wrote:

> David Hanley <·····@nospan.netright.com> wrote in article
> <·················@nospan.netright.com>...

> > int foo( int code , float blah )
> > {
> >    if ( ............. ) return this( code );
> >   else if  ( .............. ) return that( blah );
> >   else return the_other( code,blah );
> > }
> >     That's tail-recursion...
> In what way is recursion even involved?
[...]
> Do you even know what recursion is?

An excellent example of the amazing confusion that results from calling tail
recursion tail recursion! It isn't some special form of recursion, in
general. Tail recursion is merely an optimisation where a function returning
the value of another function can simply include a direct branch to that
function instead of a subroutine call.

Chris.
-- 
Chris Webb <·····@cam.ac.uk>
Trinity College, Cambridge
Telephone +44 1223 506929
From: Dann Corbit
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <01bccdd7$a02b8280$90d6a826@DCorbit.products.solutionsiq.com>
Chris Webb <·····@cam.ac.uk> wrote in article
<················@riscpc.trin.cam.ac.uk>...
> In article <··························@DCorbit.products.solutionsiq.com>,
> Dann Corbit <··················@solutionsiq.com> wrote:
> 
> > David Hanley <·····@nospan.netright.com> wrote in article
> > <·················@nospan.netright.com>...
> 
> > > int foo( int code , float blah )
> > > {
> > >    if ( ............. ) return this( code );
> > >   else if  ( .............. ) return that( blah );
> > >   else return the_other( code,blah );
> > > }
> > >     That's tail-recursion...
> > In what way is recursion even involved?
> [...]
> > Do you even know what recursion is?
> 
> An excellent example of the amazing confusion that results from calling
tail
> recursion tail recursion! It isn't some special form of recursion, in
> general. Tail recursion is merely an optimisation where a function
returning
> the value of another function can simply include a direct branch to that
> function instead of a subroutine call.
Pardon me, while I wipe this egg off my face.  Hmmm...
Nicely illustrates the dangers of a 'grumpy' post.
-- 
C-FAQ ftp sites: ftp://ftp.eskimo.com ftp://rtfm.mit.edu
Hypertext C-FAQ: http://www.eskimo.com/~scs/C-faq/top.html
C-FAQ Book: ISBN 0-201-84519-9.
Want Software?  Algorithms?  Pubs? http://www.infoseek.com
From: Mark Wilden
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <34315B81.C6B@mWilden.com>
Chris Webb wrote:
> 
> Tail recursion is merely an optimisation where a function returning
> the value of another function can simply include a direct branch to that
> function instead of a subroutine call.

I don't think that's true. "When the last statement executed in a
procedure body is a recursive call of the same procedure, the call is
said to be _tail recursive_." Aho, Sethi, Ullman.

We may use terms in illogical ways some times, but in this case, for
something to be tail-recursive, we at least require that it also be
recursive, i.e. call itself directly or indirectly.
From: Dann Corbit
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <01bccde2$f8bbee20$90d6a826@DCorbit.products.solutionsiq.com>
Mark Wilden <····@mWilden.com> wrote in article
<············@mWilden.com>...
> Chris Webb wrote:
> > 
> > Tail recursion is merely an optimisation where a function returning
> > the value of another function can simply include a direct branch to
that
> > function instead of a subroutine call.
> 
> I don't think that's true. "When the last statement executed in a
> procedure body is a recursive call of the same procedure, the call is
> said to be _tail recursive_." Aho, Sethi, Ullman.
> 
> We may use terms in illogical ways some times, but in this case, for
> something to be tail-recursive, we at least require that it also be
> recursive, i.e. call itself directly or indirectly.
Well, that's what I thought too.  Then I did a web search, and found that
the term 'tail recursion' does have a general meaning of removing function
calls from return statements.  These support that view:
http://www.cs.indiana.edu/eip/workshop1/lab9/lab951.html
http://www.cs.oberlin.edu//classes/cs280/labs/lab9/lab941.html
Whereas:
http://www.cec.wustl.edu/~cs455/subjects/paradigms/functional/recursion.html
#tail
has the definition that I have always used before.
-- 
C-FAQ ftp sites: ftp://ftp.eskimo.com ftp://rtfm.mit.edu
Hypertext C-FAQ: http://www.eskimo.com/~scs/C-faq/top.html
C-FAQ Book: ISBN 0-201-84519-9.
Want Software?  Algorithms?  Pubs? http://www.infoseek.com
From: Kaz
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <60qvqn$rl2$1@latte.cafe.net>
In article <··························@DCorbit.products.solutionsiq.com>,
Dann Corbit <·······@solutionsiq.com> wrote:
>Mark Wilden <····@mWilden.com> wrote in article
><············@mWilden.com>...
>> Chris Webb wrote:
>> > 
>> > Tail recursion is merely an optimisation where a function returning
>> > the value of another function can simply include a direct branch to
>that
>> > function instead of a subroutine call.
>> 
>> I don't think that's true. "When the last statement executed in a
>> procedure body is a recursive call of the same procedure, the call is
>> said to be _tail recursive_." Aho, Sethi, Ullman.

That's what I have always understood by tail recursion. The related
optimization is ``tail recursion optimization''. Glad to have support of
the big three.
-- 
From: Matthias Blume
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <izu3f2csb4.fsf@rant.cs.princeton.edu>
In article <············@latte.cafe.net> ···@latte.cafe.net (Kaz) writes:

   In article <··························@DCorbit.products.solutionsiq.com>,
   Dann Corbit <·······@solutionsiq.com> wrote:
   >Mark Wilden <····@mWilden.com> wrote in article
   ><············@mWilden.com>...
   >> Chris Webb wrote:
   >> > 
   >> > Tail recursion is merely an optimisation where a function returning
   >> > the value of another function can simply include a direct branch to
   >that
   >> > function instead of a subroutine call.
   >> 
   >> I don't think that's true. "When the last statement executed in a
   >> procedure body is a recursive call of the same procedure, the call is
   >> said to be _tail recursive_." Aho, Sethi, Ullman.

   That's what I have always understood by tail recursion. The related
   optimization is ``tail recursion optimization''. Glad to have support of
   the big three.

That book, while good, is more than 20 years old by now.  The usual
definition of tail recursion nowadays includes the case of mutually
recursive procedures and procedures that are passed as arguments
etc. Whole programming language designs (of languages far superior in
elegance to C, I may add) rely on the idea that _all_ tail calls are
implemented efficiently.  One should really talk about TAIL CALL
elimination; various special cases of TAIL RECURSION elimination
follow easily from that.

-- 
-Matthias
From: Jos A. Horsmeier
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <343201A5.EC609DD6@and.nl>
Kaz wrote:

> In article
> <··························@DCorbit.products.solutionsiq.com>,
> Dann Corbit <·······@solutionsiq.com> wrote:
> >Mark Wilden <····@mWilden.com> wrote in article
> ><············@mWilden.com>...
> >> Chris Webb wrote:
>
> >> > Tail recursion is merely an optimisation where a function
> returning
> >> > the value of another function can simply include a direct branch
> to
> >>> that function instead of a subroutine call.
>
> >> I don't think that's true. "When the last statement executed in a
> >> procedure body is a recursive call of the same procedure, the call
> is
> >> said to be _tail recursive_." Aho, Sethi, Ullman.
>
> That's what I have always understood by tail recursion. The related
> optimization is ``tail recursion optimization''. Glad to have support
> of
> the big three.

I think you're all right here; think of the gory details at the bare
metal level.
If a function calls itself as its last statement, there's no need to set
up a
new 'activation record' or 'display' or whatchamacallit (the area where
the
parameter values and return address reside). All it has to do instead,
is,
assign values to its own parameters and jump back to where it started.

Now think what has to happen if a function calls _another_ function as
its
last statement; it has to destroy its own activation record by
overlaying
it (and possibly expanding or shrinking it) by the new activation record

of the function being called and jump to the start address of that
function.

While the latter can definitely be implemented (and it is implemented
actually),
the former is still a bit simpler to implement ...

The former is certainly called 'tail recursion elimination', but what do
we
call the latter then?

kind regards,

Jos aka ···@and.nl
From: Frank A. Adrian
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <60ts5n$191$1@client3.news.psi.net>
 Jos A. Horsmeier wrote in article <·················@and.nl>...

[Good explaination of reusing obsolete activation records snipped]

>The former is certainly called 'tail recursion elimination', but what do
>we
>call the latter then?

Why don't you call it what I've always heard it called - tail-call
elimination?
--
Frank A. Adrian
First DataBank

············@firstdatabank.com (W)
······@europa.com (H)

This message does not necessarily reflect those of my employer,
its parent company, or any of the co-subsidiaries of the parent
company.
From: Kaz
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <60td8p$1sp$1@latte.cafe.net>
In article <·················@and.nl>, Jos A. Horsmeier <···@and.nl> wrote:
>The former is certainly called 'tail recursion elimination', but what do
>we
>call the latter then?

Since a subroutine call is being eliminated, but it's not recursive,
it should be called ``tail call elimination'' or something like that.
Calling it ``tail call threading'' appeals to me as well.
-- 
From: Lawrence Kirby
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <875710875snz@genesis.demon.co.uk>
In article <·················@and.nl> ···@and.nl "Jos A. Horsmeier" writes:

>The former is certainly called 'tail recursion elimination', but what do
>we
>call the latter then?

Tail call elimination.

-- 
-----------------------------------------
Lawrence Kirby | ····@genesis.demon.co.uk
Wilts, England | ·········@compuserve.com
-----------------------------------------
From: Mark Wilden
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <34319792.5176@mWilden.com>
Dann Corbit wrote:
> 
> I did a web search, and found that
> the term 'tail recursion' does have a general meaning of removing function
> calls from return statements.  These support that view:
> http://www.cs.indiana.edu/eip/workshop1/lab9/lab951.html
> http://www.cs.oberlin.edu//classes/cs280/labs/lab9/lab941.html

Good god. I guess some people found "recursion" too sexy a term to
restrict it to its actual meaning. :)

In any case, they are as wrong as those who use "decimate" as a synonym
for "annihilate."
From: Matthias Blume
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <izsoumckro.fsf@mocha.CS.Princeton.EDU>
In article <·············@mWilden.com> Mark Wilden <····@mWilden.com> writes:

   Dann Corbit wrote:
   > 
   > I did a web search, and found that
   > the term 'tail recursion' does have a general meaning of removing function
   > calls from return statements.  These support that view:
   > http://www.cs.indiana.edu/eip/workshop1/lab9/lab951.html
   > http://www.cs.oberlin.edu//classes/cs280/labs/lab9/lab941.html

   Good god. I guess some people found "recursion" too sexy a term to
   restrict it to its actual meaning. :)

I'd be careful with whom I accuse of not knowing what they are talking
about. You, for example, are overlooking the case of mutual recursion
and recursion facilitated by calls to functions provided as function
pointers (or first-class functions, if you know what that term
means). Tail recursion elimination is possible in all these cases, but
it involves eliminating pretty much all tail _calls_, regardless of
whether or not they eventually participate in a recursive call chain.
(You do not need to remove tail calls if you can _prove_ that they
will never participate in a tail recursive computation.  But in the
presence of separate compilation or function pointers that is not
decidable at compile time.)

-- 
-Matthias
From: Richard A. O'Keefe
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <60v79i$jf4$1@goanna.cs.rmit.edu.au>
"Dann Corbit" <·······@solutionsiq.com> writes:
>Well, that's what I thought too.  Then I did a web search, and found that
>the term 'tail recursion' does have a general meaning of removing function
>calls from return statements.

Speaking as one who was in the Prolog compiler business at one time,
you've confused the term 'tail recursion' with the term
'tail recursion OPTIMISATION', which we at Quintus preferred to call
'tail CALL optimisation' because the call->jump transformation has
nothing to do with whether the call is recursive or not.

A tail call is where the dynamically-last operation of a subprogram
is a subprogram call.

A tail recursion is where the dynamically-last operation of a subprogram
is a call to the statically containing subprogram.

Tail call optimisation is where the compiler translates a tail call
as an argument shuffle + a jump.

Tail recursion optimisation sometimes means exactly the same as tail
call optimisation, but is sometimes restricted to optimising tail
recursions only.

For example, there are some C compilers which will translate tail
_recursions_ into jumps, but not other tail calls, whereas Scheme
systems are required to treat all tail calls specially, whether
they are tail recursions or not.

-- 
John �neas Byron O'Keefe; 1921/02/04-1997-09-27; TLG,TLTA,BBTNOTL.
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.
From: David Hanley
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <343192C1.9414B7AC@nospan.netright.com>
Mark Wilden wrote:

> Chris Webb wrote:
> >
> > Tail recursion is merely an optimisation where a function returning
> > the value of another function can simply include a direct branch to
> that
> > function instead of a subroutine call.
>
> I don't think that's true. "When the last statement executed in a
> procedure body is a recursive call of the same procedure, the call is
> said to be _tail recursive_." Aho, Sethi, Ullman.

    I think that's overspecific.  In the general literature, tail
recursionrefers to constructs which return the value of another function
call.
In this case,

a()
{
    return b()
}

    Is tail recusrion, as, instead of calling b, a can jump directly to
b,
saving invaluable clock cycles.. :)

    The name is confusing.  I suspect this has this name because the
general
optimization is the same, though perhaps it should be called
'tail call elimination'.  This would help eliminate confusion.

    dave
From: Kaz
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <60rmg1$tpj$1@latte.cafe.net>
In article <·················@nospan.netright.com>,
David Hanley  <·····@nospam.netright.com> wrote:
>Mark Wilden wrote:
>
>> Chris Webb wrote:
>> >
>> > Tail recursion is merely an optimisation where a function returning
>> > the value of another function can simply include a direct branch to
>> that
>> > function instead of a subroutine call.
>>
>> I don't think that's true. "When the last statement executed in a
>> procedure body is a recursive call of the same procedure, the call is
>> said to be _tail recursive_." Aho, Sethi, Ullman.
>
>    I think that's overspecific.  In the general literature, tail
>recursionrefers to constructs which return the value of another function
>call.

What general literature? Aho, Sethi and Ullman have produced some fine
examples of ``general'' literature.

Do you know what a recursive definition is? Or a recursively enumerable set?
You cannot divorce the concept of self-reference from recursion.   It's
possible to dilute the meaning of any word to the point that it loses the
ability to discern fine ideas, but it is seldom necessary to do this.

Sorry, I will stick with the old school here. You dope smoking Lisp and Scheme
hippies can try your Newspeak on some undergraduate freshmen.
-- 
From: David Hanley
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <34326FD9.F1B476D4@nospan.netright.com>
Kaz wrote:

> In article <·················@nospan.netright.com>,
> David Hanley  <·····@nospam.netright.com> wrote:

> >    I think that's overspecific.  In the general literature, tail
> >recursionrefers to constructs which return the value of another
> function
> >call.
>
> What general literature? Aho, Sethi and Ullman have produced some fine
>
> examples of ``general'' literature.

    I know you're just trying to be annoying, but ASU are not the
entiretyof compiler literature.  A lot of research has been done in
compiler work,
and the term 'tail recursion' has a generally-accepted meaning, which is

broader than ASU state in their book.  I do have the dragon book,
and it's not the only mistake, incedentally.

> Do you know what a recursive definition is? Or a recursively
> enumerable set?

    Yes, I do.    When you move somethin by a car, it's shipping, but
when it's
in a ship, it's cargo.  Sometimes english language is a little
confusing,
but mature people are able to correct themselves.

> Sorry, I will stick with the old school here. You dope smoking Lisp
> and Scheme
> hippies can try your Newspeak on some undergraduate freshmen.

    Uh-huh...  Tail recursion has been well-understood for a long time
now,and arguing that someone is wrong because you don't agree with their
definitions
is very childish.

    If you're going to get hung up on terms, let's just substitute
'tail-calling'
and continue the discussion.  Of course, you won't do that, because
your original point was rubbish anyways.

    dave
From: Erik Westlin
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <3431F9D4.32B8@msi.se>
Kaz wrote:
> 
> In article <·················@nospan.netright.com>,
> David Hanley  <·····@nospam.netright.com> wrote:
> >Mark Wilden wrote:
> >
> >> Chris Webb wrote:
> >> >
> >> > Tail recursion is merely an optimisation where a function returning
> >> > the value of another function can simply include a direct branch to
> >> that
> >> > function instead of a subroutine call.
> >>
> >> I don't think that's true. "When the last statement executed in a
> >> procedure body is a recursive call of the same procedure, the call is
> >> said to be _tail recursive_." Aho, Sethi, Ullman.
> >
> >    I think that's overspecific.  In the general literature, tail
> >recursionrefers to constructs which return the value of another function
> >call.
> 
> What general literature? Aho, Sethi and Ullman have produced some fine
> examples of ``general'' literature.
> 

Isn't there another concept called 'continuations' used in 
common lisp which is what Chris is after.

Maybe that would be a neat thing to have in c(++) (where i spend most of
my time). 
By the way why not lambda expressions - it couldn't be that hard to
implement in c.

While i'm at it. 
The declarative powers of c is a bit limited compared to prolog but it
could improved.

- Erik Westlin
From: Kaz
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <60tder$1tn$1@latte.cafe.net>
In article <·············@msi.se>, Erik Westlin  <·······@msi.se> wrote:
>While i'm at it. 
>The declarative powers of c is a bit limited compared to prolog but it
>could improved.

But Prolog is a completely different beast! C does not solve problems based on
declared goals. You declare the mere existence of data objects, functions and
types.  I can't even be sure whether the word ``declare'' has the same meaning
in Prolog and C.
-- 
From: Chris Webb
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <ant011010d07TCVC@riscpc.trin.cam.ac.uk>
In article <·············@msi.se>, Erik Westlin
<··················@msi.se> wrote:

> Kaz wrote:
> > David Hanley wrote:
> > > Mark Wilden wrote:
> > > > Chris Webb wrote:
> > > > > Tail recursion is merely an optimisation where a function
> > > > > returning the value of another function can simply include a
> > > > > direct branch to that function instead of a subroutine call.
> > > > I don't think that's true. "When the last statement executed in a
> > > > procedure body is a recursive call of the same procedure, the call
> > > > is said to be _tail recursive_." Aho, Sethi, Ullman.
> > >    I think that's overspecific.  In the general literature, tail
> > > recursionrefers to constructs which return the value of another
> > > function call.
> > What general literature? Aho, Sethi and Ullman have produced some fine
> > examples of ``general'' literature.
> Isn't there another concept called 'continuations' used in 
> common lisp which is what Chris is after.

Okay, I sense a big naming argument coming up here. Why not replace 'tail
recursion' with 'that-optimisation-which-when-applied-to-recursive-
-functions-that-return-a-value-of-their-own-invocation-would-be-called-tail-
-recursion-but-that-in-general-we-ought-to-call-something-else-because-
-recursion-is-a-bit-of-a-misnomer' and re-read the original posting in that
light? :-) Tail-call optimisation is probably a much better name.

BTW, what I was originally trying to point out was that tail-recursion as
a name is somewhat confusing. I think that is now very clear!!

Cheers,

Chris.
-- 
Chris Webb <·····@cam.ac.uk>
Trinity College, Cambridge
Telephone +44 1223 506929
From: Martin Rodgers
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <MPG.e9c1253749f6e6d989abc@news.demon.co.uk>
Kaz wheezed these wise words:

> Sorry, I will stick with the old school here. You dope smoking Lisp and Scheme
> hippies can try your Newspeak on some undergraduate freshmen.

So, you're saying you don't know, and you don't wish to know? That's 
what it sounds like.

Try reading this book:

Structure and Interpretation of Computer Programs
MIT Press and McGraw-Hill, Inc.
ISBN 0-262-01153-0 657 

It covers this subject in rather more depth than the "dragon" book. 
See the "Applying compiled procedures" section.

I can also recommend "LISP in Small Pieces" Christian Queinnec, which 
has a few things to say about tail calls and continuations.

Neither of these are "general" compiler books, but you can find SICP 
listed in the bibliography of "Compilers: Principles, Techniques, and 
Tools", as well as several other examples (e.g. Church, McCarthy, 
Steele) of what you might call "dope smoking Lisp and Scheme 
Newspeak". Curious, eh? Perhaps compiler theory is a subject that is 
just too big for any one book, making a few compromises necessary. 
This may be why books like this have such large bibliographies!

With such a wide choice of reading material, it's easy to pick just 
the items that support your point of view. If you really wanted to 
attack Lisp people, perhaps you should try a argument that questions 
our contact with reality. Oh, was that was the "dope smoking Newspeak" 
reference was? Excuse me, but I mistook that for a cheap attempt to 
discredit your targets without depending on any technical basis for 
your "argument". Could it be that you have no technical basis coz 
there is none? That the very literature that you use to support your 
argument is flawed, because it - by necessity - omits many compiler 
techniques, yet acknowledges sources these techniques?

Or were you reading the older book, "Principles of Compiler Design"? 
While that too is an excellent book, it's more than a little dated. 
Hence the publication of the updated version, "Compilers: Principles, 
Techniques, and Tools". If you actually reading the latter, then I 
strongly recommend again that you browse the bibliography.
-- 
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
              Please note: my email address is gubbish
                         assert(got(coat)).
From: Matthias Blume
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <izpvppczxq.fsf@mocha.CS.Princeton.EDU>
In article <·························@news.demon.co.uk> ···@this_email_address_intentionally_left_crap_wildcard.demon.co.uk (Martin Rodgers) writes:

   Kaz wheezed these wise words:

   > Sorry, I will stick with the old school here. You dope smoking Lisp and Scheme
   > hippies can try your Newspeak on some undergraduate freshmen.

   So, you're saying you don't know, and you don't wish to know? That's 
   what it sounds like.

   Try reading this book:

   Structure and Interpretation of Computer Programs
   MIT Press and McGraw-Hill, Inc.
   ISBN 0-262-01153-0 657 

   It covers this subject in rather more depth than the "dragon" book. 
   See the "Applying compiled procedures" section.

   I can also recommend "LISP in Small Pieces" Christian Queinnec, which 
   has a few things to say about tail calls and continuations.

   Neither of these are "general" compiler books, but you can find SICP 
   listed in the bibliography of "Compilers: Principles, Techniques, and 
   Tools", as well as several other examples (e.g. Church, McCarthy, 
   Steele) of what you might call "dope smoking Lisp and Scheme 
   Newspeak". Curious, eh? Perhaps compiler theory is a subject that is 
   just too big for any one book, making a few compromises necessary. 
   This may be why books like this have such large bibliographies!

You may also want to consider more up-to-date compiler books than the
10+ years Dragon Book.  For example, consider Andrew Appel's "Modern
Compiler Implementation in ..." (Cambridge, 1997).  In particular, see
chapter 15.6 "Efficient Tail Recursion".

-- 
-Matthias
From: Richard RUDEK
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <34358eb2.6426170@news.zeta.org.au>
···@latte.cafe.net (Kaz) wrote:

>In article <·················@nospan.netright.com>,
>David Hanley  <·····@nospam.netright.com> wrote:
>>Mark Wilden wrote:
>>
>>> Chris Webb wrote:
>>> >
>>> > Tail recursion is merely an optimisation where a function returning
>>> > the value of another function can simply include a direct branch to
>>> that
>>> > function instead of a subroutine call.
>>>
>>> I don't think that's true. "When the last statement executed in a
>>> procedure body is a recursive call of the same procedure, the call is
>>> said to be _tail recursive_." Aho, Sethi, Ullman.
>>
>>    I think that's overspecific.  In the general literature, tail
>>recursionrefers to constructs which return the value of another function
>>call.
>
>What general literature? Aho, Sethi and Ullman have produced some fine
>examples of ``general'' literature.
>
>Do you know what a recursive definition is? Or a recursively enumerable set?
>You cannot divorce the concept of self-reference from recursion.   It's
>possible to dilute the meaning of any word to the point that it loses the
>ability to discern fine ideas, but it is seldom necessary to do this.
>
>Sorry, I will stick with the old school here. You dope smoking Lisp and Scheme
>hippies can try your Newspeak on some undergraduate freshmen.
>-- 

I suppose, it depends upon the context or point of view. From a
language/compiler writer/implementor's point of view, a function is
calling a function and this is recursion. 

But many more people will be looking from a user/programmer's point of
view. So in programmer's speak, using the word recursion is
inappropriate here, and a function calling a function is part of a
program.

Are we getting the user's and designer's guides mixed up ?

Is the language old enough to have a user's guide ?

Similar examples of this abound, one being the concept of recursing
sub-directories in a filesystem. Recurse ?.  In the user's manual ?...

I also suppose the concept of elegance faces this same fate.
  __   __   _______________________________
 //)) //)) | Richard RUDEK. MicroDek.      | 
//\\ //\\  | Chatswood, Sydney. Australia. | 
           `-------------------------------'
From: Lawrence Kirby
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <876059878snz@genesis.demon.co.uk>
In article <················@news.zeta.org.au>
           ···@NoMoreSpam.com "Richard RUDEK" writes:

>I suppose, it depends upon the context or point of view. From a
>language/compiler writer/implementor's point of view, a function is
>calling a function and this is recursion. 

No it is not, recursion is something very specific. Recursion is an
algorithmic trick where a problem is solved by solving one or more simpler
instances of the same problem and combining the results. From a
procedural point of view recursion involves a function calling itself
either directly or indirectly (e.g. function a calls function b which calls
function c which calls function a). Similarly you can have recursive
datastructures, for example in C you can define a linked list:

struct List {
    struct List *next;
    int value1, value2;
};

Here the type of one of the structure members refers to the type of the
whole structure hence it is recursive.

>But many more people will be looking from a user/programmer's point of
>view. So in programmer's speak, using the word recursion is
>inappropriate here, and a function calling a function is part of a
>program.
>
>Are we getting the user's and designer's guides mixed up ?

No, you are simply misunderstanding the meaning of "recursion".

>Is the language old enough to have a user's guide ?
>
>Similar examples of this abound, one being the concept of recursing
>sub-directories in a filesystem. Recurse ?.  In the user's manual ?...

That's another good example of recursion. On systems where directories
are defined as entities that contain files and other directories (plus
possibly other miscellaneous things) the definition of a directory is
recursive (i.e. te definition of a directory involves elements that are
also directories). It is becaudse of this recursive nature that general
directory trees are possible.

-- 
-----------------------------------------
Lawrence Kirby | ····@genesis.demon.co.uk
Wilts, England | ·········@compuserve.com
-----------------------------------------
From: William D Clinger
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <343D53C7.6EBC@ccs.neu.edu>
···@latte.cafe.net wrote:
> Do you know what a recursive definition is?
> Or a recursively enumerable set?
> You cannot divorce the concept of self-reference from recursion.

A recursive definition is either a primitive recursive definition
or a definition by minimization of a primitive recursive function.

A recursively enumerable set is a set that can be generated by
some Turing machine.

Both of these standard definitions illustrate the fact that the
concept of recursion, as that concept is used in both computer
science and in mathematics, is not necessarily wedded to immediate
self-reference.

Immediate self-reference is just a special case of recursion.

Knowing Ravi Sethi, and considering also the number of chapters
devoted to Scheme and Standard ML in his undergraduate text on
programming languages, I can't believe that he meant for this
one sentence

    When the last statement executed in a procedure body is
    a recursive call of the same procedure, the call is
    said to be _tail recursive_."

to be taken as a general definition of tail recursion.  In context,
however, his sentence makes pedagogical sense: To illustrate tail
recursion optimization for the second edition of the dragon book,
he needed a simple explanation of tail recursion.  He wasn't trying
to make a definitive statement about tail recursion.

Kaz also wrote:
> You dope smoking Lisp and Scheme hippies...

That's the nicest thing anyone has called me in a long time.
On the net, anyway.  :-)

Will
From: Torkel Franzen
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <vcbk9fm15zs.fsf@sm.luth.se>
William D Clinger <····@ccs.neu.edu> writes:

  >A recursive definition is either a primitive recursive definition
  >or a definition by minimization of a primitive recursive function.

  There are a couple of nits to pick in this. (i) A recursive function
definition is simply a definition that directly or indirectly uses the
function being defined. A recursive function definition does not necessarily
define a computable partial function. (ii) Not every computable
partial function can be defined by minimization of a primitive
recursive function.

  >A recursively enumerable set is a set that can be generated by
  >some Turing machine.

  In this there are no nits to pick.

  >When the last statement executed in a procedure body is
  >a recursive call of the same procedure, the call is
  >said to be _tail recursive_."

  Regardless of what Ravi Sethi did or did not intend, this is the
standard definition of "tail recursive".
From: Tom Payne
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <625ihf$jb6$1@skylark.ucr.edu>
In comp.lang.c++ Torkel Franzen <······@sm.luth.se> wrote:
: William D Clinger <····@ccs.neu.edu> writes:

:   >A recursive definition is either a primitive recursive definition
:   >or a definition by minimization of a primitive recursive function.

[...]
: A recursive function
: definition is simply a definition that directly or indirectly uses the
: function being defined. 

The following is a bit off topic, but the question of "What is
recursion?" seems to keep recurring in these groups.  So, here's my
two-cents worth.


The most appropriate term for a *justified* circular definition is
"fixed-point definition."  Such definitions have the form:

             f(x) = ... x ... f ...

where the right hand side is some expression involving x and f.
Occasionally, additional equations are required to achieve uniqueness.
For instance, the following cirucular definition

             f(x) = f'(x)

(together with the equations f(0) = 1) defines the exponential function.
             
Such definitions are called a fixed-point definition, because a
function f satisfies the defining equation if and only if it is a
fixed point of the operator that map any function f to the function
lambda x [ ... x ... f ...].

Fixed-point theorems guarantee the existence of solutions to such
equations when the defining expressions are suitably restricted.  The
main categories of fixed-point theorems that I know of are:

  * Convergence theoretic fixed point theorems, which are used in
    analysis, e.g., differential equations.

  * Diagonal arguments, which are based on the fact that any function
    that maps the diagonal of a possibly infinite matrix (aka, binary
    function) to one of its rows has a fixed point where that row
    intersects the diagonal.  Throughout logic, diagonal arguments
    are used to justify definitions involving self reference.  Kleene's 
    second recursion theorem is such a result.  It allows procedures
    to be defined in terms of their own text, e.g., 
         
        p(x) = (your halt detector says that p halts) ? p(x) : 0;

  * Order theoretic fixed-point results, such as Tarski's fixed-
    point theorem and Zermelo's fixed-point theorem.  

The general (transfinite) recursion theorem justifies circular
definitions of the form:
   
            f(x) = ... x ... f|x ...    

where f|x denotes the restriction of f to the predecessors of x under
some well-founded relation (i.e., a relation having no infinite chains
of predecessors).  It is order-theoretic and can be proved as an easy
correlary to Zermelo's fixed-point theorem.  Normally, this is what I
think of when I hear the term "recursion," i.e., a function being
defined in terms of its "previous" values.

So, where does this leave recursion as we know it in programming
languages, i.e., recursion where a function calls itself or another
function that in turn invokes the first, etc.?  Those are functions
whose definitions have forms such as:

            f(x) = ... x ... f(...x...) ...

Since self-invocation is a special case of self-reference, we can
easily justify such definitions via a diagonal agument, in particular
Kleene's second recursion theorem.  Alternatively, we can use general
recursion to define a sequence of machine states (essentially
course-of-values recursion) to justify such a definition of f.  In
that case, we are using an order-theoretic fixed-point theorem.  So,
circularity involving self invocation seems to fall into both
categories.

Tom Payne
From: Matthias Blume
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <izraa6ckp5.fsf@mocha.CS.Princeton.EDU>
In article <·················@nospan.netright.com> David Hanley <·····@nospan.netright.com> writes:

   Mark Wilden wrote:

   > Chris Webb wrote:
   > >
   > > Tail recursion is merely an optimisation where a function returning
   > > the value of another function can simply include a direct branch to
   > that
   > > function instead of a subroutine call.
   >
   > I don't think that's true. "When the last statement executed in a
   > procedure body is a recursive call of the same procedure, the call is
   > said to be _tail recursive_." Aho, Sethi, Ullman.

       I think that's overspecific.  In the general literature, tail
   recursionrefers to constructs which return the value of another function
   call.
   In this case,

   a()
   {
       return b()
   }

       Is tail recusrion, as, instead of calling b, a can jump directly to
   b,
   saving invaluable clock cycles.. :)

No, so far that's a tail _call_.  It depends on what b does whether or
not you have a case of tail recursion.

       The name is confusing.  I suspect this has this name because the
   general
   optimization is the same, though perhaps it should be called
   'tail call elimination'.  This would help eliminate confusion.

That _is_ what it is called.

-- 
-Matthias
From: Robert White
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <343B182E.1D73CBC@pobox.com>
David Hanley wrote:

>     I think that's overspecific.  In the general literature, tail
> recursionrefers to constructs which return the value of another function
> call.

Actually this is not what the "correct" general literature calls tail
recursion.  This may well be what some people have mis-labeled tail
recursion, but in order for something to be recursion of any sort it must
involve something that "recurs" (or re-occurs).

I will cede that the term may be mutating away from it's correct meaning
because of a recient spate of imprecise usage, but it is *NOT* what the
phrase is supposed to mean.

I have seen and known published and presumably "learned" professors (I
worked in education for quite some time 8-) who taught their beginning
students that a 5.25" disk was a "floppy disk" while a 3.5" disk was a "hard
disk".  Published misuse of a term by fools (anybody can get published these
days, take a *REAL* close look at the IDG Books "CGI BIBLE" for an example
of "just anybody" getting published 8-) does not make that usage of a term
correct.

Tail Recursion is a spesific set of behaviors that involve *INVOKING* a
*RECURSIVE* piece of logic as the last step of that very piece of logic.  It
has nothing to do with "RETURNING" a blasted thing.  Go find a good book on
parsing, or even a useful one (The "Nutshell" book on LEX and YACC being a
good easy read that will visit this topic), and see why things like Tail
Recursive Grammers (and hence any logic) are an interesting and complex
issue that is orders of magnitude more significant in many forms of
automated and theoretical logic than the pitifully obvious topic of how "you
can just do a jump instead of a call to enter a function who's invocation is
the last thing that happens in another function"

Simplifying the whole body of theory in this area like that is like saying
"law is about the bad things that can happen to you if you steal somthing"
The statement is a gross simplification and is also simply not true. (as
there are plenty of bad things that can happen to you if you steal something
that don't involve the law at all, like if the thing you steal turns out to
be bio-toxic and you didn't know that...)

Please people, precision is important and the fact that some vague "they"
were impresice is not an acceptable excuse.

Rob.

PS to reply to this via email, humans must demangle the address
From: Matthias Blume
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <izsoumcs52.fsf@rant.cs.princeton.edu>
In article <············@mWilden.com> Mark Wilden <····@mWilden.com> writes:

   Chris Webb wrote:
   > 
   > Tail recursion is merely an optimisation where a function returning
   > the value of another function can simply include a direct branch to that
   > function instead of a subroutine call.

   I don't think that's true. "When the last statement executed in a
   procedure body is a recursive call of the same procedure, the call is
   said to be _tail recursive_." Aho, Sethi, Ullman.

   We may use terms in illogical ways some times, but in this case, for
   something to be tail-recursive, we at least require that it also be
   recursive, i.e. call itself directly or indirectly.

Aha, the word "indirectly" is the key!  If the compiler is supposed to
eliminate tail recursion that goes through indirect self-calls, then
it better optimizes _all_ tail call, as statically it is generally
undecidable whether or not a function calls itself indirectly.  (Hint:
Think about function pointers or separate compilation.)


-- 
-Matthias
From: Dennis Weldy
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <UDJ0$Ifz8GA.157@news2.ingr.com>
 

David Hanley wrote in article <·················@nospan.netright.com>...

>Kaz wrote:
>> I looked through the ANSI/ISO C standard forwards and backwards but
>> could not
>> find any references to a stack. The C language leaves calling
>> conventions up
>> to the implementation. C has no disavantage here compared to any other
>>
>> language.
>
>    You are incorrect.  There's somethig called the ABI that is
>designedto allow linkage between code produced by different C compilers
>on the same platform.  It specifies quite a bit, including calling
>convention.
>And, yes, the C convention is not necessarily the best for modern
>platforms.  That's to be expected, as these ABI's were defined quite
>awhile ago,

Hmm.. Ok, are the ABI's part of the draft standard?
Of course, if it specs  for copmpilers on the same platform, then this'd be
an implementation-specific feature fr that platform. Hopefully the flks
specing that would be conversant as to whats the best calling convention
for that platform. 

Dennis
From: David Hanley
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <343193D9.EF6FE75E@nospan.netright.com>
Dennis Weldy wrote:

>
>
> David Hanley wrote in article
> <·················@nospan.netright.com>...
>
> >    You are incorrect.  There's somethig called the ABI that is
> >designedto allow linkage between code produced by different C
> compilers
> >on the same platform.  It specifies quite a bit, including calling
> >convention.
> >And, yes, the C convention is not necessarily the best for modern
> >platforms.  That's to be expected, as these ABI's were defined quite
> >awhile ago,
>
> Hmm.. Ok, are the ABI's part of the draft standard?

    I don't think so, but that doesn't mean that they're not important.

    Actually, this is where a VM architecture like JAVA can be really
good, I think.  The VM can decode what the best calling convention
is, and dynamically compile the code that way...


> Of course, if it specs  for copmpilers on the same platform, then
> this'd be
> an implementation-specific feature fr that platform. Hopefully the
> flks
> specing that would be conversant as to whats the best calling
> convention
> for that platform.

    It's not always that simple.  There are issues such as
cross-languagecalling, legacy code, portign other compilers, etc,etc.

    dave

    dave
From: Dennis Weldy
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <4lE2v3nz8GA.188@news2.ingr.com>
  Kaz mentioned the ANSI/ISO spec looking for a stack. Then mentioned that
the C language leaves calling convention up to the implementation. If the
ABI's are NOT part of the draft, then he was correct in stating that C has
no more a disadvantange than other languages in that regardm contrary to
what y'said about being "incorrect". 

Sure, they would be important, but if the spec changes on a per-platform
bass, then it's not the job of the ANSI committee to spec this, but rather
the compiler vendors for that platform, taking in the factors which you
mention. 


David Hanley wrote in article <·················@nospan.netright.com>...

>Dennis Weldy wrote:
>
>>
>>
>> David Hanley wrote in article
>> <·················@nospan.netright.com>...
>>
>> >    You are incorrect.  There's somethig called the ABI that is
>> >designedto allow linkage between code produced by different C
>> compilers
>> >on the same platform.  It specifies quite a bit, including calling
>> >convention.
>> >And, yes, the C convention is not necessarily the best for modern
>> >platforms.  That's to be expected, as these ABI's were defined quite
>> >awhile ago,
>>
>> Hmm.. Ok, are the ABI's part of the draft standard?
>
>    I don't think so, but that doesn't mean that they're not important.
>
>    Actually, this is where a VM architecture like JAVA can be really
>good, I think.  The VM can decode what the best calling convention
>is, and dynamically compile the code that way...
>
>
>> Of course, if it specs  for copmpilers on the same platform, then
>> this'd be
>> an implementation-specific feature fr that platform. Hopefully the
>> flks
>> specing that would be conversant as to whats the best calling
>> convention
>> for that platform.
>
>    It's not always that simple.  There are issues such as
>cross-languagecalling, legacy code, portign other compilers, etc,etc.

thats one reason they have extern <language>, at least that's in the C++
standard. 
>
>    dave
>
>    dave
>
>.
> 
From: Kaz
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <60tekq$24p$1@latte.cafe.net>
In article <···············@news2.ingr.com>,
Dennis Weldy <··········@ever.com> wrote:
>  Kaz mentioned the ANSI/ISO spec looking for a stack. Then mentioned that
>the C language leaves calling convention up to the implementation. If the
>ABI's are NOT part of the draft, then he was correct in stating that C has
>no more a disadvantange than other languages in that regardm contrary to
>what y'said about being "incorrect". 

The ABI's are not even mentioned at all. C is an abstract language. It
has a concept of ``automatic storage''. Function parameters and local (auto)
variables are in this storage. 

>Sure, they would be important, but if the spec changes on a per-platform
>bass, then it's not the job of the ANSI committee to spec this, but rather
>the compiler vendors for that platform, taking in the factors which you
>mention. 

That is correct. 

The abstract defintion of the C language does pose some optimization problems.
Firstly, C programs are divided into translation units. An implementation
translates a unit independently of the others. Combination of the translated
units happens at a linking stage. In principle, a C implementation could
consider all translation units at once, but it need not do so, and is
required to support separate translation (since the standard explicitly
states that ``[a] C program need not be translated all at at the same time''
and ``[p]reviously translated translation units may be preserved individually
or in libraries''.

Within a translation unit, ``anything goes'' as far as optimization is
concerned, as long as the visible effects of the program agree with certain
minimum requirements. It's possible to have tail call elimination, procedural
integration, detailed pointer aliasing analysis, etc.

Across translation unit boundaries, many kinds of optimizations are difficult
to do.  For example, currently only some cutting-edge experimental C compilers
perform optimizations such as procedural integration of code from a previously
translated unit.
-- 
From: Robert White
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <343B13ED.FE9234D5@pobox.com>
Please note: I am any of the quoted persons below...

David Hanley wrote:

> Kaz wrote:
>
>
> int foo( int code , float blah )
> {
>    if ( ............. ) return this( code );
>   else if  ( .............. ) return that( blah );
>   else return the_other( code,blah );
> }
>
>     That's tail-recursion, and it's not a loop, and it makes you
> look silly for saying that this can be done.

BZZZZZT! Thank you for playing, there are some lovely parting gifts waiting
for you back-stage.  The code above is *NOT* tail recursion unless
"the_other(...)" ends up calling foo again.  "Recursion" requires that the
function in question recur (as in re-occur, hence the word) on the stack
while a prior version is still active.  To be recursive a function F() must
call F(), or some other function(s) that then call(s) F().  (The former is
"direct" recursion, the latter is "indirect" recursion).  In the case of
"direct tail recursion" the body of F() is run through N times and so can be
converted to a loop of N iterations.  Inlining and such can cause an
indirect tail recursion to become a direct tail recursion, but barring that
most compliers can not detect indirect tail recursion in most cases.

I suggest a diet of heavy theoretical reading before you again start
correcting people about things subtle or sublime.

It is AXIOMATIC that a tail-recursive procedure (function, whatever) can be
converted to a loop.  (If you don't know what axiomatic means you will no
doubt try to disprove this 8-)

Being self-taught (which you clearly are, unless you selpt through some
classes) is no excuse for being rude when you are out of your element.  I am
self taught but I know when I am inside or outside the domain of "things I
know aobut well enought to go around correcting people".  I suggest you do
some introspection in this area.

Rob.

PS Humans needs-must demangle this email address to respond to this message
in email.  (I hate spam 8-)
From: Alicia Carla Longstreet
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <343B8613.3C75@ici.net>
Robert White wrote:

You might want to take note of the fact that there are two definitions
of tail-recursion posted on the `Net.  One definition is as you
suggested, a true recursive function, the other is *not* recursion at
all, but is like the code presented.

> PS Humans needs-must demangle this email address to respond to this message
> in email.  (I hate spam 8-)

-- 

Education is a companion which no misfortune can depress,
no crime can destroy, and no enemy can alienate...
at home a friend, abroad an introduction,
in solitude a solace, and in society and ornament.
                                Joseph Addison.
************************************************

You can't use void main() I have a patent on it!

************************************************
*  Alicia Carla Longstreet     ·····@ici.net   *
*    Remove the _JUNK_ when replying to me.    *
************************************************
From: Lynton Alan Fletcher
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <343C3CB9.456E5795@camtech.net.au>
My two cents worth:

ADA and LISP are the most elegant languages.
Ada is the Kwasitz Haderach of the Pascal-like family of programming languages;
more thought
has gone into the design of Ada than anything else, which is why it's trusted for
the
most critical defence applications.

LISP represents recursion and artificial intelligence truly elegantly.
People moan about the brackets. Indent eg.
    (
        ( LISP statement )
    )

Cheers,
Lynton Fletcher
From: Matthew M. Huntbach
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <61vk67$ssh$9@beta.qmw.ac.uk>
Lynton Alan Fletcher (·······@camtech.net.au) wrote:
> My two cents worth:

> Ada is the Kwasitz Haderach of the Pascal-like family of programming 
> languages; more thought has gone into the design of Ada than anything else, 
> which is why it's trusted for the most critical defence applications.

It suffers badly from having been designed just before the widespread
acceptance of the insights that led to object-oriented programming becoming
the dominant paradigm. 

> LISP represents recursion and artificial intelligence truly elegantly.
> People moan about the brackets. Indent eg.

It's a mess. Any more modern functional programming langauge beats it in
elegance.

Matthew Huntbach
From: Chris Bitmead
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <m3ra9n16ph.fsf@thepla.net>
···@dcs.qmw.ac.uk (Matthew M. Huntbach) writes:
> > LISP represents recursion and artificial intelligence truly elegantly.
> > People moan about the brackets. Indent eg.
> 
> It's a mess. Any more modern functional programming langauge beats it in
> elegance.

How can you call something so simple a mess? You may personally feel
that some other language is better, but I can't imagine it would be
much simpler, and something so simple in concept can't be messy.
From: Bill Gribble
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <87ra9ndrew.fsf@firetrap.csres.utexas.edu>
Chris Bitmead <······@thepla.net> writes:
> How can you call something so simple a mess? 

"Common LISP: The Language, 2nd edition" is 1029 pages long.  I don't
call that "simple". p. 586 et seq (sec 22.3.3 for those of you
following along at home) describe in some depth the requirements *in
the language spec* for Common LISP dealing with numbers represented as
Roman numerals, both modern ("IV") and "old" ("IIII").

I call any language that mandates handling of Roman numerals in its
language definition "a mess."  Don't confuse the simplicity and
elegance of LISP's syntax (at least compared with C/C++) with
simplicity and elegance of the language itself.

Let me qualify this by saying that I would rather program in Common LISP
than C++ any day; I'd just prefer Scheme to both.  

Bill Gribble
From: Michael Davis
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <622m2v$6lv$1@mpsrv3.multipath.com>
In article <··············@firetrap.csres.utexas.edu>,
Bill Gribble  <····@cs.utexas.edu> wrote:
>Chris Bitmead <······@thepla.net> writes:
>> How can you call something so simple a mess? 
>
>"Common LISP: The Language, 2nd edition" is 1029 pages long.  I don't
>call that "simple". p. 586 et seq (sec 22.3.3 for those of you
>following along at home) describe in some depth the requirements *in
>the language spec* for Common LISP dealing with numbers represented as
>Roman numerals, both modern ("IV") and "old" ("IIII").
>

Don't confuse the language with the standard library, or function set
or whatever you want to call it.

The _language_ of Lisp is very small and simple, especially when compared
to C++. ( I like both languages myself, this is not a criticism of either ).

Both come with extensive libraries.

I've got "Common LISP: The Language, 2nd edition" sitting on my shelf,
and it is quite large, but it's mostly function descriptions.
Printing numbers using Roman numberals is a library function,
not an inherent feature of the library.

Similarly, the iostreams library is just that - a _library_, not
a built-in feature of the C++ _language_.

>I call any language that mandates handling of Roman numerals in its
>language definition "a mess."  Don't confuse the simplicity and
>elegance of LISP's syntax (at least compared with C/C++) with
>simplicity and elegance of the language itself.

The elegance of the syntax _is_ the elegance of the language.
Don't confuse the size of the library with the syntax of the language!

>Let me qualify this by saying that I would rather program in Common LISP
>than C++ any day; I'd just prefer Scheme to both.  
>
>Bill Gribble

I've heard great things about Scheme, I might check it out some time.


-- 
// Michael Davis, Programmer/Analyst      I don't speak for Multipath.  //
// ······@DELmultipath.com                Nor do I speak against them.  //
// Toronto             The 'DEL' in my address is an anti-spam device.  //
From: Erik Naggum
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <3085946866762678@naggum.no>
* Bill Gribble
| "Common LISP: The Language, 2nd edition" is 1029 pages long.  I don't
| call that "simple". p. 586 et seq (sec 22.3.3 for those of you following
| along at home) describe in some depth the requirements *in the language
| spec* for Common LISP dealing with numbers represented as Roman numerals,
| both modern ("IV") and "old" ("IIII").

perhaps you should actually read those pages?  they're about _printing_
numbers in Roman style, not "dealing" with them.  it's strictly an output
feature, part of the admittedly enormous `format' function and _language_.

| I call any language that mandates handling of Roman numerals in its
| language definition "a mess."

I have a few words for people who can't be bothered to read carefully, too.
however, I don't find any particular reason to share them right now.

#\Erik
-- 
if you think this year is "97", _you_ are not "year 2000 compliant".

see http://www.naggum.no/emacs/ for Emacs-20-related material.
From: Bill Gribble
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <8767qymrda.fsf@firetrap.csres.utexas.edu>
Erik Naggum <······@naggum.no> writes:
> * Bill Gribble
> | "Common LISP: The Language, 2nd edition" is 1029 pages long.  I don't
> | call that "simple". p. 586 et seq (sec 22.3.3 for those of you following
> | along at home) describe in some depth the requirements *in the language
> | spec* for Common LISP dealing with numbers represented as Roman numerals,
> | both modern ("IV") and "old" ("IIII").
> 
> perhaps you should actually read those pages?  they're about _printing_
> numbers in Roman style, not "dealing" with them.  it's strictly an output
> feature, part of the admittedly enormous `format' function and _language_.

...doth protest too much.

Clearly, I've either read those pages or I have a phenomenal list of
niggling citations to things that I haven't read.  I'll let you in on
the fact that I have read CLTL2, way more than I want to admit, and I
was being argumentative.

Furthermore, my advisor (Ben Kuipers) was a student of Marvin Minsky
and claims to have himself implemented the first Roman numeral format
routines for Lisp at MIT, and has a very funny anecdote about
circulating an AI Lab memo which eventually led to the inclusion of
Roman numerals in the format spec.

Admittedly, "format" is a language in and of itself.  So is "loop".
However, the fact remains that any Lisp that can claim to be "Common
LISP" must have the ability to print Roman numerals according to my
citation.  That's a bizarre and ridiculous thing to include in a
language, and is representative of lots of other bizarre and
ridiculous things that are included in Common LISP.  Although format
and loop are part of the "library" and not the "syntax" of Common LISP
(well, loop is syntax but I'll pretend), they are a part of the
language, and if you embrace Common LISP you must also embrace format
and loop.

Maybe this is the wrong set of newsgroups to have discussions about
the real merits and drawbacks of Common LISP.  I hope you can
understand that I have real affection for the language, including all
its bizarre baggage.  I am forced to write perl and c++ every day, and
getting to write Scheme or Common LISP is a pleasure that makes it
worthwhile.  Actually, perl has its pleasures too (then again, so does
any kind of masochism.. I'll drop the subject). But don't let the
wonderfulness of Common LISP make you blind to its flaws.  Which are
legion.

I have never seen a language that made me fall over in pure bliss, and
I've been looking for a while.  That's a language that I could write a
device driver or OS in, but whose elegance and expressiveness would
make me want to try to write HAL in.  The closest I have come so far
is the hacked-up Scheme that I'm currently using (RScheme) but it's
pretty far from perfect.  As far as I can tell, parenthesized syntax
is an absolute requirement, if only for the purposes of having a real
macro system (RScheme's may be even better than Common LISP's).  The
one more thing I want is a decent type-inference system.  I hear
DrScheme has something like this.  Haven't tried it.

Bill Gribble
From: Erik Naggum
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <3086024401123307@naggum.no>
* Bill Gribble
| Although format and loop are part of the "library" and not the "syntax"
| of Common LISP (well, loop is syntax but I'll pretend), they are a part
| of the language, and if you embrace Common LISP you must also embrace
| format and loop.

well, this is where we will have to agree to disagree.  you don't _have_ to
know and use `format' and `loop' to embrace Common Lisp as a programmer,
but you _have_ to know about lambda lists, macros, `setf', etc.  I think
the former are a matter of practical elegance in the code, and the latter a
matter of elegant language design.

other than this point, we're in harmony.

#\Erik
-- 
if you think this year is "97", _you_ are not "year 2000 compliant".

see http://www.naggum.no/emacs/ for Emacs-20-related material.
From: Ian Collier
Subject: Roman Numerals (Re: What is the most "Elegant" Language?)
Date: 
Message-ID: <12119-Athabascan.imc@comlab.ox.ac.uk>
In article <··············@firetrap.csres.utexas.edu>, Bill Gribble <····@cs.utexas.edu> wrote:
>However, the fact remains that any Lisp that can claim to be "Common
>LISP" must have the ability to print Roman numerals according to my
>citation.  That's a bizarre and ridiculous thing to include in a
>language

TeX has the same requirement, but it isn't so bizarre and ridiculous there...
-- 
---- Ian Collier : ···@comlab.ox.ac.uk : WWW page below
------ http://www.comlab.ox.ac.uk/oucl/users/ian.collier/imc.html
From: Marco Antoniotti
Subject: Re: Roman Numerals (Re: What is the most "Elegant" Language?)
Date: 
Message-ID: <scf3elxljl4.fsf@ferrari.PATH.Berkeley.EDU>
In article <····················@comlab.ox.ac.uk> ···@ecs.ox.ac.uk (Ian Collier) writes:

   From: ···@ecs.ox.ac.uk (Ian Collier)
   Newsgroups: comp.lang.lisp,comp.lang.misc,comp.lang.scheme
   Date: 16 Oct 1997 12:49:13 GMT
   Organization: Oxford University Computing Laboratory
   Lines: 10
   X-Local-Date: Thursday, 16th October 1997 at 1:49pm BST
   X-Spammers: Warning: I have a procmail filter and I'm prepared to use it.
   Xref: agate comp.lang.lisp:31379 comp.lang.misc:32162 comp.lang.scheme:23483

   In article <··············@firetrap.csres.utexas.edu>, Bill Gribble <····@cs.utexas.edu> wrote:
   >However, the fact remains that any Lisp that can claim to be "Common
   >LISP" must have the ability to print Roman numerals according to my
   >citation.  That's a bizarre and ridiculous thing to include in a
   >language

Yep.  This is a bit of an overkill.  But then again, not having the
ability to explicitily write binary numbers (as in some high level
language) is a sorely missing thing.
-- 
Marco Antoniotti
==============================================================================
California Path Program - UC Berkeley
Richmond Field Station
tel. +1 - 510 - 231 9472
From: William Paul Vrotney
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <vrotneyEI4H9D.M6p@netcom.com>
In article <··············@firetrap.csres.utexas.edu> Bill Gribble
<····@cs.utexas.edu> writes:

> 
> Chris Bitmead <······@thepla.net> writes:
> > How can you call something so simple a mess? 
> 
> "Common LISP: The Language, 2nd edition" is 1029 pages long.  I don't
> call that "simple". p. 586 et seq (sec 22.3.3 for those of you
> following along at home) describe in some depth the requirements *in
> the language spec* for Common LISP dealing with numbers represented as
> Roman numerals, both modern ("IV") and "old" ("IIII").

I hate posting to this thread crossing to all these newsgroups!  But, you
sucked me in, I don't want people to get a false impression of Lisp that the
enclosed post might imply.

The elegance of Common Lisp is basically depicted in only 25 pages of CLTLII
(p 69-94 Program Structure Chapter 5) the rest of it should be thought of as
library, similar to a C++ library.  The reason being that in Chapter 5 it
defines the lambda, special form and macro.  On page 73 are the 24 special
forms of Common Lisp.  *Everything* else is either a function or macro.
*Not* a mess at all!

> 
> I call any language that mandates handling of Roman numerals in its
> language definition "a mess."  Don't confuse the simplicity and
> elegance of LISP's syntax (at least compared with C/C++) with
> simplicity and elegance of the language itself.

The Roman Numeral stuff is for formatted output presentation (FORMAT
function).  This is similar to a C++ or Scheme library for formatting Roman
Numerals.  Again, *not* a mess at all!  Lisp's simplicity and elegance
extends beyond its syntax.

The whole FORMAT function is quite powerful and quite large and is used as a
convenience.  A programmer can do everything that the FORMAT function can do
using just the simple print functions.

> 
> Let me qualify this by saying that I would rather program in Common LISP
> than C++ any day; 
> 

Me too.  I think this goes for a lot of people.  So let's rediscover Common
Lisp!  

For the few who posted to this thread that claimed that C++ is an elegant
language should read more carefully (as a language implementor would need)
all of the annotations in Ellis/Stroupstrup "The Annotated C++ Reference
Manual".

> I'd just prefer Scheme to both.  

Scheme is nice and should probably be considered the most elegant of all
existing programming languages.  However, there are two caveats to this.
One, Scheme is really a dialect of Lisp, it just happens to be called
Scheme.  Two, Scheme *in my mind* violates Einstein's "should be no simpler"
principle of simplicity.  That is to say in reality we seem to need a lot of
the stuff that Common Lisp provides.  In fact, an example of this is the
huge FORMAT function discussed above.  It really is not fundamentally
necessary, but it sure is nice for prototyping.
-- 

William P. Vrotney - ·······@netcom.com
From: Lawrence Kirby
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <877181321snz@genesis.demon.co.uk>
In article <·················@netcom.com>
           ·······@netcom.com "William Paul Vrotney" writes:

...

>The elegance of Common Lisp is basically depicted in only 25 pages of CLTLII
>(p 69-94 Program Structure Chapter 5) the rest of it should be thought of as
>library, similar to a C++ library.  The reason being that in Chapter 5 it
>defines the lambda, special form and macro.  On page 73 are the 24 special
>forms of Common Lisp.  *Everything* else is either a function or macro.
>*Not* a mess at all!

In C an conforming hosted implementation is required to implement
the standatd library as specified by the standard. That means that the
standard library is very much part of the C language and reflects on the
"elegance" of the language. I suspect the same is true for Common LISP.

-- 
-----------------------------------------
Lawrence Kirby | ····@genesis.demon.co.uk
Wilts, England | ·········@compuserve.com
-----------------------------------------
From: William Paul Vrotney
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <vrotneyEIA1MM.Lyv@netcom.com>
In article <············@genesis.demon.co.uk> ····@genesis.demon.co.uk
(Lawrence Kirby) writes:

>   In article <·················@netcom.com>
>              ·······@netcom.com "William Paul Vrotney" writes:
>
>   ...
>
>   >The elegance of Common Lisp is basically depicted in only 25 pages of CLTLII
>   >(p 69-94 Program Structure Chapter 5) the rest of it should be thought of as
>   >library, similar to a C++ library.  The reason being that in Chapter 5 it
>   >defines the lambda, special form and macro.  On page 73 are the 24 special
>   >forms of Common Lisp.  *Everything* else is either a function or macro.
>   >*Not* a mess at all!
>
>   In C an conforming hosted implementation is required to implement
>   the standatd library as specified by the standard. That means that the
>   standard library is very much part of the C language and reflects on the
>   "elegance" of the language. I suspect the same is true for Common LISP.
>

Good point.  The analogy "similar to the ANSI C library" instead of "similar
to a C++ library" would have been more poignant.

ANSI C is an elegant language (note the ANSI).  However, ANSI C is not as
elegant as Common Lisp.  I would agree with many scientists who hold the
view that it is difficult to define elegance but we know it when we see it.
Those scientists use elegance as a driving principle for research.  For
example the DNA molecule might not have been uncovered without it.  At least
how it went with Watson (or Crick?) in the story that I remembered ... "It
[DNA] *has* to be simple and beautiful, so what are we missing?".  Of
course, to keep a proper perspective on this matter of elegance one should
delineate computer *science* and computer *engineering*.  Do elegantly
designed bridges withstand more stresses?

-- 

William P. Vrotney - ·······@netcom.com
From: Dave I. Saunders
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <62fhp1$36n$1@beta.qmw.ac.uk>
William Paul Vrotney (·······@netcom.com) wrote:

: Do elegantly designed bridges withstand more stresses?

No.  Have a look at pictures of the Tacoma Straits bridge:

before the dance: elegant
during the dance: elegant
at the end: very inelegant
From: Dave I. Saunders
Subject: [Reposted due to Enlow UCE cancel]: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <REPOST-25136.232879638672.62fhp1$36n$1@beta.qmw.ac.uk>
William Paul Vrotney (·······@netcom.com) wrote:

: Do elegantly designed bridges withstand more stresses?

No.  Have a look at pictures of the Tacoma Straits bridge:

before the dance: elegant
during the dance: elegant
at the end: very inelegant
========= WAS CANCELLED BY =======:
Rogue cancel from Michael Enlow, X-Cancelled-by etc.  are forged.
Further information can be acquired at http://www.sputum.com/ucepage.htm,
or http://rampages.onramp.net/~eholmes/enlow/enlowce.html

You can express your displeasure with Mr. Enlow by contacting him at:
·····@direcpc.com
Control: cancel <············@beta.qmw.ac.uk>
Newsgroups: comp.lang.prolog
Path: ...!news.tamu.edu!bcm.tmc.edu!news.msfc.nasa.gov!europa.clark.net!204.59.152.222!news-peer.gsl.net!news-tokyo.gip.net!news.gsl.net!gip.net!nspixp!newsfeed.btnis.ad.jp!newsfeed1.btnis.ad.jp!news.fsinet.or.jp!ubc.co.jp!nobody
From: ······@pagesz.net
Subject: cmsg cancel <············@beta.qmw.ac.uk>
Approved: ······@pagesz.net
Message-ID: <···················@beta.qmw.ac.uk>
X-No-Archive: Yes
Sender: ·····@dcs.qmw.ac.uk (Dave I. Saunders)
X-Cancelled-By: ······@pagesz.net
Organization: UBC
Date: Tue, 21 Oct 1997 02:31:53 GMT
Lines: 2


This article cancelled within Tin.
From: Ken Tilton
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <344A4E2D.3B9F@bway.net>
Lawrence Kirby wrote:
> 
> That means that the
> standard library is very much part of the C language ...

Would you say null-terminated strings are part of C?

  Ken
From: Kaz
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <62gjph$kl4$1@latte.cafe.net>
In article <·············@bway.net>, Ken Tilton  <····@bway.net> wrote:
>Lawrence Kirby wrote:
>> 
>> That means that the
>> standard library is very much part of the C language ...
>
>Would you say null-terminated strings are part of C?

Of course! In many contexts, string literals are actually objects of type
array of char which hold null terminated strings. The language explicitly
supports null terminal strings in the form of these string literals.
for example:

    char *string = "Hello, world\n";	/* null terminated */

Of course, the standard library functions for string manipulations assume this
representation as well.
-- 
From: Ken Tilton
Subject: [Reposted due to Enlow UCE cancel]: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <REPOST-2698.9176330566406.344A4E2D.3B9F@bway.net>
Lawrence Kirby wrote:
> 
> That means that the
> standard library is very much part of the C language ...

Would you say null-terminated strings are part of C?

  Ken
========= WAS CANCELLED BY =======:

Rogue cancel from Michael Enlow, X-Cancelled-by etc. are forged.
Further information can be acquired at http://www.sputum.com/ucepage.htm
You can express your displeasure with Mr. Enlow by contacting him at:
·····@direcpc.com

Control: cancel <·············@bway.net>
Newsgroups: comp.lang.prolog
Path: ...!news.starnet.net!newspump.wustl.edu!rice!bcm.tmc.edu!news.msfc.nasa.gov!newsfeed.internetmci.com!204.59.152.222!news-peer.gsl.net!news-tokyo.gip.net!news.gsl.net!gip.net!nspixp!newsfeed.btnis.ad.jp!newsfeed1.btnis.ad.jp!news.fsinet.or.jp!ubc.co.jp!nobody
From: ······@pagesz.net
Subject: cmsg cancel <·············@bway.net>
Approved: ······@pagesz.net
Message-ID: <····················@bway.net>
X-No-Archive: Yes
Sender: Ken Tilton <····@bway.net>
X-Cancelled-By: ······@pagesz.net
Organization: UBC
Date: Tue, 21 Oct 1997 02:31:13 GMT
Lines: 2


This article cancelled within Tin.
From: Alicia Carla Longstreet
Subject: Re: [Reposted due to Enlow UCE cancel]: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <344CC00E.2292@ici.net>
Ken Tilton wrote:
 
> Lawrence Kirby wrote:

> > That means that the
> > standard library is very much part of the C language ...
 
> Would you say null-terminated strings are part of C?

There goes Mr Lawerence stating his opinion as if it were fact, once
again.  Given his knowledge and understanding, his opinion holds a *lot*
more weight than most, I just wish he wouldn't be quite so arrogant
about it.

-- 
***********************************************************
You have not converted a man because you have silenced him.
                                        Lord John Morley
***********************************************************
Alicia Carla Longstreet     ·····@ici.net
You can't use void main() I have a patent on it!
From: Ken Tilton
Subject: [Reposted due to Enlow UCE cancel]: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <REPOST-15187.536499023438.344A4E2D.3B9F@bway.net>
Lawrence Kirby wrote:
> 
> That means that the
> standard library is very much part of the C language ...

Would you say null-terminated strings are part of C?

  Ken
========= WAS CANCELLED BY =======:

Rogue cancel from Michael Enlow, X-Cancelled-by etc. are forged.
Further information can be acquired at http://www.sputum.com/ucepage.htm
You can express your displeasure with Mr. Enlow by contacting him at:
·····@direcpc.com

Control: cancel <·············@bway.net>
Newsgroups: comp.lang.prolog
Path: ...!news.starnet.net!newspump.wustl.edu!rice!bcm.tmc.edu!news.msfc.nasa.gov!newsfeed.internetmci.com!204.59.152.222!news-peer.gsl.net!news-tokyo.gip.net!news.gsl.net!gip.net!nspixp!newsfeed.btnis.ad.jp!newsfeed1.btnis.ad.jp!news.fsinet.or.jp!ubc.co.jp!nobody
From: ······@pagesz.net
Subject: cmsg cancel <·············@bway.net>
Approved: ······@pagesz.net
Message-ID: <····················@bway.net>
X-No-Archive: Yes
Sender: Ken Tilton <····@bway.net>
X-Cancelled-By: ······@pagesz.net
Organization: UBC
Date: Tue, 21 Oct 1997 02:31:13 GMT
Lines: 2


This article cancelled within Tin.
From: Tom Payne
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <62gp4v$884$3@skylark.ucr.edu>
In comp.lang.c++ Lawrence Kirby <····@genesis.demon.co.uk> wrote:
: In article <·················@netcom.com>
:            ·······@netcom.com "William Paul Vrotney" writes:

: ...

: >The elegance of Common Lisp is basically depicted in only 25 pages of CLTLII
: >(p 69-94 Program Structure Chapter 5) the rest of it should be thought of as
: >library, similar to a C++ library.  The reason being that in Chapter 5 it
: >defines the lambda, special form and macro.  On page 73 are the 24 special
: >forms of Common Lisp.  *Everything* else is either a function or macro.
: >*Not* a mess at all!

: In C an conforming hosted implementation is required to implement
: the standatd library as specified by the standard. That means that the
: standard library is very much part of the C language and reflects on the
: "elegance" of the language. I suspect the same is true for Common LISP.

There is an old saying, with which I fully agree, that "Library design
IS language design."

Tom Payne
From: Tom Payne
Subject: [Reposted due to Enlow UCE cancel]: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <REPOST-5860.8211364746094.62gp4v$884$3@skylark.ucr.edu>
In comp.lang.c++ Lawrence Kirby <····@genesis.demon.co.uk> wrote:
: In article <·················@netcom.com>
:            ·······@netcom.com "William Paul Vrotney" writes:

: ...

: >The elegance of Common Lisp is basically depicted in only 25 pages of CLTLII
: >(p 69-94 Program Structure Chapter 5) the rest of it should be thought of as
: >library, similar to a C++ library.  The reason being that in Chapter 5 it
: >defines the lambda, special form and macro.  On page 73 are the 24 special
: >forms of Common Lisp.  *Everything* else is either a function or macro.
: >*Not* a mess at all!

: In C an conforming hosted implementation is required to implement
: the standatd library as specified by the standard. That means that the
: standard library is very much part of the C language and reflects on the
: "elegance" of the language. I suspect the same is true for Common LISP.

There is an old saying, with which I fully agree, that "Library design
IS language design."

Tom Payne
========= WAS CANCELLED BY =======:

Rogue cancel from Michael Enlow, X-Cancelled-by etc. are forged.
Further information can be acquired at http://www.sputum.com/ucepage.htm
You can express your displeasure with Mr. Enlow by contacting him at:
·····@direcpc.com

Control: cancel <············@skylark.ucr.edu>
Newsgroups: comp.lang.prolog
Path: ...!news.rediris.es!newsfeed.mad.ibernet.es!uunet!in3.uu.net!news.mathworks.com!europa.clark.net!204.59.152.222!news-peer.gsl.net!news-tokyo.gip.net!news.gsl.net!gip.net!nspixp!newsfeed.btnis.ad.jp!newsfeed1.btnis.ad.jp!news.fsinet.or.jp!ubc.co.jp!nobody
From: ······@pagesz.net
Subject: cmsg cancel <············@skylark.ucr.edu>
Approved: ······@pagesz.net
Message-ID: <···················@skylark.ucr.edu>
X-No-Archive: Yes
Sender: Tom Payne <···@cs.ucr.edu>
X-Cancelled-By: ······@pagesz.net
Organization: UBC
Date: Tue, 21 Oct 1997 00:55:21 GMT
Lines: 2


This article cancelled within Tin.
From: Tom Payne
Subject: [Reposted due to Enlow UCE cancel]: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <REPOST-27362.164947509766.62gp4v$884$3@skylark.ucr.edu>
In comp.lang.c++ Lawrence Kirby <····@genesis.demon.co.uk> wrote:
: In article <·················@netcom.com>
:            ·······@netcom.com "William Paul Vrotney" writes:

: ...

: >The elegance of Common Lisp is basically depicted in only 25 pages of CLTLII
: >(p 69-94 Program Structure Chapter 5) the rest of it should be thought of as
: >library, similar to a C++ library.  The reason being that in Chapter 5 it
: >defines the lambda, special form and macro.  On page 73 are the 24 special
: >forms of Common Lisp.  *Everything* else is either a function or macro.
: >*Not* a mess at all!

: In C an conforming hosted implementation is required to implement
: the standatd library as specified by the standard. That means that the
: standard library is very much part of the C language and reflects on the
: "elegance" of the language. I suspect the same is true for Common LISP.

There is an old saying, with which I fully agree, that "Library design
IS language design."

Tom Payne
========= WAS CANCELLED BY =======:

Rogue cancel from Michael Enlow, X-Cancelled-by etc. are forged.
Further information can be acquired at http://www.sputum.com/ucepage.htm
You can express your displeasure with Mr. Enlow by contacting him at:
·····@direcpc.com

Control: cancel <············@skylark.ucr.edu>
Newsgroups: comp.lang.prolog
Path: ...!news.rediris.es!newsfeed.mad.ibernet.es!uunet!in3.uu.net!news.mathworks.com!europa.clark.net!204.59.152.222!news-peer.gsl.net!news-tokyo.gip.net!news.gsl.net!gip.net!nspixp!newsfeed.btnis.ad.jp!newsfeed1.btnis.ad.jp!news.fsinet.or.jp!ubc.co.jp!nobody
From: ······@pagesz.net
Subject: cmsg cancel <············@skylark.ucr.edu>
Approved: ······@pagesz.net
Message-ID: <···················@skylark.ucr.edu>
X-No-Archive: Yes
Sender: Tom Payne <···@cs.ucr.edu>
X-Cancelled-By: ······@pagesz.net
Organization: UBC
Date: Tue, 21 Oct 1997 00:55:21 GMT
Lines: 2


This article cancelled within Tin.
From: Matthew M. Huntbach
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <6285d7$9rv$2@beta.qmw.ac.uk>
Chris Bitmead (······@thepla.net) wrote:
> ···@dcs.qmw.ac.uk (Matthew M. Huntbach) writes:
> > > LISP represents recursion and artificial intelligence truly elegantly.
> > > People moan about the brackets. Indent eg.
> > 
> > It's a mess. Any more modern functional programming langauge beats it in
> > elegance.

> How can you call something so simple a mess? You may personally feel
> that some other language is better, but I can't imagine it would be
> much simpler, and something so simple in concept can't be messy.

One word: SETQ.

Matthew Huntbach
From: Donald Fisk
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <344DE30A.3D0B@bt-sys.bt.spamblock.co.uk>
Matthew M. Huntbach wrote:
> Chris Bitmead (······@thepla.net) wrote:
> > How can you call something so simple a mess? You may personally feel
> > that some other language is better, but I can't imagine it would be
> > much simpler, and something so simple in concept can't be messy.
> 
> One word: SETQ.

Use of setq (or setf) is not compulsory.   It is possible to write
lisp with no destructive assignment statements.   However, for
many problems, the occasional use of destructive assignment is more
natural and/or efficient.   In languages like Haskell, destructive 
assignment is forbidden even when you want it.

One of the advantages of lisp is that so many things are available
but not compulsory, so you can adopt any of a number of different
styles -- functional, procedural, object-oriented.   Things you
like which are absent -- e.g. lazy evaluation, currying, pattern
matching -- are easy to add on, and things you don't like -- e.g.
all those parentheses -- are easy to remove.

Lisp is far more flexible than any other language I know.

> Matthew Huntbach

-- 
Le Hibou (mo bheachd fhe/in: my own opinion)
"What the ... This is Lambic!   Where's my culture of amoebic 
dysentery?"
			-- Gary Larson
From: Matthew M. Huntbach
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <62nicu$6si$12@beta.qmw.ac.uk>
Donald Fisk (···········@bt-sys.bt.spamblock.co.uk) wrote:
> Matthew M. Huntbach wrote:
> > Chris Bitmead (······@thepla.net) wrote:
> > > How can you call something so simple a mess? You may personally feel
> > > that some other language is better, but I can't imagine it would be
> > > much simpler, and something so simple in concept can't be messy.
> > 
> > One word: SETQ.

> Use of setq (or setf) is not compulsory.   It is possible to write
> lisp with no destructive assignment statements.   However, for
> many problems, the occasional use of destructive assignment is more
> natural and/or efficient. 

But not elegant. Which was my point.

Matthew Huntbach
From: Adam K. Kirchhoff
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <62bkcb$lm2$1@jake.esu.edu>
net.au>;
Organization: Kutztown University of Pennsylvania,  USA
Distribution: 

One word: Perl

*****************************************
*  Adam Kirchhoff        	 	*
*  ········@kutztown.edu	 	*
*  http://www.kutztown.edu/~kirc5650	*
*  PGP Key available			*
*****************************************
From: John Clements
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <62eh52$bne$1@joe.rice.edu>
In article <············@jake.esu.edu>,
Adam K. Kirchhoff <········@kutztown.edu> wrote:
>
>One word: Perl

One character: ?


--
john clements
From: ? the platypus {aka David Formosa}
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <877503344.740891@cabal>
In <············@jake.esu.edu> ········@kutztown.edu (Adam K. Kirchhoff) writes:

>Organization: Kutztown University of Pennsylvania,  USA
>Distribution: 

>One word: Perl

Not even perls most ardent supporters would call Perl elegent.  Its not
supposed to be,  its a ruff and ready languge that is prepared to get down
and dirty.


--
Please excuse my spelling as I suffer from agraphia see the url in my header. 
Never trust a country with more peaple then sheep. 
Save the ABC Is $0.08 per day too much to pay?   ex-net.scum and proud
I'm sorry but I just don't consider 'because its yucky' a convincing argument
From: Thant Tessman
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <343142AE.41C6@signature.below>
Kaz wrote:

> In other words, you can do the same replacement in C that 
> you do in assembly language. Instead of tail recursion, you 
> write a loop, like a real programmer.

ROTFL

It's hopeless.  I give up.

--
thant at acm dot org
From: Christopher Oliver
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <60s2ah$fhf@guy-smiley.traverse.com>
Kaz (···@latte.cafe.net) wrote:
: In other words, you can do the same replacement in C that you do in assembly
: language. Instead of tail recursion, you write a loop, like a real programmer.

: You are basically complaining that C implementations don't always compensate
: for stupidity.

Hmmm...  I don't know the original source, but the following allusion in
Moylan's "The Case Against C" comes to mind:

   "Much of the power of C comes from having a powerful preprocessor.
   The preprocessor is called a programmer."

Watch the name calling and jingoism!

--
(list->string (reverse! (string->list ·············@revilo")))
From: Lawrence Kirby
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <876059652snz@genesis.demon.co.uk>
In article <··········@guy-smiley.traverse.com>
           ················@fritz.co.traverse.com "Christopher Oliver" writes:

>Kaz (···@latte.cafe.net) wrote:
>: In other words, you can do the same replacement in C that you do in assembly
>: language. Instead of tail recursion, you write a loop, like a real programmer.>
>: You are basically complaining that C implementations don't always compensate
>: for stupidity.
>
>Hmmm...  I don't know the original source, but the following allusion in
>Moylan's "The Case Against C" comes to mind:
>
>   "Much of the power of C comes from having a powerful preprocessor.

This falls at the first hurdle since C does not have a powerful
preprocessor, it has a rather primitive one. It is however true that
it is more than many other languages have.

>   The preprocessor is called a programmer."

Pardon?

-- 
-----------------------------------------
Lawrence Kirby | ····@genesis.demon.co.uk
Wilts, England | ·········@compuserve.com
-----------------------------------------
From: Gareth McCaughan
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <86k9fo340l.fsf@g.pet.cam.ac.uk>
Someone calling himself `Kaz' wrote, many moons ago,

> >current computer architecture, as you like to say.  It makes
> >tail-calling difficult in C and imposes unfortunate restrictions on
> >some programming styles.  Did you never replace a JSR xyz; RTS by a
> >JMP xyz in assembly language?  Don't you understand how this is
> >extremely useful?
> 
> I totally understand why it is useful. I also know C compilers that have
> no trouble converting tail recursive functions into loops.
> 
> In any case, smart programmers don't write tail recursive functions,
> because a C implementation is not required by the ISO standard to
> recognize and optimize tail recursion.

... and since then everyone has been merrily flaming everyone else
about exactly what "tail recursion" means. This is *stupid*, because
the relevant question isn't `is this particular bit of code a case
of tail recursion?', it's `is this a good way of implementing what
you want, and does the compiler do a good job on it'; the words don't
matter diddly-squat.

`Kaz' got it wrong, because tail-call[1] does many things other than
just loops; because a bunch of, er, tail-recursive functions can do
some things that can't be done elegantly if you don't have a compiler
that groks tail calls; and because his last sentence seems to be saying
`The fact that C doesn't have to do tail calls right isn't a problem,
because clever programmers won't use tail calls, because C doesn't have
to do them right'. Of course, this argument is entirely useless when
the question at issue is `is being able to write state machines etc
using tail call, and be sure the compiler won't screw you, a good thing
or not?'.

Anyway, this is basically a plea[2] for an end to the pointless
flamage over whether a given construct should be *called* tail
recursion or tail call or something else. It doesn't matter what
you call it. If you must argue Lisp versus C, or ML versus COBOL,
or whatever, please at least argue over things that *matter*.


[1] If you care, note that the person `Kaz' was replying to used the
    term `tail call', not `tail recursion'.

[2] Which I know to be doomed; but hey, I might as well try.

-- 
Gareth McCaughan       Dept. of Pure Mathematics & Mathematical Statistics,
·····@dpmms.cam.ac.uk  Cambridge University, England.
From: Kaz
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <61feer$14n$1@latte.cafe.net>
In article <··············@g.pet.cam.ac.uk>,
Gareth McCaughan  <·····@dpmms.cam.ac.uk> wrote:
>Someone calling himself `Kaz' wrote, many moons ago,
>
>> >current computer architecture, as you like to say.  It makes
>> >tail-calling difficult in C and imposes unfortunate restrictions on
>> >some programming styles.  Did you never replace a JSR xyz; RTS by a
>> >JMP xyz in assembly language?  Don't you understand how this is
>> >extremely useful?
>> 
>> I totally understand why it is useful. I also know C compilers that have
>> no trouble converting tail recursive functions into loops.
>> 
>> In any case, smart programmers don't write tail recursive functions,
>> because a C implementation is not required by the ISO standard to
>> recognize and optimize tail recursion.
>
>... and since then everyone has been merrily flaming everyone else
>about exactly what "tail recursion" means. This is *stupid*, because
>the relevant question isn't `is this particular bit of code a case
>of tail recursion?', it's `is this a good way of implementing what
>you want, and does the compiler do a good job on it'; the words don't
>matter diddly-squat.
>
>`Kaz' got it wrong, because tail-call[1] does many things other than
>just loops; because a bunch of, er, tail-recursive functions can do
>some things that can't be done elegantly if you don't have a compiler
>that groks tail calls; and because his last sentence seems to be saying
>`The fact that C doesn't have to do tail calls right isn't a problem,
>because clever programmers won't use tail calls, because C doesn't have
>to do them right'. Of course, this argument is entirely useless when
>the question at issue is `is being able to write state machines etc
>using tail call, and be sure the compiler won't screw you, a good thing
>or not?'.

Yes it is. But it's also a burden on the implementors, so it may be left as a
``quality of implementation'' issue. C may not require such an optimization,
but look at the availability of C compilers for just about everything that has
a processor.  In fact, the C standard doesn't require *any* optimizations at
all, describing instead the abstract semantics of computation. That fact
doesn't seem to stop compilers from implementing all kinds of wonderful
optimizations.

Can we conclude that if C implementations were suddenly required tail-call
optimizations in order to be conforming, all of the current implementations of
the language could be brought to conformance?

Incidentally in assembly language, that optimization of JSR xyz to JMP xyz is
possible only under some circumstances. If the current function has a stack
frame, it will have to be disposed somehow. 

[ Yes, I've written assembly code with features like lateral
branches between subroutines or multiple entry points to the same function.
But who would want to maintain it? ]

>[1] If you care, note that the person `Kaz' was replying to used the
>    term `tail call', not `tail recursion'.

You are right; this was my mistake. But then someone jumped on me for not
understanding what tail recursion is instead of pointing out my hopeless
non-sequitur!

And that's how the lame thread began...
-- 
From: Gareth McCaughan
Subject: Re: What is the most "Elegant" Language?
Date: 
Message-ID: <86k9focivp.fsf@g.pet.cam.ac.uk>
`Kaz' wrote:

> >                   Of course, this argument is entirely useless when
> >the question at issue is `is being able to write state machines etc
> >using tail call, and be sure the compiler won't screw you, a good thing
> >or not?'.
>
> Yes it is. But it's also a burden on the implementors, so it may be
> left as a ``quality of implementation'' issue. C may not require
> such an optimization, but look at the availability of C compilers
> for just about everything that has a processor.  In fact, the C
> standard doesn't require *any* optimizations at all, describing
> instead the abstract semantics of computation. That fact doesn't
> seem to stop compilers from implementing all kinds of wonderful
> optimizations.

No indeed, but the point is that if you can't be confident that a
given way of writing code will be compiled reasonably sensibly then
you can't use it. This means, for instance, that in C you *can't*
implement a state machine as a bunch of mutually tail-recursive
functions, because you have no guarantee that your compiler won't
turn your program into a stack-guzzling monstrosity. (And, I think,
most compilers *will*.)

This is not the same as the situation with most other optimisations
(say, strength reduction, or clever instruction scheduling, or
loop unrolling). If you don't do those, then the result is that
your program runs more slowly. On the other hand, if you don't
do tail-call optimisation, then the result is that certain classes
of program consume infinite amounts of stack space.

> Can we conclude that if C implementations were suddenly required
> tail-call optimizations in order to be conforming, all of the
> current implementations of the language could be brought to
> conformance?

I haven't looked at the insides of `all of the current implementations
of the language', so I don't know. But I can't see any convincing
reason why not. It depends, though, on exactly what you required.
Requiring, say, sensible tail-call behaviour on calls to explicitly
named functions (as opposed to calls through function pointers)
defined in the same compilation unit (is that the right term?) as
the one containing the call, provided that the function containing
the call never allows addresses of any of its automatic variables
to escape, would seem to me to be reasonable and not difficult to
implement. Restrict that last clause a bit more, to `never takes
the address of any of its automatic variables', and it's definitely
easy.

> Incidentally in assembly language, that optimization of JSR xyz to JMP xyz is
> possible only under some circumstances. If the current function has a stack
> frame, it will have to be disposed somehow. 

Um. That's what tail-call optimisation *means*. You construct the new
stack frame on top of the old.

> [ Yes, I've written assembly code with features like lateral
> branches between subroutines or multiple entry points to the same function.
> But who would want to maintain it? ]

No one. That's why you want your higher-level languages to be able
to do that sort of thing for you.

-- 
Gareth McCaughan       Dept. of Pure Mathematics & Mathematical Statistics,
·····@dpmms.cam.ac.uk  Cambridge University, England.