HDTenEightyP/NetNews huggingface dataset:
From: Phillip_Coxon@equinox.gen.nz (Phill)
Subject: Amiga Scheme
Newsgroups: comp.lang.scheme
Summary: 
Keywords: 
X-Newsreader: TIN [version 1.1 PL8]
Date: 5 Jan 93 19:55:48 +1200
Organization: Equinox Networks

I'm in pretty desperate need of an implementation of Scheme for the Amiga,
preferably as close as possible to MacScheme. 

Could someone please give me a site where I can bribe someone to FTP it for
me?

Sorry about the post - I know the FAQ comes out on the 13th, but I am unable
to wait until then. Haven't got FTP myself, so I can't read the FAQ before
then. 

--
Phill Coxon -- <phill@nebula.equinox.gen.nz>, Christchurch, New Zealand
From: kardank@ERE.UMontreal.CA (Kardan Kaveh)
Newsgroups: comp.lang.scheme
Subject: building scheme-to-c on SGI Indigo
Date: 8 Jan 93 16:57:13 GMT
Organization: Universite de Montreal

I am having some trouble figuring out the makefiles for building scheme-to-c.

It seems to me that the build libsc.a, the .c files are required, but sccomp
can't be compiled until libsc.a is exists.

More specifically, when I cd to CPUDIR and do `make port', I get:

...
	cc -c -O -DMIPS -I. scdebug.c
accp: scdebug.c: No such file or directory
*** Error code 1

Any help would be appreciated.

Thanks,

Kaveh

-- 
------------
Kaveh Kardan                                       kaveh@taarna.UUCP
Systeme Taarna                                     kardank@eole.umontreal.qc.ca
Montreal Quebec Canada                             (514)844-8448
Newsgroups: comp.lang.scheme
From: jaffer@zurich.ai.mit.edu (Aubrey Jaffer)
Subject: Re: Scheme & C: a universal interface
Organization: M.I.T. Artificial Intelligence Lab.
Date: Wed, 6 Jan 1993 05:09:21 GMT

In article <1993Jan1.202829.11727@netcom.com> thinman@netcom.com (Technically Sweet) writes:
Path: mintaka.lcs.mit.edu!olivea!uunet!spool.mu.edu!umn.edu!csus.edu!netcom.com!thinman
   From: thinman@netcom.com (Technically Sweet)

   I just posted my COOL object library for C to alt.sources.
   It included the interfaces for ELK and SCM.

This posting has not appeared at this site.  If someone will send it
to me I can put it on altdorf.ai.mit.edu.
Newsgroups: comp.lang.scheme
From: thinman@netcom.com (Technically Sweet)
Subject: Re: Scheme & C: a universal interface
Organization: International Foundation for Internal Freedom
Date: Tue, 5 Jan 1993 19:43:31 GMT

Thomas Breuel pointed out in e-mail that each c-call requires a
string table lookup.  The implementation of this that I actually
use has a string -> table index feature that avoids this problem.

-- 

Lance Norskog
thinman@netcom.com
Data is not information is not knowledge is not wisdom.
From: markf@zurich.ai.mit.edu (Mark Friedman)
Newsgroups: comp.lang.scheme
Subject: Re: How do I implement trace/untrace
Date: 6 Jan 93 09:26:30
Organization: M.I.T. Artificial Intelligence Lab.
Reply-To: markf@zurich.ai.mit.edu
NNTP-Posting-Host: montreux.ai.mit.edu
In-reply-to: mtoy@mycool.asd.sgi.com's message of 6 Jan 93 01:18:06 GMT

You can't change the function per se in standard Scheme but if some
variable is bound to that function you can reassign that variable to a
new function which type checks the arguments and then calls the
original function. For example:

  (define (type-check function list-of-check-funcs)
    (lambda args
       (type-checker function list-of-check-funcs args)))

  (define (foo bar) (numerical-func bar))

  (set! foo (type-check foo (list number-checker)))

You can macro-ize the above with something like:

  (define-syntax type-check!
    (syntax-rules ()
      ((type-check! function-name check-func ...)
       (set! function-name 
             (type-check function-name (list check-func ...))))))

which would allow you to simply say:

  (type-check! foo number-checker)

-Mark
--

Mark Friedman
42 Wyatt St.
Somerville, Ma. 02143

markf@zurich.ai.mit.edu
From: fab9452@nigel.tamu.edu (Allan Bailey)
Newsgroups: comp.lang.scheme
Subject: Elk 2.0 problem loading xt.o (_alloca undefined)
Date: 5 Jan 93 14:38:37
Organization: Computing Services Center, Texas A & M University
Distribution: comp
NNTP-Posting-Host: nigel.tamu.edu


   Has anyone had a problem with Elk 2.0 loading xt.o finding _alloca
undefined??   If so, is there a fix for this?  Or way around it?

--
Allan Bailey, UNIX programmer, CSC  |
fab9452@nigel.tamu.edu              | or: nefud-the-delirious@tamu.edu
616c6c616e206261696c6579            |
From: wert@apple.com (scott comer)
Newsgroups: comp.lang.scheme
Subject: Re: Scheme for the Macintosh
Date: 5 Jan 93 07:03:28 GMT
Followup-To: comp.lang.scheme
Organization: apple computer

In article <1992Dec21.142214.554@hhcs.gov.au>, anderpe@hhcs.gov.au wrote:
> 
> 
> Does anybody know of a Scheme implementation for the Macintosh?

Lightship scheme seems to be ok. Try Academic Software at 800-531-3227.
Or, Ted Essen of Computer Biz at 408-456-0100. Or, call Lightship directly
at 415-694-7799.

The basic interpreter is $125. They also sell a toolkit of sorts
called Toolsmith. Supposedly this gives you access to the macintosh
toolbox, but i don't have any direct or indirect experience with
it. You can get the two bundled for $425 or so.

scott
wert@apple.com
Newsgroups: comp.lang.scheme
From: gls@think.COM (Guy Steele)
Subject: Scheme Digest V5 #4
Organization: The Internet
Date: Tue, 5 Jan 1993 15:16:11 GMT


[headers omitted]

      Lastly, "register" is a lousy choice of name.

   yeah, it's a reserved word in C.

   I know, it was for illustrative purposes.

So make it "Register".  Then everyone will be happy.  :-)
From: thinman@netcom.com (Technically Sweet)
Newsgroups: comp.lang.scheme
Subject: Re: Scheme & C: a universal interface
Date: 5 Jan 93 02:56:08 GMT
Organization: International Foundation for Internal Freedom

sinyaw@starbright.smsc.sony.com (Sin-Yaw Wang) writes:


>Since you require C program to register, "Thing" is put into Scheme's name
>space already.  Why not simply call these C functions directly?  Like:

>	(Thing 4) -> thing1(4)
>	(Thing 5 6) -> thing2(5, 6)
>	

>This way, the calling syntax is transparent.

"Thing" not put into Scheme's name space.  The interface library maintains
its own list of (name, function, argument spec) tuples.  It doesn't
add them to Scheme's data structures.  You can do this in Scheme:

	; where (c-call string . args) is interior to the interpreter
	(define (Thing . args)
		(apply (lambda (. l) (c-call "Thing" l))))

I think would do it.

I like to be reminded when I'm using a C extension, because I have to
be careful how I call it and how I use the return value.  Being forced
to type (c-call "Thing" xxx) is not so bad.

>I would also like to propose the removal of "not to expose Scheme object to
>C" rule.  Instead, there should be a library of C routines to parse Scheme
>objects (like pair, vector, etc.).  You can specify a native Scheme object
>by registering like this:

>	register("Thing", "thing_scm", 1, SCM_OBJECT);

I wanted a universal interface, where one C routine would
work in any Scheme implementation that supported the
interface.  If the interior structures of a particular
Scheme implementation are exposed, the C code won't work
under another Scheme.  Showing Scheme data structures into
portable C code would require copying the entire structure
into generic "struct cell" and "struct vector" data cells.
These would have to be dynamically allocated and freed with
each C call.  

I would prefer that Scheme code do what Scheme does best,
and C code what C does best.  Respectively, manipulating 
data structures, and twiddling bits.  Also, it helps to
keep each extension as small and simple as possible, 
because debugging it takes 5-20 times as long as
debugging Scheme.

> >Lastly, "register" is a lousy choice of name.

I know, it was for illustrative purposes.


-- 

Lance Norskog
thinman@netcom.com
Data is not information is not knowledge is not wisdom.
From: kaveh@CAM.ORG (Kaveh Kardan)
Newsgroups: comp.lang.scheme
Subject: porting clos code to scheme
Date: 11 Jan 93 14:15:43 GMT
Organization: Communications Accessibles Montreal, Quebec Canada


I need to port some clos code to scheme->c.  I would appreciate any
suggestions regarding the best way of doing so.  I have tiny-clos, although
it doesn't seem to run on scheme->c.  If anyone has done a port, or can
suggest another object system to use, plese let me know.

Thanks,

Kaveh

-- 
Kaveh Kardan                                        kaveh@mtrpls.login.qc.ca
Metropolis Graphics Ltd
Montreal Quebec Canada                              phone/fax: (514)842-6172
From: goudal@labri.greco-prog.fr (Frederic GOUDAL)
Newsgroups: comp.lang.scheme
Subject: bibliography
Date: 6 Jan 93 18:08:49 GMT
Organization: Laboratoire Bordelais de Recherche en Informatique


Hello,
 
I'm looking for the exact references of some articles... but I only
have the name of the author and the partial title, but here is the list

Lieberman, a paper about reversible debugging
Habtrad, a paper about mulT vision
Wilson a paper about what he called "demoniac memories"

I want to know too if ther is any paper on lispEdit (from VMlisp).

Could you reply by e-mail please....

Thanks in advance.

Frederic Goudal.
 

-- 

goudal@geocub.greco-prog.fr          "Why can't we reach the sun?"
oral-mail : babbs			 Pink Floyd
Newsgroups: comp.lang.scheme
From: wright@gefion.cs.rice.edu (Andrew Wright)
Subject: Re: R5RS and macros
Organization: Rice University, Houston
Date: Tue, 5 Jan 1993 19:22:48 GMT

In article <1icb1fINN5rs@agate.berkeley.edu> bh@anarres.CS.Berkeley.EDU (Brian Harvey) writes:
>Did the R5RS meeting clarify the status of that bizarre elephantine proposed
>macro appendix from R4RS?  Or is that still up for discussion?
>
>(It's the low-level part I find elephantine, btw; I can live with the
>proposed extend-syntax.)

R5RS adopts the high-level part only at present.  A low-level mechanism
is still under discussion, as far as I know.

Andrew Wright
From: mtoy@mycool.asd.sgi.com (Michael Toy)
Newsgroups: comp.lang.scheme
Subject: How do I implement trace/untrace
Date: 6 Jan 93 01:18:06 GMT
Organization: Silicon Graphics, Inc., Mountain View, CA
NNTP-Posting-Host: mycool.asd.sgi.com

I am new to scheme and I am trying various small projects
to explore what can and can not be done.  One idea was to
add a factility for strict type checking, which would allow
you to declare what the legal types for a function were,
and the type check would be "inserted" into the procedure,
similar to the way "trace" and "untrace" work in some schemes.

I failed to get very far in figuring out how to do this.

Is pseudo-code I want something like:

;; "type-check" insert a type check into references to a function
(define (type-check function list-of-check-funcs)
 (set! (bindingof function)
 (lambda args
  (type-checker (current-binding function) list-of-check-funcs args))))
(define (type-checker func checkers args)
  (letrec
   ((good
     (lambda (chk-list arg-list)
      (cond
       ((null? chk-list) (null? arg-list))
       ((null? arg-list) (error "Too many arguments"))
       (((car chk-list) (car arg-list)) (good (cdr chk-list) (cdr arg-list)))
       (else #f)))))
   (if (good checkers args) (apply func args) (error "Type Error"))))

Obviously this type checking is not sophisticated, but the point for me now
is not what sort of type checking, but how I implement "type-check".  With
some doodling i discovered that if I pass the quoted name of the function to
"type-check" I can use unquote to get the current binding, but since set!
is a special form, it doesn't like an expression for its first argument.

What do I need to learn to make this possible?  My scheme has a "trace"
debugging aid which does something like this.  Can this be done in Scheme?
From: kardank@ERE.UMontreal.CA (Kardan Kaveh)
Newsgroups: comp.lang.scheme
Subject: Re: building scheme-to-c on SGI Indigo
Date: 9 Jan 93 04:02:48 GMT
Organization: Universite de Montreal

Please ignore my posting regarding scheme-to-c.  Stupid mistake on my part.

Kaveh


-- 
------------
Kaveh Kardan                                       kaveh@taarna.UUCP
Systeme Taarna                                     kardank@eole.umontreal.qc.ca
Montreal Quebec Canada                             (514)844-8448
Newsgroups: comp.lang.scheme
From: brent@ssd.csd.harris.com (Brent Benson)
Subject: Re: How do I implement trace/untrace
Organization: Harris Computer Systems
Date: Wed, 6 Jan 1993 14:32:17 GMT

mtoy@mycool.asd.sgi.com (Michael Toy) writes:

> I am new to scheme and I am trying various small projects to explore
> what can and can not be done.  One idea was to add a factility for
> strict type checking, which would allow you to declare what the
> legal types for a function were, and the type check would be
> "inserted" into the procedure, similar to the way "trace" and
> "untrace" work in some schemes.

Here's a simple version of what you're looking for.  (You need to use
a macro if you don't like having to set! the result.)  As an exercise,
write a similar procedure that also checks the types of the arguments.

;;;
;;; Return a version of FUN that calls TYPE-PRED? on
;;; its return value and signals an error if the return
;;; type is incorrect.
;;;
(define (type-check fun fun-name type-pred?)
  (lambda args
    (if (and (not (null? args))
	     (eq? (car args) 'un-type-check)
	     (null? (cdr args)))
	fun
	(let ((result (apply fun args)))
	  (if (type-pred? result)
	      result
	      (error "incorrect return type:" fun-name))))))
	      
;;;
;;; Return the original FUN.
;;;
(define (un-type-check fun)
  (fun 'un-type-check))

An example:

> (define (number-car l) (car l))
> (set! number-car (type-check number-car 'number-car number?))
> (number-car '(1 2 3))
1
> (number-car '(a b c))

Error: incorrect return type:
       number-car
1> 
> (set! number-car (un-type-check number-car))
> (number-car '(a b c))
'a

--
Brent Benson                     
Harris Computer Systems
Newsgroups: comp.lang.scheme
From: quale@spock.cs.wisc.edu (Doug Quale)
Subject: Re: applying or
Reply-To: quale@saavik.cs.wisc.edu
Organization: University of Wisconsin -- Madison
Date: Wed, 6 Jan 1993 16:47:36 GMT

In article <1993Jan5.165545.11990@neptune.inf.ethz.ch> marti@nugget.inf.ethz.ch (Robert Marti) writes:
>
>Pascal as described in the 1st ed. of Jensen & Wirth did indeed specify
>that both the left _and_ right Boolean sub-expression of AND and OR must
>_always_ be evaluated.

Could you provide the page number that says this?  This directly conflicts
with my recollection that the User Manual and Report is completely silent
on this issue.  This is one of the Report's several bugs, but it was
pretty good for its time.

In a quick scan of the second edition (the one I had handy, but I can
get the first edition from the library) I couldn't find anything.  My
understanding is that short-circuit evaluation is compatible with the
requirements of the User Manual and Report, but is not required.  Many
early Pascal compilers didn't do short-circuit evaluation, and ultimately
many used the CDC implementation from ETH as the final arbiter on the
ambiguities in the definition.  (This was clearly less than ideal.)

-- 
Doug Quale
quale@saavik.cs.wisc.edu
Newsgroups: comp.lang.scheme
From: quale@spock.cs.wisc.edu (Doug Quale)
Subject: Re: applying or
Organization: University of Wisconsin -- Madison
Date: Thu, 7 Jan 1993 03:04:12 GMT

In article <1993Jan6.215411.28927@neptune.inf.ethz.ch> marti@nugget.inf.ethz.ch (Robert Marti) writes:
>
>However, Wirth himself assumed that Pascal implementations would always
>evaluate both Boolean sub-expressons as can be seen e.g. in his Pascal
>code in the 1st edition of "Algorithms and Data Structures".
>Example:
>  if p <> nil then
>    if p^.key = x then
>      begin
>        (* do something here *)
>      end
>

I'm not trying to start a fight, but I read this completely differently.
Wirth recognized that a Pascal implementation *may* evaluate both sides
of the and.  I don't see any way from this example to conclude that
implementations will *always* evaluate both sides.  Because short-circuit
evaluation is not required by Pascal you can never assume it, so you
have to code that way.




-- 
Doug Quale
quale@saavik.cs.wisc.edu
Newsgroups: comp.lang.scheme
From: sommerfeld@apollo.hp.com (Bill Sommerfeld)
Subject: Re: Scheme & C: a universal interface
Date: Tue, 5 Jan 1993 02:51:00 GMT
	<SINYAW.93Jan4153040@starbright.smsc.sony.com>
Organization: Hewlett Packard

In article <SINYAW.93Jan4153040@starbright.smsc.sony.com> sinyaw@starbright.smsc.sony.com (Sin-Yaw Wang) writes:

   Lastly, "register" is a lousy choice of name.

yeah, it's a reserved word in C.
From: wert@apple.com (scott comer)
Newsgroups: comp.lang.scheme
Subject: Experience with Lightship Scheme for Mac?
Date: 5 Jan 93 07:04:59 GMT
Followup-To: comp.lang.scheme
Organization: apple computer

has anyone any experience with Toolsmith for Lightship Scheme? Built
any applications with it? Care to share the code? I'm trying to decide
if I should buy it or not.

Thanks,
scott
wert@apple.com
Xref: sparky comp.lang.scheme:2856 comp.lang.c:19199
From: dyer@airplane.sharebase.com (Scot Dyer)
Newsgroups: comp.lang.scheme,comp.lang.c
Subject: Re: applying or
Date: 4 Jan 93 19:07:21 GMT
Reply-To: dyer@airplane.sharebase.com (Scot Dyer)
Organization: NCR/ShareBase Corporation

From: josh@viewlogic.com (Josh Marantz)
/// I was sort of glad to move to C/Scheme, where this short-circuiting
/// was guaranteed, although I never thought about the compiler
/// optimizations that the short-circuit guarantee prevents!  Would it be
/// legal for a C or Scheme compiler to avoid the short-circuiting if it
/// could prove there were no side effects involved, and if it looked like
/// a fruitful optimization?

Who would know it had been done?   ;)

	-- Scot

P.S.  This is a GOOD IDEA.  I think Scheme compilers will eventually keep
    track of the functional purity of functions and optimize accordingly.
    Until then, the current AND is useful in the extreme...  Especially to
    teach programmers that things aren't always what they seem!  ;)
Newsgroups: comp.lang.scheme
From: sinyaw@starbright.smsc.sony.com (Sin-Yaw Wang)
Subject: Re: Scheme & C: a universal interface
Organization: Sony Microsystems
Date: 4 Jan 93 15:30:40

In article <1993Jan1.202829.11727@netcom.com> thinman@netcom.com (Technically Sweet) writes:

   Here's how a universal Scheme&C interface should work:
   from C, you register a tuple (string, function pointer,
   argument grammar) with the interface:

	   int thing1(int);
	   int thing2(int, int);
	   int thingn(int nargs, int ...);

	   register("Thing", thing1, 1, INT);
	   register("Thing", thing2, 2, INT, INT);
	   register("Thing", thingn, NARGS, INT);

   Now from Scheme, you can say:	-> C mapping

	   (c-call "Thing" 4)	-> thing1(4);
	   (c-call "Thing" 5 6)	-> thing2(5, 6);
	   (c-call "Thing" 7 8 9)	-> thingn(3, 7, 8, 9);




Since you require C program to register, "Thing" is put into Scheme's name
space already.  Why not simply call these C functions directly?  Like:

	(Thing 4) -> thing1(4)
	(Thing 5 6) -> thing2(5, 6)
	
This way, the calling syntax is transparent.


I would also like to propose the removal of "not to expose Scheme object to
C" rule.  Instead, there should be a library of C routines to parse Scheme
objects (like pair, vector, etc.).  You can specify a native Scheme object
by registering like this:

	register("Thing", "thing_scm", 1, SCM_OBJECT);

	
Lastly, "register" is a lousy choice of name.

--
Sin-Yaw Wang, sinyaw@smsc.sony.com, 408-944-4076
Newsgroups: comp.lang.scheme
From: Kenneth Dickey <kend@newton.apple.com>
Subject: Re: Implementing continuations
X-Useragent: Nuntius v1.1.1d11
Date: Mon, 4 Jan 1993 17:14:14 GMT
X-Xxdate: Mon, 4 Jan 93 17:16:00 GMT
Organization: Bauhaus

Re: Implementing continuations

See "Implementation Strategies for Continuations", W. Clinger, A.
Hartheimer, E. Ost, in _Proceedings of the 1988 ACM Conference on Lisp
and Functional Programming_ (L&FP '88), ACM # 552880.

-Ken Dickey                                      kend@newton.apple.com
Newsgroups: comp.lang.scheme
From: marti@nugget.inf.ethz.ch (Robert Marti)
Subject: Re: applying or
Organization: Dept. Informatik, Swiss Federal Institute of Technology (ETH), Zurich, CH
Date: Tue, 5 Jan 1993 16:55:45 GMT

In article <1992Dec31.181545.19917@sharebase.com>, dyer@airplane.sharebase.com
(Scot Dyer) writes:
|> In article <MOB.92Dec30090646@strident.think.com> mob@strident.think.com
|> (Mario O. Bourgoin) writes:
|> > I am at a loss for naming an existing programming language that has AND
|> > and OR and where they do not have the same behavior as they do in Scheme.
|>
|> I don't believe any of these languages guarantee that all the sub-
|> expressions will be evaluated*.
[ ... ]
|> * except ISO Pascal which I know squat about.  It would be wirthian to
|> provide a "clean operator" (and damn the awkwardness that _everything_
|> can't be an "operator!")

Pascal as described in the 1st ed. of Jensen & Wirth did indeed specify
that both the left _and_ right Boolean sub-expression of AND and OR must
_always_ be evaluated.  I don't know about ISO Pascal, though.  Moreover,
to the best of my knowledge, Niklaus Wirth did not take part in the ISO
Pascal standardization.

Modula-2, designed by Niklaus Wirth in 1978 as a successor to Pascal,
specified "short-circuit" AND and OR.  The same is true for Modula-2's
successor Oberon, also designed by Niklaus Wirth.

-- 
Robert Marti                    |  Phone:    +41 1 254 72 60
Informationssysteme             |  FAX:      +41 1 262 39 73
ETH-Zentrum                     |  E-Mail:   marti@inf.ethz.ch
CH-8092 Zurich, Switzerland     |
From: jaffer@zurich.ai.mit.edu (Aubrey Jaffer)
Newsgroups: comp.lang.scheme
Subject: Scheme Library slib1c4 available.
Date: 8 Jan 93 21:13:54 GMT
Organization: M.I.T. Artificial Intelligence Lab.

This message announces the availability of Scheme Library release
slib1c4.

New in release slib1c4 are:
From: pgs@ai.mit.edu (Patrick Sobalvarro) is Red-Black trees.
From: lutzeb@cs.tu-berlin.de (Dirk Lutzebaeck) is version 2.2 format.

SLIB is a portable scheme library meant to provide compatibiliy and
utility functions for all standard scheme implementations.

SLIB includes initialization files for ELK 1.5, GAMBIT, MITScheme,
scheme->C, Scheme48, and T3.1.  Scm4a also supports SLIB.

Documentation includes a manifest, installation instructions, and
proposed coding standards for the library.  Documentation on each
library package is supplied.

SLIB can be obtained via ftp (detailed instructions follow) from:
altdorf.ai.mit.edu:archive/scm/slib1c4.tar.Z
prep.ai.mit.edu:pub/gnu/jacal/slib1c4.tar.Z

  ftp altdorf.ai.mit.edu [18.43.0.246] (anonymous)
  cd archive/scm
  bin
  get slib1c4.tar.Z

or
  ftp prep.ai.mit.edu (anonymous)
  cd pub/gnu/jacal
  bin
  get slib1c4.tar.Z

  `slib1c4.tar.Z' is a compressed tar file of a Scheme Library.

