RE: Icon

[Tim Hickey <address@hidden>]

On Wed, 19 Dec 2001, Todd Proebsting wrote:
> procedure main()
>    every write(4 < (1 to 6))
> end
>
> The program above produces 5,6.  How can this be so?  Well, it tries to
> write(4<1), but because 4<1 fails, the write never actually gets called,
> BUT write does not give up---it tries for a new value from '<' which
> obliges by trying 4<2, which also fails, as does 4<3 and 4<4, but
> finally 4<5 succeeds, so write can chew on 5 and then later on 6.
>
> Now, I won't bother you further with all the details of Icon, but I will
> add that Icon does allow user-specified generators and has lots of the
> other features that you'd expect in a language.  (It lacks a bunch, too,
> such as closures and continuations.)  I just know that now that I've
> used a language with goal-directed evaluation, I never want to go back.
> When I'm forced to, I do, but only as I grumble.
>


Prolog is another language with this kind of goal-directed paradigm,
but where "every" is implicit and omnipresent.

 %% untested code example ....
 in-range(N,N,M) :- N =< M.
 in-range(X,N,M) :- N=<M, N1 is N+1, in-range(X,N1,M).

 main :-
  in-range(X,1,6), 4<X, display(X),nl.

 ?- main.
 5
 6
 no
 ?-
For certain problems, this goal directed style
is wonderful (e.g. building Interval Arithmetic constraint
solvers, where backtracking arises naturally).

*But* one major problem with this goal generation is that it
presents difficulties when interacting with objects that
are not inherently backtrackable (e.g. windows, whiteboards,
network connections). The Prolog solution is to use the
cut (!) to cut-off all remaining solutions. Still, imperative
and functional languages seem to have, IMO, a better fit for
most "practical" programming tasks, e.g. implementing socket-based
services, building GUIs, responding to HTML-form requests, ....

I suspect ICON has the same difficulties.


> So, what does all this have to do with the
> How-Will-Lisp-Gain-The-Place-It-Deserves-In-The-Hearts-And-Minds-Of-Prog
> rammers-Around-The-Globe debate that consumes so much of this mailing
> list?  (I've isolated three basic threads to this discussion (1) Real
> Programmers Use Macros, (2) Real Programmers Aren't Afraid of
> Parentheses, and (3) Real Programmers Understand Continuations.)  Well,

Another important thread in this How-will-Lisp-take-over-the-world  :)  is

  Why do *real* programmers
    (as opposed to Real Programers)
  use Perl,Java,C,C++,PHP,Python,...
    (and not Scheme, Dylan, Lisp, ML, Haskell, Self, Smalltalk, Icon,
     Prolog, Ruby, APL, J, BRL, my-favorite-language ...)?

Some of the reasons disucssed on this list are technical,
some are psychological (cognitive complexity of nesting, language weight...)
some are social (network effect, killerapp phenomenon)
some are educational (structure of Computer Science curricula, existence
                      of texts and tutorials).
....
Its a complex question and this list has been a great way (for me) to
gain some insight into the problem.

There has been some recent quantitative work comparing the
productivity and effectiveness of programmers when they are
using different languages (see the references on Peter Norvig's
page: http://www.norvig.com). Perhaps this sort of "social science"
research would help provide a rational basis for language
design and adoption.

> my missive has nothing to do with the great Lisp debate.  I just wanted
> mention a beautiful language mechanism that's been ignored by virtually
> all language designers.
>

I seem to remember ICON having spectacular text-handling features
(like SNOWBALL).... or have these been overtaken by PERL   :)

---Tim---