Xref: utzoo comp.lang.misc:7202 comp.lang.icon:684
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!relay.nswc.navy.mil!oasys!mimsy!midway!ellis.uchicago.edu!goer
From: goer@ellis.uchicago.edu (Richard L. Goerwitz)
Newsgroups: comp.lang.misc,comp.lang.icon
Subject: Re: Survey Results : Perl vs Icon vs .... (> 500 lines)
Message-ID: <1991Apr1.043321.11251@midway.uchicago.edu>
Date: 1 Apr 91 04:33:21 GMT
References: <BEVAN.91Mar29162211@panda.cs.man.ac.uk>
Sender: goer@midway.uchicago.edu (Richard L. Goerwitz)
Distribution: comp
Organization: University of Chicago
Lines: 136

We've seen an excellent summary of Icon's benefits and deficits, and I
think it is a good one (especially considering that the person in
question was only doing an initial survey).  Let me comment on some of
the conclusions reached in efforts to refine them, and ask some
question of my own.

In <BEVAN.91Mar29162211@panda.cs.man.ac.uk> Stephen J Bevan writes (re-
garding Icon), that it has

> -  no packages.  Everything is in one namespace.  However ...

The "however" is for Idol, I gather.  For people who don't want to add
yet another level of indirection to their Icon programs, though, naming
conflicts remain a problem.

>-  no exceptions.

Have you looked at the Icon "error conversion" capability?  Normally,
run-time errors will result in program termination.  You can, however,
turn off this feature, and catch the errors yourself, either passing
them through an exception handler, or else passing them back to the
normal termination routine via runerr().  It's not an elegant system,
since every expression that might normally cause error termination has
to be checked individually.  I wonder if there are plans to expand
this feature.

> +  Object oriented features.
>    An extension to the language called Idol is included.
>    This converts Idol into standard Icon.
>    Idol itself looks (to me) like Smalltalk.
> +  has records.  Other types include :- sets, lists, strings, tables
> +  unlimited line length when reading
>    (Note. the newline is discarded)
> !  The only language that has enough facilities to be able to re-write
>    some of my Lex/Yacc code.
> +  stack trace on error.
> +  C interface is good.  Can extend the language by building `personal
>    interpreter'.  No dynamic linking.
> +  extensive documentation
>    9 technical reports in all (PostScript and ASCII)
 
> -  Unix interface is quite primitive.
>    If you just want to use a command, you can use `callout', anything
>    more complicated requires building a personal interpreter (not as
>    difficult as it may sound)
 
It is quite true that Icon does not provide a good low-level interface
with the operating system.  Moreover this is unlikely to change, since
one of the great aims of Icon has been to keep it portable.  Luckily,
customization (as you note) is not as difficult as it might seem.

> +  extensive test suite
> +  Usenet group exists specifically for it - comp.lang.icon
> 
> -  Unless you use Idol, all procedures are at the same level
>    i.e. one scope.
> -  regular expressions not supported.
>   However, in many cases, you can use an Icon functions `find',
>   `match', `many' and `upto' instead.

"In many cases" ain't so.  ANY pattern representable by regular
expressions can also be represented via Icon's builtin string
processing control structures and functions.

I note, though, that many still want regular expressions.  The
reason usually given for NOT including them is that they lack
sufficient power.  In point of fact, they represent a miniscule subset
of the range of patterns that can be specified using Icon's native
facilities.  The advantage they would bring is that they would allow
far greater recognition speed for those patterns which can be
recognized via regular expressions, and that they would allow much
more compact expression of these patterns than can be achieved with
Icon's intrinsic functions.

Until someone does it *right*, I've written a prototype findre()
function, which is in one of the more recent IPL updates.  It
essentially combines Icon's find() function with an egrep-style
FSTN-description language.  Ideally, someone should write this in C.
Let's fool with the prototype for a while until we know exactly what
we want, and then let's try to talk some poor soul into coding it up
as part of the Icon run-time system.  A matchre() function should also
be added as well.

> +  Can trace execution.
> *  Pascal/C-like syntax
>    i.e. uses {} but has a few more keywords than C.
> +  lots of example programs included.
> +  can define your own iterators
>    i.e. your own procedures for iterating through arbitrary structures.
> +  co-expressions.  Powerful tool, hard to explain briefly.  See
>    chapter 13 of the Icon Programming Language.
 
> -  co-expressions haven't been implemented on Sun 4s (the type of
>    machine I use)
 
Please correct me if I'm wrong, but I believe I saw the coexpression
code for the Sun4 posted almost a year ago.

> +  has an `initial' section in procedures that is only ever executed
>    once and allows you to initialise C like static variables with the
>    result of other functions (unlike C).
> +  arbitrary precision integers.

Wish list:

> E.2.4 Add a regular expression data type.  Modify the functions find
>       and match to perate appropriately when their first argument is a
>       regular expression.

I'd modify this to say, add findre() and matchre() to the list of
builtin functions.  Most C libraries have regexp routines that can be
drafted to serve in these capacities.  I know that regular expression
don't fit into the traditional image of what Icon string processing
has always been.  Practical advantages of speed and compactness,
though, far outweigh this supposed disadvantage, and would make Icon
much more useful for many real-world tasks.

> E.2.5 \  All of these suggest extending
> E.5.4  | the string scanning facilities to
> E.5.5 /  cope with files and strings in a uniform way.

Not sure what you mean.
 
> E.12.1 Provide a way to load functions (written in C) at runtime

My impression is that inclusion of this feature would be
hopelessly implementation dependent, and would dramatically increase
the complexity of maintaining the many implementations that exist.
I'm curious why it is that you would see any advantage in run-time
loading other than decreased in-core mem. reqs.  If you were to use the
Icon compiler (i.e. Icon->C translator), you wouldn't even have to
worry about adding any code to any run-time system.
-- 

   -Richard L. Goerwitz              goer%sophist@uchicago.bitnet
   goer@sophist.uchicago.edu         rutgers!oddjob!gide!sophist!goer