yost@tss.com (Dave Yost) (03/03/91)
Has anyone implemented any of icon's great features in scheme? Seems to me to be a reasonable idea. --dave yost
goer@ellis.uchicago.edu (Richard L. Goerwitz) (03/03/91)
Regarding Dave Yost's question about implementing Iconish features in Scheme: It's hard to respond to such a question without knowing what you have in mind. For instance, if you are interested in backtracking, then I doubt you could move the Icon mechanisms to Scheme, with all its limitation expressions, goal-directed evaluation, and what not. String scanning is a bit less difficult. At some point, though, I'd begin to wonder whether it was easier just to cut Icon code. What is it about Scheme in particular that make it a more attractive basis for your intended application? Just curious. -Richard
yost@tss.com (Dave Yost) (03/05/91)
In article <1991Mar3.013912.14857@midway.uchicago.edu>, goer@ellis.uchicago.edu (Richard L. Goerwitz) 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. Also, I'm learning scheme partly just because I'm interested in it and because I'm reading the Abelson & Sussman(s) book. I'd rather use Icon-style expression evaluation, and it seemed that scheme could easily accomodate that. --dave yost
goer@ellis.uchicago.edu (Richard L. Goerwitz) (03/05/91)
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
cjeffery@CS.ARIZONA.EDU (Clinton Jeffery) (03/05/91)
>In response to people comparing Scheme and Icon, Richard notes that: >The fact that Icon isn't interpreted per se does get in the way of >Icon code executing code. Icon's virtual machine architecture does not rule out a true interpreter. For instance, most implementations of the SmallTalk language use a virtual machine, but the SmallTalk environment comes with an interpreter. A SmallTalk guru could provide some useful suggestions in this discussion, I think. A by-product of my own research this year is a "multi-program interpreter", a version of iconx that allows mulitple icon programs to be loaded into a single execution of the virtual machine. This would allow further improvements to the kind of "Icon interpreter written in Icon" programs that were posted last year by various members of this group.
williamh@iris.ucdavis.edu (Heather Blanchard) (03/08/91)
In article <1991Mar4.225707.12864@midway.uchicago.edu> goer@ellis.uchicago.edu (Richard L. Goerwitz) writes: >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). Just thought I would let you know: An interactive Icon interpreter is what I am currently working on for my Master's Thesis. I am merging the source code for the translator and executor, icont & iconx, into a single program, iconi, which will translate, link, and execute single Icon expressions interactively. I have already done some of the work, but have quite a bit left. If anyone is interested in the interpreter, please let me know and I will let you know when I have finished my work. Heather