🚀 go-pugleaf

In article  <320@quintus.UUCP> ok@quintus.uucp (Richard A. O'Keefe) writes:
>In article <6797@megaron.arizona.edu> gudeman@arizona.edu (David Gudeman) writes:
>>(1) The article described an experiment in which a program was written
>>in Prolog and in Icon, and the Prolog implementation was faster.
>
>For heaven's sake, nobody claimed that that PROVED anything!

For heaven's sake, nobody claimed that you claimed that that PROVED
anything :-).  In fact, I understood that you were throwing the
experiment out for discussion so I discussed.  Sorry you misunderstood.

>...  Other things being equal, that should mean that Icon
>could be made to go about twice as fast, but the claim was made in the
>Icon books that that sort of speed-up had not been attained.

I should have mentioned that the Icon compiler didn't do anything
except output a sequence of machine code instructions for each icode
instruction.  The machine language part just called functions in the
run-time system to do all the work.  There is currently a lot of work
going on to write a _real_ compiler for Icon, and we expect a lot of
improvement.  But the improvements mostly will come from optimizations
rather than from getting rid of the interpreter.

>>In particular I was horrified at the description of using Icon records
>>to implement linked lists...
>
>Why should you be horrified at using records for sequences?  They are
>in the language, and they are supposed to be useful for that amongst
>other things.

Oh well, I guess I shouldn't apply my dry sense of humor to people who
don't know me.  The work "horrified" should be taken as hyperbole.
What I _meant_ was that this use of records is no where near as
efficient as the use of conses in Prolog and Lisp.  Looking up a field
in a record requires (1) looking up the record constructor, (2) hashing 
on the name of the field, (3) going back to the record to get the
value.  Rather than trying to write a Prolog program in Icon, it would
have been more efficient to completely reformulate the solution for
Icon.

I'd be interested in knowing how well _my_ Icon solution stacks up
against your Prolog solution.  If you will send me a complete
description of the problem, I'll send you my solution.  Please be
aware that I'm not out to defend Icon.  There are a _lot_ of problems
with the current implementation (and I'm not responsible for any of
them :-).  I just think the comparison would be interesting.

>... Icon does have things called lists, but they are not at
>all what everyone else means by lists:  they are flex arrays.

I probably should just pass on this one, but I can't help myself...
By "everyone else" you must mean "everyone in the Lisp/Prolog
community" because outside of that group "list" is a generic term
referring to an ordered collection of objects.  The operations on a
list are generally considered to be application specific.  Also,
outside of that group no one would know what you mean by the term
"flex array".  Ask a C programmer, a Smalltalk programmer, a Snobol4
programmer, and a data-structures teacher what a list is.  You will
probably get three or four different answers.

>...  Yes, Icon *is* a higher-level language than
>Prolog, in that its basic operations (replace a substring &c) are more
>remote from conventional machines than the basic operations of Prolog.

Isn't unification just as remote from conventional machines as Icon
operations are?