rgr@m10ux.UUCP (Duke Robillard) (08/04/87)
Does anyone here have any experience with TI's Scheme
for the IBM-PC world? It's so cheap, that I'm sorely tempted,
but I fear that my 8086-based machine just won't be able to
do anything with it....
I'll post any interesting reviews I receive.
Thanks in Advance (where is Advance?)
Bob Robillard
ihnp4!m10ux!rgrmike@yetti.UUCP (Mike Clarkson ) (08/18/87)
In article <316@m10ux.UUCP> rgr@m10ux.UUCP (Duke Robillard) writes: >Does anyone here have any experience with TI's Scheme >for the IBM-PC world? It's so cheap, that I'm sorely tempted, >but I fear that my 8086-based machine just won't be able to >do anything with it.... > TI's Scheme is an excellent product, and well worth it's price. The manual alone is worth the $99, and serves as valuable documentation for the MIT Vax/Sun/VMS version as well, as they have been very careful to distinguish between "generic" Scheme and TI's implementation. (The differences are minor and usually very reasonable and worthwhile.) Besides, Scheme is an excellent language in it's own right, and I feel that most programmers will benefit from looking at it. Some people have characterized Scheme as "what Common Lisp *should* have been". Which brings me to my question: I heard a rumour that a new, as yet unfinished European effort at a Lisp standard (EuroLisp?), is based significantly on Scheme. Does anyone have any info on EuroLisp - does it exist, what stage is it at, what does it look like? I'd be interested in hearing anything concrete about it. -- Mike Clarkson, ...!allegra \ BITNET: mike@YUYETTI or CRESS, York University, ...!decvax \ SYMALG@YUSOL 4700 Keele Street, ...!ihnp4 > !utzoo!yetti!mike North York, Ontario, ...!linus / CANADA M3J 1P3. ...!watmath / Phone: +1 (416) 736-2100 x 7767 "...the most inevitable business communications system on the planet." - ROLM magazine advertisement which planet?
dleigh@hplabsz.HPL.HP.COM (Darren Leigh) (08/18/87)
In article <527@yetti.UUCP> mike@yetti.UUCP (Mike Clarkson ) writes: >In article <316@m10ux.UUCP> rgr@m10ux.UUCP (Duke Robillard) writes: >>Does anyone here have any experience with TI's Scheme >>for the IBM-PC world? It's so cheap, that I'm sorely tempted, >>but I fear that my 8086-based machine just won't be able to >>do anything with it.... >> > >TI's Scheme is an excellent product, and well worth it's price. The I run TI's PC Scheme on my 4.77 MHz XT clone and it is so slow that it is almost unusable. The emacs-like editor won't even react in real typing time. I have tried TI Scheme on a couple of AT machines (one was 6 MHz and the other was 8 MHz) and the performance was quite reasonable. My only gripe with the implementation itself is that I can't compile something and run it without being in Scheme itself. Darren Leigh dleigh@hplabs.hp.com
Isaac_K_Rabinovitch@cup.portal.com (08/24/87)
> >I run TI's PC Scheme on my 4.77 MHz XT clone and it is so slow that it >is almost unusable. The emacs-like editor won't even react in real >typing time. > >I have tried TI Scheme on a couple of AT machines (one was 6 MHz and >the other was 8 MHz) and the performance was quite reasonable. > >My only gripe with the implementation itself is that I can't compile >something and run it without being in Scheme itself. > >Darren Leigh >dleigh@hplabs.hp.com I've run TI scheme on a Toshiba T1100 (the old model with the 8088), which I don't think is that much faster than the clone Leigh subscribes. I found Scheme's performance marginally acceptable, though I never ran any really serious programs that way: one really needs a hard disk for that kind of software. I wouldn't use the builtin editor with scheme, it's missing some basic features. I seem to recall the refusal to provide native-code compilation is a basic ideological decision of the inventors of scheme, who didn't want to introduce the ambiguity of interpretation that would entail. Still, there's a discussion of writing a Scheme compiler (in Scheme, of course) in Abelson and Sussman's Structure and Interpretation of Computer Programs (I haven't got that far yet, so I don't know how complete the discussion is).
dbt@faccs.UUCP (08/27/87)
In article <646@cup.portal.com>, Isaac_K_Rabinovitch@cup.portal.com writes: > I seem to recall the refusal to provide native-code compilation is a basic > ideological decision of the inventors of scheme, who didn't want to introduce > the ambiguity of interpretation that would entail. There are Schemes that generate native code. Yale's T system for Vax & 68020 computers includes a *very good* optimizing compiler. Chez Scheme (where is this from?) I read somewhere (_The_Scheme_Programming_Language_, Prentice-Hall?) generates code for the VAX (only?) comparable to Franz Lisp. MacScheme, for the Macintosh, is coming out with a native code compiler as well. I don't know what the code generation is like. (I would appreciate any information about this one in particular. e.g. is the native code compiler an modification of the original byte-code compiler?) The first versions of Scheme were research implementations developed in MacLisp and were not intended to be "real" compilers, but I never read anything about a "refusal to provide native-code" as any kind of "ideological decision." In fact, a lot of Guy Steele's work with Scheme had a lot to do with compilers and compilation. -- Think Green, Patrick Logan (dbt@faccs) uw-beaver!ssc-vax!shuksan!tahoma!bcstec!faccs Reporter: "What do you think about Western Civilization?" Ghandi: "I think it would be a good idea!"
willc@tekchips.UUCP (09/02/87)
In article <121@faccs.UUCP> dbt@faccs.UUCP (Data base translator ) writes: >MacScheme, for the Macintosh, is coming out with a native code compiler as >well. I don't know what the code generation is like. (I would appreciate any >information about this one in particular. e.g. is the native code compiler >an modification of the original byte-code compiler?) For the moment at least, the MacScheme native code compiler is available only as part of MacScheme+Toolsmith. The native code compiler is indeed a modification of the original byte code compiler, which was described in my 1984 Lisp conference paper. The original compiler had one pass, but the new one has three: macro expansion, code generation, and assembly. The first two passes are the same for byte code as for native code, but there are two assemblers. The assembly pass decides which assembler to use for each code segment (i.e. lambda expression) as specified by the programmer. Though the new three-pass compiler is slower than the old one-pass, it seems faster because character i/o, which has always been the bottleneck, has been sped up. "Optimization" takes place in all three passes: simple source code transformations in the macro expansion pass, a few simple optimizations in the code generator, and peephole optimizations in the native code assembler. With more peephole optimizations and perhaps a few more optimizations in the code generator the code would be fairly decent, but right now it's merely competitive. It compiles very good code for loops but does poorly with procedure calls. (Using generic arithmetic a Macintosh II can count down from 1,000,000 in 4.5 seconds, which is very good, but (tak 18 12 6) takes 2.3 seconds, which is mediocre.) The representation used for continuations was changed for the native code compiler, but the byte code representations are still used for procedures and environments. These representations appear to be the main limits to performance. Exceptions in native code are handled by dropping into byte code and letting the byte code exception handler deal with it. The exception handler and byte code debugger are therefore used for native code as well as byte code. This is why native code and byte code use the same representations. There isn't much difference between a compiler that compiles to byte code and one that compiles to native code, so it's fair to say that nearly all implementations of Scheme are compiled. The PC Scheme byte code compiler, for example, is quite a bit more sophisticated than the MacScheme compiler even though it always generates interpreted byte code. Peace, William Clinger