freeman@argosy.UUCP (Jay R. Freeman) (07/01/90)
I have written a shareware Scheme implementation for the Apple
Macintosh. Until 1 August 1990, I will be happy to (US) mail a free
copy to anyone who sends me a 3.5-inch 800K disk and a self-addressed
return mailer WITH ENOUGH POSTAGE to get it back to you.
"Free" means that I encourage recipients of disks thus obtained to
ignore the program's built-in appeal for a shareware donation.
Mail to:
Jay Reynolds Freeman
P. O. Box 60628
Palo Alto, CA, 94306-0628
If I should get more requests than I can handle, I will have to
return empty disks. I think that's very unlikely.
For those who don't know, Scheme is a dialect of Lisp. For those
who do know, my implementation is a nearly-complete "R3" Scheme
interpreter, with a few extra features. It should run on a Mac Plus
or on any later Macintosh.
I have no FTP access and subscribe to no commercial on-line
services, so I cannot get my project to the various usual places, and
the distribution seems too large for comp.binaries.mac.
I hope it does not breach netiquette to post this item: Shareware
appears regularly on comp.binaries.<etc>, so I concluded it was OK.
-- Jay Reynolds Freeman
<canonical disclaimer -- all opinions herein are my own>oz@yunexus.yorku.ca (Ozan Yigit) (07/06/90)
In article <601@argosy.UUCP> freeman@MasPar.COM (Jay Reynolds Freeman) writes: > > I have written a shareware Scheme implementation for the Apple >Macintosh. You realise of course that there is a *very inexpensive* and very well implemented scheme for Macintosh: Scheme Express or MacScheme Student editions, and the latter comes in a book. Why should anyone be interested in "yet another" implementation ?? What is it that makes your implementation special? [I am not trying to be cynical... I am just curious] oz --- Sometimes when you fill a vacuum, it still sucks. | oz@nexus.yorku.ca Dennis Ritchie | or (416) 736 5257
freeman@argosy.UUCP (Jay R. Freeman) (07/08/90)
In article <12383@yunexus.YorkU.CA> you write: >In article <601@argosy.UUCP> freeman@MasPar.COM (Jay Reynolds Freeman) writes: >> >> I have written a shareware Scheme implementation for the Apple >>Macintosh. > >You realise of course that there is a *very inexpensive* and very well >implemented scheme for Macintosh: Scheme Express or MacScheme Student >editions, and the latter comes in a book. I didn't know LightShip Software (I think that is what they are called now) had released a student edition: I am a registered user of MacScheme/Toolsmith, and I am surprised they haven't mailed me any advertising on it. Perhaps I have moved too often and have fallen off a mailing list. Where is it advertised and how much does it cost? Is "Scheme Express" the same as "MacScheme Student Edition"? > Why should anyone be interested >in "yet another" implementation ?? Well, I don't know if anyone is. I shall have to wait and see. > What is it that makes your implementation >special? [I am not trying to be cynical... I am just curious] I wrote my implementation, "Pixie Scheme", because I like Scheme and wanted one to play with, that I could modify to suit myself. That takes source, and I thought the best way to get source I understood (?) was to write it. So I coded and coded. Part way through, it occured to me that if I got the program into reasonable shape, it might be a useful public service to make it available as shareware, or perhaps to put it in public domain. (The least expensive MacScheme at that time was $125, I think, which might set some folks back a bit.) I decided on shareware because I was curious to see who (if anyone) used it: I thought more people would be willing to send me a dollar (my suggested shareware donation) than a post card or a letter. I will be flabbergasted if I gross more than the price of an occasional cup of coffee from the program. Anyhow, Pixie Scheme is a nearly complete "R3" Scheme. The most notable lacks are: No support for complex numbers, no support for rationals with numerator and denominator stored as separate integers, "mutation" procedures (set-car!, etc.) are not prevented from altering constants, and decimal numeric printing and scanning is only IEEE, not the much tougher standard specified by the R3 report. My implementation is (essentially) interpreted: It is *much* slower than (e. g.) MacScheme's compiled code, possibly excepting programs that make heavy use of the 68881. I may release a compiler some day. What you get on your 800K disk is two versions of the program -- one that runs on a Mac Plus or better, one that requires a 68020-or-better and a 68881-or-better, a couple of saved worlds, a HyperCard stack that describes the implementation, and a few other things. -- Jay Freeman <canonical disclaimer -- I speak only for myself>
oz@yunexus.yorku.ca (Ozan Yigit) (07/10/90)
In article <606@argosy.UUCP> freeman@cleo.UUCP (Jay R. Freeman) writes: >I didn't know LightShip Software (I think that is what they are called >now) had released a student edition... It is a part of a package from scientific press. First one is a book: %A Michael Eisenberg %A William Clinger %A Anne Hartheimer %T Programming In MacScheme %E Harold Abelson %I The Scientific Press %C Redwood City, CA %D 1990 The second is a MacScheme (student edition) Manual and Software by scientific press ISBN 0-89426-141-X, (the diskette is inside the back cover of the book) the price is (If I remember correctly) less than $45. >Is "Scheme Express" the same as "MacScheme Student Edition"? As of now, it may be. I do not know for sure. [anybody??] oz --- Sometimes when you fill a vacuum, it still sucks. | oz@nexus.yorku.ca Dennis Ritchie | or (416) 736 5257
winston@fjcnet.GOV (Winston M. Llamas) (07/12/90)
How portable is the Scheme representation (i.e. how difficult will it be to port this Macintosh Scheme interpreter to other 68k based machines)? Winston
freeman@argosy.UUCP (Jay R. Freeman) (07/13/90)
In article <305@fjcp60.GOV> winston@fjcnet.GOV (Winston M. Llamas) writes: > >How portable is the Scheme representation (i.e. how difficult will it be >to port this Macintosh Scheme interpreter to other 68k based machines)? > >Winston I'm not sure exactly what you are asking: I do not provide source code for the system (but for the record, it is in MPW C and would be pretty hard to port to a non-Macintosh, since I use (and abuse) the Macintosh Toolbox widely). The Scheme itself conforms as closely as I could make it to the R3 standard, with my extensions easily identifiable (e. g., by text search through your files of your own Scheme source), so that it should be relatively easy to port Scheme programs written in my system to other R3 interpreters. -- Jay Freeman <canonical disclaimer -- I only speak for myself.>
alms@cambridge.apple.com (Andrew L. M. Shalit) (07/13/90)
In article <612@argosy.UUCP> freeman@argosy.UUCP (Jay R. Freeman) writes:
I do not provide source code
for the system (but for the record, it is in MPW C and would be pretty
hard to port to a non-Macintosh, since I use (and abuse) the Macintosh
Toolbox widely).
Jay -
If you want to make your Scheme a real contribution, you should
distribute it as source code. That way people could use it as
the kernel of applications, and also include it as an extension
language. (and also extend it themselves!)
-andrew
--
If my sig file were you alms@cambridge.apple.com
it'd be reading this message now.freeman@argosy.UUCP (Jay R. Freeman) (07/13/90)
In article <ALMS.90Jul12192621@brazil.cambridge.apple.com> alms@cambridge.apple.com (Andrew L. M. Shalit) writes: > If you want to make your Scheme a real contribution, you should >distribute it as source code. That way people could use it as >the kernel of applications, and also include it as an extension >language. (and also extend it themselves!) > > -andrew Possibly sometime. The code needs cleaning up and regularizing, which I do piecemeal as I rework and add to it. The implementation is in some sense not done (though it is pretty complete "R3" Scheme as is) -- I am adding features to the user interface, and I would like to get my compiler to work well enough to release; that may require internal changes for support. Furthermore, MPW C has been rather a moving target: I am now porting to 3.1 from 2.0.2, and have encountered subtle bugs due to changes in the Pascal glue. (And floating-point is mostly broken in MPW C 3.1, but that's another story.) And how many people would digest 40000-odd lines of stuff well enough to make changes and applications. (Since I knew my implementation was going to be mostly interpreted for a while, I wrote the built-in Scheme procedures in the underlying C, rather than in Scheme itself. This approach leads to lots of C ...) -- Jay Freeman <canonical disclaimer -- I speak only for myself.>
mayer@hplabsz.HPL.HP.COM (Niels Mayer) (07/14/90)
So, how does this version of scheme compare to xscheme and elk?? Is it byte compiled?? Does it require any assembly language coding?? Can it support incremental GC?? ------------------------------------------------------------------------------- Niels Mayer -- hplabs!mayer -- mayer@hplabs.hp.com Human-Computer Interaction Department Hewlett-Packard Laboratories Palo Alto, CA. *
freeman@argosy.UUCP (Jay R. Freeman) (07/17/90)
In article <5598@hplabsz.HPL.HP.COM> mayer@hplabs.hp.com (Niels Mayer) writes: >So, how does this version of scheme compare to xscheme and elk?? I don't know, I have never seen either one. >Is it byte compiled?? In essence, no: Source code written by the user is interpreted by a virtual machine that is almost an SECD machine in the sense of (eg) Henderson. (Almost?? Well, the stack is a separate entity in its own right, not a heap object, there is no separate "dump" register (things get pushed onto the stack), and there are a few other registers for various special purposes.) The values of the symbols that name the built-in primitives (eg "+", "car", "cons" ...) are (tagged) pointers to compiled C routines that run the SECD machine. Essentially all of the built-in primitives are coded as C routines rather than written in Scheme using a smaller subset of "real" primitives: This structure speeds up the interpreter at the expense of making it large. The user never sees these C routines directly; that layer of the architecture is visible only to me, since I do not distribute source. These top-level C routines are in turn mostly written in terms of other, lower level C routines that also know about the SECD machine, and which (courtesy of the C preprocessor) are made to appear to me like assembly-language code -- not 68XXX code, but, if you will, the native assembler of the SECD machine. Thus if I were coding up a simple version of binary addition I would write something like PROC( add ) ADD DROP CONTINUE END_PROC which the preprocessor would translate into void add() { addMC(); ++S; } What's going on here is that the evaluator will have pushed the numbers to be added onto the stack; this code adds the top two and pops the stack. "addMC" is (virtual) microcode for addtion, "S" is a pointer into the array of tagged objects that constitutes the stack, and so on. I can in principle create a compiler that will take Scheme source code as input and produce a list of primitive addresses as output; this list can get pushed into the continuation and executed. I have such a compiler partly done, but back-burnered. Thus the implementation is not so much byte-coded as threaded, and could support (but does not at present support) compilation in the sense of Forth. I hope that makes sense. >Does it require any assembly language coding?? No. >Can it support incremental GC?? No. Given the current limits to physical memory of the Macintosh, GC time is unlikely to bother anyone very much. I could put in an incremental GC system with no more than a moderately ridiculous amount of work, should a need for one arise. Thanks for your interest. -- Jay Freeman <canonical disclaimer -- I speak only for myself>