Path: utzoo!utgpu!watserv1!watmath!att!rutgers!ucsd!pacbell.com!decwrl!argosy!freeman From: freeman@argosy.UUCP (Jay R. Freeman) Newsgroups: comp.lang.scheme Subject: Re: Scheme implementation strategies (was: Free Macintosh Scheme) Message-ID: <616@argosy.UUCP> Date: 16 Jul 90 19:17:01 GMT References: <601@argosy.UUCP> <5598@hplabsz.HPL.HP.COM> <1436@tub.UUCP> Sender: news@argosy.UUCP Reply-To: freeman@cleo.UUCP (Jay R. Freeman) Organization: MasPar Computer Corporation, Sunnyvale, CA Lines: 56 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