Newsgroups: comp.lang.icon
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!maverick.ksu.ksu.edu!ux1.cso.uiuc.edu!midway!ellis.uchicago.edu!goer
From: goer@ellis.uchicago.edu (Richard L. Goerwitz)
Subject: Re: RE: terrible code
Message-ID: <1991Mar19.042611.18718@midway.uchicago.edu>
Sender: goer@midway.uchicago.edu (Richard L. Goerwitz)
Organization: University of Chicago
References: <9103190245.AA11982@uunet.uu.net>
Distribution: inet
Date: Tue, 19 Mar 91 04:26:11 GMT

In article <9103190245.AA11982@uunet.uu.net> nowlin@isidev.UUCP writes:
>
>   m := 0
>   while *(p := (s[i:j] ?  =!l)) > m do m := *p
>   if /p then fail
>   else return i + m
>
>The key to this is that it's not a "mindless iteration through the entire
>list".  It's an iteration, but in any language but Icon you'd have to
>explicitly do a lot more to control this iteration than in the simple
>expression above.  Simple is in the eyes of the beholder :-)

You know, reading over my last posting, you could take the word "mindless"
to refer to the programmer, and not to the =!l method of looking for mat-
ches.  That's not what I indended, of course.  I should really try to be
a bit more gracious.  The overall solution was really very clean.

Anyway, elegance of expression is certainly a plus with Icon.  So it its
economy.  The question is whether this economy doesn't sometimes involve
some serious, serious performance penalties.  In the case of my "terrible
code" (self-admitted), I was trying to use two Icon features (hash tables
and sets) to coax more performance out of a routine than the backtrack-
ing mechanisms, unhindered, allowed.

>This Icon stuff is pretty slick.  I fail to see why a few of dozen lines of
>admittedly "terrible" code make a better solution than these four lines.
>I could do a matching table in C that would blow this away in terms of
>speed but this is Icon.  It should be done Iconishly.

Well, that again is in the eyes of the beholder.  Does "Iconishly" mean
"in an extremely compact and elegant, but computationally clumsy and inef-
ficient, manner"?  Perhaps in many cases, yes.  In this case, I had hoped
no.  My attempt at doing things more deterministically, though, failed.
So in the end I was left with something both slow and inelegant.

I guess one could argue that this sort of thing should be done in C, and
that the easiest way to do things would be just to use the regexp rou-
tines.  Often, though, I work on larger-scale projects mainly in Icon,
and am very, very reluctant to hack in C code, either through extcall/
callout, or, worse yet, via shell scripts and pipes.  Unix isn't the only
platform I operate on, and there is something esthetically displeasing
about having to hack every interpreter I want to run software on.

I guess the big question is this:  How easy will inline C code be able
to be incorporated into compiled Icon code??

(Jerry, thanks for responding; I'll probably end up using your code, a
la Steve Wampler's modifications.)

-Richard (goer@sophist.uchicago.edu)
