net@tub.UUCP (Oliver Laumann) (07/15/90)
I can't answer the original question, but I would like to bring up a general observation about Scheme implementations: In article <5598@hplabsz.HPL.HP.COM> mayer@hplabs.hp.com (Niels Mayer) writes: > > Is it [Free MacIntosh Scheme] byte compiled?? > > Does it require any assembly language coding?? I think the latter follows from the former (or rather from the opposite). In a Scheme implementation (written in C or a similar language) that does NOT compile the source code to some form of "virtual machine" code and then run a virtual machine to execute it, it is impossible to implement call/cc without assembly language coding. As far as I know, Elk is the only Scheme implementation with this property, i.e. it directly interprets the source code AND supports call/cc (this is due to the fact that it was written to be used as a general extension language); thus Elk needs assembly language coding (a few lines actually). So generally speaking a programming language L may or may not have the property ``A Scheme interpreter written in L that does not follow the "virtual-machine approach" can support call/cc''. Assembly and (obviously) Scheme have this property (I don't know any other that falls in this category); C, C++, PASCAL, and Lisp do not have it. Is that saying something? I don't know... -- Oliver Laumann net@TUB.BITNET net@tub.cs.tu-berlin.de net@tub.UUCP
freeman@argosy.UUCP (Jay R. Freeman) (07/17/90)
In article <1436@tub.UUCP> net@tub.UUCP (Oliver Laumann) writes: #I can't answer the original question, but I would like to bring up a #general observation about Scheme implementations: # #In article <5598@hplabsz.HPL.HP.COM> mayer@hplabs.hp.com (Niels Mayer) writes: ## ## Is it [Free MacIntosh Scheme] byte compiled?? ## ## Does it require any assembly language coding?? # #I think the latter follows from the former (or rather from the opposite). # #In a Scheme implementation (written in C or a similar language) that #does NOT compile the source code to some form of "virtual machine" code #and then run a virtual machine to execute it, it is impossible to #implement call/cc without assembly language coding. # #As far as I know, Elk is the only Scheme implementation with this #property, i.e. it directly interprets the source code AND supports #call/cc (this is due to the fact that it was written to be used #as a general extension language); thus Elk needs assembly language #coding (a few lines actually). # #So generally speaking a programming language L may or may not have the #property # # ``A Scheme interpreter written in L that does not follow # the "virtual-machine approach" can support call/cc''. # #Assembly and (obviously) Scheme have this property (I don't know any #other that falls in this category); C, C++, PASCAL, and Lisp do not #have it. Is that saying something? I don't know... There is perhaps a semantic quibble about what is meant by "directly interprets". The implementation I wrote (the shareware one I posted a notice about here lately, which is called "Pixie Scheme") does use a virtual-machine approach, yet I would have called it a "straight interpreter", and it does support "call/cc" without requiring users to code any assembly language. In a little more detail, the (internal) evaluator is running a virtual machine which interprets the source code. The virtual machine is capable of supporting "call/cc", because it has a specific continuation into which it can push things. (Persons who hate to type will be distressed to learn that in "R3" Scheme -- hence in Pixie Scheme, "call/cc" is named "call-with-current-continuation", and you have to type all that out when you want to use it, at least until you think to rename it.) -- Jay Freeman <canonical disclaimer -- I speak only for myself.>
krulwich@zowie.ils.nwu.edu (07/17/90)
From: Bruce Krulwich <krulwich@zowie.ils.nwu.edu> >In a Scheme implementation (written in C or a similar language) that >does NOT compile the source code to some form of "virtual machine" code >and then run a virtual machine to execute it, it is impossible to >implement call/cc without assembly language coding. > >As far as I know, Elk is the only Scheme implementation with this >property, i.e. it directly interprets the source code AND supports >call/cc (this is due to the fact that it was written to be used >as a general extension language); thus Elk needs assembly language >coding (a few lines actually). It seems to me that this is only the case when the processing of procedure-call arguments is done using recursive calls in the implementation language. If, on the other hand, the implementation maintains it's continuations explicitly (or in some other way maintains what would usually be on the stack) this is not the case. Am I missing something? Bruce Krulwich Institute for the Learning Sciences
mayer@hplabsz.HPL.HP.COM (Niels Mayer) (07/18/90)
In article <1436@tub.UUCP> net@tub.UUCP (Oliver Laumann) writes: >In a Scheme implementation (written in C or a similar language) that >does NOT compile the source code to some form of "virtual machine" code >and then run a virtual machine to execute it, it is impossible to >implement call/cc without assembly language coding. > >As far as I know, Elk is the only Scheme implementation with this >property, i.e. it directly interprets the source code AND supports >call/cc (this is due to the fact that it was written to be used >as a general extension language); thus Elk needs assembly language >coding (a few lines actually). What about xscheme?? It seems to run a byte compiler, yet it requires no assembly language. Does xscheme support call/cc correctly? ------------------------------------------------------------------------------- Niels Mayer -- hplabs!mayer -- mayer@hplabs.hp.com Human-Computer Interaction Department Hewlett-Packard Laboratories Palo Alto, CA. *
mayer@hplabsz.HPL.HP.COM (Niels Mayer) (07/19/90)
In article <5613@hplabsz.HPL.HP.COM> mayer@hplabs.hp.com (Niels Mayer) writes: >What about xscheme?? > >It seems to run a byte compiler, yet it requires no assembly language. > >Does xscheme support call/cc correctly? Please ignore my previous posting. I left my brain at home yesterday. I won't do it again, I promise. -- Niels "duuuuh" Mayer.