🚀 go-pugleaf

In article <1991Mar21.123639.577@hawk.cs.ukans.edu>, billk@hawk.cs.ukans.edu (Bill Kinnersley) writes:
> In article <924@optima.cs.arizona.edu> gudeman@cs.arizona.edu 
>   (David Gudeman) writes:
> : Icon lets you express a collection of different evaluation paradigms
> : that other languages don't.  It has search-with-backtracking like Prolog
> 
> Icon's backtracking is "implicit", which means it is there but you can't
> see it.  It is "restricted syntactically", which means you have to rewrite
> a major portion of your program into a single expression to get it to work.

What you "see" when you read a program depends on your mental model.
If you understand where backtracking occurs, you will see it there.

I don't understand your use of the term "rewrite". If you start off
using goal-directed evaluation why would you have to rewrite your
code to use it? The syntactic restrictions on backtracking is a feature
that you can (and usually do) use because you want to. If you want
to allow backtracking through your entire program, you can write it
that way. As for most of your program being a single expression, it
aways is. Icon is an expression oriented language: A procedure body is
one expression even when you cannot backtrack through all of it.

> : it has success/failure semantics like SNOBOL4
> 
> which means Icon lacks boolean variables, operators or expressions.

You don't need boolean operators or expressions in Icon. Icon's
success/failure semantics perform the same functionality quite
elegantly. I realize some people who "grew up" with boolean operators
are uncomfortable with this; to appreciate the elegance of Icon's
expression evaluation mechanism you must escape from old prejudices.

There are several ways to emulate boolean variables. None is as elegant
as I would like, but they are not bad.

> These two features, the heart and soul of Icon, are elegant on paper, and
> sound useful--until you try to use them.  In practice they are of limited
> use, difficult to write, and difficult to debug.

Full goal-directed evaluation is a powerful feature, but is not used
extensively. That may be because few people have learned to think
in those terms or it may be because you don't often need its power.
Like anything else, it becomes easier to use as you gain experience
with it. While complex goal-directed evaluation is not used a lot,
generators are. In Icon, these are simply one piece of goal-directed
evaluation and iterating through a generator is really a trivial example
of backtracking.

Debugging goal-directed  evaluation also becomes easier with time, but
can still be a problem. I'm not sure if that is an inherent difficulty
or if we just lack good debugging tools.

Anti-disclaimer: As a member of the Icon Project my opinions might
be a triffle biased.

Because Icon is not geared toward "systems programming", I do most of
my implementation work in C. However, I assure you I write programs
in Icon whenever it is applicable. It is far less painful than programming
in C.

  Ken Walker / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721
  +1 602 621-4252  kwalker@cs.arizona.edu {uunet|allegra|noao}!arizona!kwalker