Xref: utzoo comp.lang.scheme:2053 comp.lang.icon:637
Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!midway!ellis.uchicago.edu!goer
From: goer@ellis.uchicago.edu (Richard L. Goerwitz)
Newsgroups: comp.lang.scheme,comp.lang.icon
Subject: Re: ideas from the icon language applied to scheme
Message-ID: <1991Mar4.225707.12864@midway.uchicago.edu>
Date: 4 Mar 91 22:57:07 GMT
References: <1991Mar2.175036.24463@tss.com> <1991Mar3.013912.14857@midway.uchicago.edu> <1991Mar4.185819.19587@tss.com>
Sender: news@midway.uchicago.edu (News Administrator)
Followup-To: comp.lang.icon
Organization: University of Chicago
Lines: 46

In article <1991Mar4.185819.19587@tss.com> yost@tss.COM writes:
>|> What is it about Scheme in particular that make it a more attractive
>|> basis for your intended application?  Just curious.
>
>* The fact that it can execute a string containing source code.
>* The fact there are scheme implementations that seem to be more
>  easily assimilated into a C environment.

The fact that Icon isn't interpreted per se does get in the way of
Icon code executing code.  Everything has to be compiled, either
into an icode file (geared for a virtual machine implemented by an
interpreter) or else into C code (as with Ken Walker's compiler).
As if the Icon Project didn't have enough to do already, it might
be nice to have an Icon interpreter (in the interactive, rather
than "virtual machine" sense).

I guess, though, that the fundamental code/data unity of Lisp and
Prolog really isn't part of the Icon paradigm (although you can
get some of the same functionality by judicious application of the
IPL codeobj procedure).

The C <-> Icon interoperability issue is interesting.  You can create
personalized interpreters and translators, if you simply want addi-
tional built-in functions.  If it's access to C functions that you
want, you can use the callout() function, which lets you call C
functions from Icon.  With the compiler, it's even easier to call
C code, although I don't think the technical document explaining
precisely how has been put online yet.

I'd say that the major disadvantage to using Icon code is that the
programmer is completely hamstrung when it comes to low-level inter-
action with the operating system.  Icon is meant to be very, very
portable, and it's counter to the spirit of its implementation to,
say, give you, a fork(), wait(), and exec().  You can get these
via callout(), I guess.  But it would not be elegant.  The compiler
should rectify this, though, since it allows you to add C code in-
line.

If you knew about all of this callout() (interpreter) and inline
(compiler) stuff, then I apologize.  I figure there are others out
there asking the same sorts of questions, though, and that it is
worth posting a reply.  It's also worth reminding people about some
of the many gems included in the IPL (the adjunct library that
comes with the full Icon distribution).  Codeobj is one of them.

-Richard