Remember to use binary mode when transferring the *.tar.Z files.
Newsgroups: comp.lang.scheme.c
From: isaac@sdz01.uu.ch (Isaac Lorencez)
Subject: scheme for NeXT?
Organization: The Internet
Date: Tue, 5 Jan 1993 16:26:09 GMT


Hello,
I was trying to adapt a version of scheme (a beta release 1987) obtained from
the decwrl machine and I got the message: get a wizard.
It seems that a primitive (get-environment is undefined).
Any suggestions? Do you know if there is a version for a NeXT already
available?
Thank you,
isaac
p.s. isaac@sdz01.uu.ch
From: hardy@golem.ps.uci.edu (Meinhard E. Mayer (Hardy))
Subject: Re: scheme for NeXT?
In-reply-to: isaac@sdz01.uu.ch's message of Tue, 5 Jan 1993 16:26:09 GMT
Newsgroups: comp.lang.scheme.c
Organization: Department of Physics, UC Irvine, CA 92717-4575, USA
Date: 5 Jan 93 19:38:51 GMT

There is a nice implementation of MIT-Scheme version 7.1 for the NeXT.
It includes a 68040 compiler and a NeXT front end, as well as
primitive Postscript graphics.
It is called Schematik and can be obained by ftp from ftp.gac.edu.
--
Hardy 
-----
Meinhard E. Mayer,  Department of Physics, UC Irvine 
e-mail: hardy@golem.ps.uci.edu (preferred) or MMAYER@UCI.BITNET
!!!! NO NEXTMAIL TO THESE ADDRESSES, PLEASE !!!!!