HDTenEightyP/NetNews huggingface dataset:
From: cfry@MIT.EDU (Christopher Fry)
Newsgroups: comp.lang.lisp.mcl
Subject: Re: Continuing education
Date: 18 Nov 92 21:11:24 GMT

> From: Michael D Young <myoung@magnus.acs.ohio-state.edu>
> Subject: Continuing education
> To: info-macl@cambridge.apple.com (Macintosh Common Lisp Bulletin Board)
> Date: Wed, 18 Nov 92 13:17:35 EST
> Cc: myoung@magnus.acs.ohio-state.edu (Michael D Young)
> X-Mailer: ELM [version 2.3 PL11]
> 
> All,
> I originally purchased MCL to write a  small system for use in my dissertation,
>  and as far as that goes MCL is a success. However, I am really a novice progra
> mmer/Lisper and I have an introductory LISP course under my belt which gets me
> about as far as defstruct. No additional courses are available to me at OSU.
> 
> Does anyone provide seminars/summer programs that focus on LISP/CLOS/MCL?
> I would be willing to travel to attend such a program and even pay fees (both w
> ithin reason).
> 
> Any suggestions? ( I would prefer a course, I have several good books but a boo
> k can only help so much. )
> 
> Thanks in advance,
>      Michael Young

The Lisp User's & Vendors  conference [LUV 93] will be in Cambridge, USA
Aug 9 -> 13, 93
Usually there are tutorials but they aren't necessarily about basic Common Lisp.
Last year there were tutorials about CLIM, Error Handling. etc.
Most of what you need to know to program in Lisp is not basic lisp but
about peripheral pieces of software [like window systems], effective use of tools 
like an editor, inspector, stepper, and, esp if you want to write a big program, 
strategy for managing complexity.

Paradigms of AI by Peter Norvig is huge and good, though it doesn't talk about
tools much, probably because they are CL-implementation dependent.
From: bill@cambridge.apple.com (Bill St. Clair)
Newsgroups: comp.lang.lisp.mcl
Subject: Re: Adding MOVEM to LAP
Date: 23 Nov 92 20:15:47 GMT

At  0:14 11/21/92 +0000, Erann Gat wrote:
>The LAP assembler doesn't seem to handle the MOVEM instruction.  LAP is
>supposed to be extensible (via the DEFLAPGEN macro).  Has anyone added
>MOVEM before I start reinventing the wheel?

It works fine for me. Maybe you're getting the form of the arguments
wrong. The first arg is a vector of register names. The second is a
standard destination addressing mode (usually "areg@+" or "-@areg").
Here's an example from the file "ccl:lib;windoids.lisp" which is on
the MCL 2.0 CD:

(in-package :ccl)

(defun windoid-wdef (&lap 0)
  (lap
    @lispA5
    (dc.w 0 0)
    @defpascal
    (dc.w 0 0)
    (sub.l ($ 4) sp)                    ; space for defpascal address
    (link a6 ($ 0))
    (equate _variation 12)
    (equate _wptr (+ _variation 2))
    (equate _message (+ _wptr 4))
    (equate _parameter (+ _message 2))
    (equate _return (+ _parameter 4))
    (movem.l #(a5 d0 a0) -@sp)          ; <========== MOVEM ************
    (lea (^ @defpascal) a5)
    (move.l @a5 (a6 4))                 ; defpascal entry point
    (move.l -@a5 a5)                    ; Lisp's A5
    (if# (ne (tst.b (a5 $gcON)))
      (move.w (a6 _message) d0)
      (if# (ne (cmp.w ($ #.$wHit) d0))
        ; Maybe we should frame the strucRgn on a draw command
        (move.l ($ 0) (a6 _return))
       else#
        (sub.w ($ 2) sp)                ; result from _PtInRgn
        (spush (a6 _parameter))
        (move.l (a6 _wptr) a0)
        (spush (a0 #.(get-field-offset :windowrecord.strucrgn)))
        (dc.w #_PtInRgn)
        (if# (ne (tst.w sp@+))
          (move.l ($ #.$wInContent) (a6 _return))
          else#
          (move.l ($ #.$wNoHit) (a6 _return))))
      (movem.l sp@+ #(a5 d0 a0))        ; ; <========== MOVEM ************
      (unlk a6)
      (add.l ($ 4) sp)
      (move.l sp@+ (sp (- _return 12)))
      (lea (sp (- _return 8)) sp)
      (rts)
     else#
      (movem.l sp@+ #(a5 d0 a0))
      (unlk a6)
      (rts))))
From: espen@coli.uni-sb.de (Espen J. Vestre)
Newsgroups: comp.lang.lisp.mcl
Subject: can I copy to a drop folder?
Date: 19 Nov 92 11:03:45 GMT
Organization: Computerlinguistik, Universitaet des Saarlandes
X-Xxmessage-Id: <A73132D070014453@mp-mac10.coli.uni-sb.de>
X-Useragent: Nuntius v1.1.1d12
X-Xxdate: Thu, 19 Nov 92 11: 02:24 GMT

I would like to be able to copy a file to a "drop" folder, a folder into
which I can drop things (with the Finder), but which I am not allowed to
open.
Using COPY-FILE directly doesn't work, because COPY-FILE tries to look
into the folder, and thus violates the protection of the folder.  
Is it possible at all to do such a copy-operation from MCL?  If not, is
it possible to do it by sending appleevents to the Finder?
--------------------------------------------------------------
Espen J. Vestre,                          espen@coli.uni-sb.de
Universitaet des Saarlandes,        
Computerlinguistik, Gebaeude 17.2 
Im Stadtwald,                          tel. +49 (681) 302 4501
D-6600 SAARBRUECKEN, Germany           fax. +49 (681) 302 4351
--------------------------------------------------------------
From: jbk@world.std.com (Jeffrey B Kane)
Newsgroups: comp.lang.lisp.mcl
Subject: Re: rlet keyword documentation
Date: 21 Nov 92 18:39:17 GMT


> I was wondering where the documentation was for all the possible keywords
> that can be used with rlet.  The documentation under rlet doesn't list them
> and since it is a compiled macro, there is no way to look at the source and
> see what values it tests for.


Well at the risk of talking to myself, I found the answer and wanted to post it
in case it wasn't obvious to anyone else.  It turns our that there are two global
variables:

                     *record-types*

                            and

                     *mactypes*

 which return:

(:GDEVICE :PICTURE :PENSTATE :WINDOWRECORD :GRAFPORT 
:PATTERN :BITMAP :RECT)

and 

(:INVALID-TYPE :STRING :OSTYPE :POINT :TEHANDLE :HANDLE 
:QELEMPTR :ARRAY :POINTER :UNSIGNED-LONGINT :LONGINT 
:SIGNED-LONGINT :LONG :UNSIGNED-LONG :SIGNED-LONG 
:UNSIGNED-WORD :WORD :SIGNED-WORD :UNSIGNED-SHORT 
:SHORT :SIGNED-SHORT :INTEGER :UNSIGNED-INTEGER 
:SIGNED-INTEGER :BYTE :UNSIGNED-BYTE :SIGNED-BYTE 
:CHARACTER :BOOLEAN)

respectively.

There should probably be a cross reference to these variables in some of the 
sections that allocate records, such as rlet and %stackblock so the new user
has a place to begin.

             Jeffrey



======================================
Jeffrey Kane, MD
Kane Biomedical Systems
Boston, MA

Internet    jbk@world.std.com
Compuserve  74206,640
AppleLink   D0738

[Don't take life too seriously... it's not like anyone gets out of it alive.]
Newsgroups: comp.lang.lisp.mcl
From: gat@robotics.jpl.nasa.gov (Erann Gat)
Subject: Adding MOVEM to LAP
Organization: Jet Propulsion Laboratory
Date: Sat, 21 Nov 1992 00:14:15 GMT

The LAP assembler doesn't seem to handle the MOVEM instruction.  LAP is
supposed to be extensible (via the DEFLAPGEN macro).  Has anyone added
MOVEM before I start reinventing the wheel?

Thanks,
Erann Gat
gat@aig.jpl.nasa.gov
gat@robotics.jpl.nasa.gov
(Don't reply to this message.  Its return address (gat@forsight2) will
not work.)
From: rp23+@andrew.cmu.edu (Ray Pelletier)
Newsgroups: comp.lang.lisp.mcl
Subject: Re: old hardcopy.lisp
Date: 18 Nov 92 15:40:13 GMT

I've uploaded a version of hardcopy.Lisp
which seems to work for MCL 2.0 final.
Windows must however be an instance of HARDCOPY-WINDOW.
I leave it for someone else to get
the code to work for the WINDOW class.

--Ray Pelletier
From: luchsinger@urz.unibas.ch (Michel Luchsinger)
Newsgroups: comp.lang.lisp.mcl
Subject: MUSICOLOGY
Date: 23 Nov 92 10:12:05 GMT

Hello, I'm studying musicology and am interested in all lisp code in connection with music - especially storing musical information and representing musical notes on a screen; thanks in advance for any hints..
From: bill@cambridge.apple.com (Bill St. Clair)
Newsgroups: comp.lang.lisp.mcl
Subject: Re: ffi to MCL
Date: 23 Nov 92 20:14:40 GMT

>Date: Thu, 19 Nov 92 17:24:03 EST
>From: staley@carnap.srl.ford.com (Scott M. Staley)
>To: bill@cambridge.apple.com
>Subject: Re: ffi to MCL
>
>> From bill@cambridge.apple.com Thu Nov 19 13:35:20 1992
>> Date: Thu, 19 Nov 1992 13:41:52 -0600
>> To: staley@carnap.srl.ford.com (Scott M. Staley)
>> From: bill@cambridge.apple.com (Bill St. Clair)
>> Sender: bill@cambridge.apple.com (Unverified)
>> Subject: Re: ffi to MCL
>> Cc: bill@cambridge.apple.com
>> Content-Length: 1178
>> 
>> >Bill.
>> >
>> >I posted a question to the info-mcl a while back and got no takers so 
>> >I thought I would try you direct. I am looking to get a C compiler to
>> >write c code to link with mcl. There is something in the MCL manual about
>> >c compiler must generate mpw compatible .o files. What does that entail?
>> >
>> >Does it mean the mpw is the only C I can use the ffi with, or could 
>> >Think C or others be used. What do you recommend to write C code for MCL.
>> >
>> >I have no desire to but a c compiler to write plain c. My only purpose is
>> >to hook to MCL.
>> 
>> I have heard that Think Pascal is able to import Think C projects and
>> write MPW compatible libraries, but I have never done it. I know of no
>> other way to make Think C generate object files that MCL's FFI knows
>> how to parse.
>> 
>> One other way to run Think C generated code from MCL is to create a
>> code resource. Guillaume Cartier has written some code to simplify finding
>> entry points in this code resource. His code is on the MCL 2.0 CD in
>> the folder:
>> 
>>    MCL 2.0 CD:User Contributed Code:Think C Interface:
>> 
>> It is also available for anonymous FTP from cambridge.apple.com in the file:
>> 
>>   /pub/mcl2/contrib/Cartiers-Contribs-1.2.sea.hqx
>> 
>> 
>
>Bill.
>
>Thanks for the come back. Can you say what is the minimimum mpw C stuff I
>should buy to do the above. Also I might mention that the C code I hope
>to integrate is in ANSI C.

I know very little about developing C on the Macintosh. I used Think C
two or three years ago to do a small project, and have used MPW a little
bit to assemble MCL's kernel, but that is the extent of my experience.
From looking at the November, 1992 APDA catalog, I would guess that you would
need to get the MPW C Bundle, which was listed for $425. The description of
the MPW C compiler version 3.2.4 says "The MPW C compiler supports K&R C,
as well as many ANSI extensions to C, including function prototypes and strong type checking. It includes a standard C library that offers the functions
described in the ANSI C standard." I do not know if "many ANSI extensions"
means that it will have problems with your "ANSI C", nor do I know if
Think C is closer to the ANSI standard (or if that will matter for your
code), or how the effort involved in building Think C stubs using Guillaume
Cartier's package compares to writing DEFFCFUN stubs to interface to MPW C.

Can someone else help out?
From: jbk@world.std.com (Jeffrey B Kane)
Newsgroups: comp.lang.lisp.mcl
Subject: Re: ccl:scrolling window bug?
Date: 17 Nov 92 18:05:04 GMT


I'm not sure if there is a reason for not doing this, but I've noticed
that the class ccl::scrolling-windows does not seem to set the update
region to exclude it's own scroll bars before it continues with the call
chain.  This means that any views inside of it will automatically draw
into the scroll bar area.  I'm assuming that the "view-draw-contents"
methods are all called with the appropriate "with-focused-view" or 
"with-focused-dialog-item" by the call chain (read that as I'm not
using this macro within my "view-draw-contents" methods since I assumed
all that is automatically handled).  Also note that resizing a scrolling
window is what brings out this view.  If I simply cover up the subview with
another window (such as the listener), then uncover it, the scroll bars
seem to be drawn properly.

Is there a fix available for this or am I doing this wrong?

            Jeffrey


;; define a test class
(defclass test-view (view)
  nil)

;; make this a separate routine, so we can move it around the call chain easily
(defmethod draw-code ((me test-view))
   (with-fore-color *yellow-color*
    (paint-rect me 0 0 (point-h (view-size me)) (point-v (view-size me))))
  (with-fore-color *red-color*
    (move-to me 0 0)
    (line-to me (point-h (view-size me)) (point-v (view-size me)))
    (move-to me (point-h (view-size me)) 0)
    (line-to me 0 (point-v (view-size me)))))

;;
;; specialize various methods to see where the problem is
;;

;; try the around method
(defmethod view-draw-contents :around ((me test-view))
  ;; I tried inserting the draw-code here, both before and after
  ;; the call-next-method with no change
  (call-next-method)
  (draw-code me))

;; try the primary method
(defmethod view-draw-contents ((me test-view))
  ;; I tried inserting the draw-code here, both before and after
  ;; the call-next-method with no change
  (call-next-method))


(defmethod view-draw-contents :after ((me test-view))
 ;; the drawing does not good here either
)

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;; Create the window with a large subview in it
;;

(make-instance 'ccl::scrolling-window
  :window-title "test"
  :color-p t
  :view-size #@(300 100)
  :view-subviews
  (list (make-instance 'test-view
          :view-position #@(20 20)
          :view-size #@(300 100))))





======================================
Jeffrey Kane, MD
Kane Biomedical Systems
Boston, MA

Internet           jbk@world.std.com
Compuserve  74206,640
AppleLink     D0738
From: straz@cambridge.apple.com (Steve Strassmann)
Newsgroups: comp.lang.lisp.mcl
Subject: Paradigms of AI by Peter Norvig
Date: 23 Nov 92 16:28:48 GMT

>Date: 23 Nov 92 10:58:42 EST
>From: Bruce Lester <72110.1107@CompuServe.COM>
>Subject: Paradigms of AI by Peter Norvig
>Apparently-To: <info-macl@cambridge.apple.com>
>
>Does anyone know where I can get "Paradigms of AI by Peter Norvig"?  Publisher
>name and address.
>
>Bruce Lester
>Pillsbury


 Morgan Kaufmann Publishers
 2929 Campus Dr., Suite 260
 San Mateo, CA 94403
 415-578-9911
 800-745-7323

The book is ISBN 1-55860-191-0

The code examples in the book are included in the MCL 2.0 cd-rom.
They are also available by anonymous ftp from unix.sri.com, and on
diskette directly from the publisher, as follows:
 Mac          ISBN 1-55860-227-5
 DOS 3.5"     ISBN 1-55860-228-3
 DOS 5.25"    ISBN 1-55860-229-1
From: straz@cambridge.apple.com (Steve Strassmann)
Newsgroups: comp.lang.lisp.mcl
Subject: file access FAQ
Date: 19 Nov 92 16:04:27 GMT

>Date: Thu, 19 Nov 92 08:40:28 -0600
>From: David Kieras <kieras@engin.umich.edu>
>To: info-mcl@cambridge.apple.com
>Subject: file access FAQ
>Cc: kieras@engin.umich.edu
>
>This should be an FAQ:  What's a good way to access files in
>different directories in MCL, in a way that will not require code
>changes to run in other CL implementations or on other  Macs, and
>allows some independence of the directory hierarchy?   

Use logical pathnames (see page 628 of CLtL2), which MCL 2.0 supports.

If you're using a CL that doesn't support them yet, try
Mark Kantrowitz's logical pathname utility, available by ftp from CMU
or on the MCL CD-ROM in "User Contributed Code:Defsystem:Logical Pathnames".
From: kab (Kim Barrett)
Newsgroups: comp.lang.lisp.mcl
Subject: Re: Making a lambda-expr more like a fn
Date: 16 Nov 92 15:26:01 GMT

> One of the changes to CL2 that bit me has been that
> raw lambda's can no longer be funcall'd (or apply'd)
> directly.
> 
> With CMULisp, I have remedied this by coercing the lambda
> into a function first:
> 
>         (setf (org-lexpr p) (coerce lexpr 'function))
> 
> But CCL::COERCE-TO-FUNCTION won't have it:

This is a known bug.  I believe there's a patch for it, but don't remember the 
name.  Try asking bug-mcl.

> I was able to get what I wanted compiling the form instead.  However, in
> this application, I would like very much to avoid the compilation overhead
> if at all possible.  Can I?

Since MCL is (for the most part) a compiled-only implementation, there is 
actually no real difference between the forms (coerce lexpr 'function) and 
(compile nil lexpr), except that the former fails due to a bug.  That is, if 
the bug were not present then the call to coerce would call the compiler to 
process the lambda expression.
From: UK0392@AppleLink.Apple.COM (EHN & DIJ Oakley,GB,IDV)
Newsgroups: comp.lang.lisp.mcl
Subject: Re: I Want my own framework...
Date: 15 Nov 92 16:40:00 GMT

Tom,
 
A small group of us have been debating a (lean and mean) MCL application
framework for the last few months.  Although discussions are a bit quiescent at
present (partly because I am still working out how to have an efficient and
easy AppleLink and Internet group mail system for us), there are still plenty
of us who have gone at least some of the way down that road.
 
My first suggestion is why do you not 'join' us (once I can get my own Internet
mail system going, or someone comes to my rescue with a better alternative!)?
 
My second suggestion is that you should go ahead and try your ideas out.  One
of my main criticisms of other people's ideas for such a framework remains that
it is relatively easy to come up with ideas, but they need tempering with
reality.  In your case, I would suggest that you do *not* try replacing or
duplicating MCL's own event handling code.  Rather, learn how to make best use
of it.  Studying the MCL event handling source etc. from the MCL CD is a
wonderful insight, and should show you some really neat ways to get where you
are heading without trashing all the good stuff in MCL.
 
My third suggestion is that you should look at a good application framework
like MacApp or TCL, which illustrate (within their accepted limitations) the
sort of thing which can be achieved, and some techniques for doing so.
However, remember what I have said above and work with, rather than against,
the existing features of MCL.
 
My final suggestion is to head for full factoring (FF) of events/commands into
AppleEvents.  MCL is one of the neatest environments for working with
AppleEvents in a clean and sensible way, but unless you start off FF, it is a
lot of work to go FF later.  And if you do not FF, then all sorts of doors
close on you.
 
Enjoy it!
 
Howard.
From: rsargent@kame.media.mit.edu (Randy Sargent)
Newsgroups: comp.lang.lisp.mcl
Subject: Threads?
Date: 17 Nov 92 00:20:02 GMT


From: bill@cambridge.apple.com (Bill St. Clair)
> To do this right, you really need multiple threads, which MCL doesn't
> have (yet). ...

When will MCL have threads??  They would be really useful to me...

-- randy
From: cartier@math.uqam.ca (Guillaume Cartier)
Newsgroups: comp.lang.lisp.mcl
Subject: Re: handler-case problem?
Date: 18 Nov 92 21:02:10 GMT

This one should certainly go into a MCL FAQ.
Almost everyone got bite by this one at one time or another.

<---
| So when I enter this form I get this behavior:
| ? (handler-case (/ pi 0) (DIVISION-BY-ZERO (x) (print x)))
| > Error: While compiling an anonymous function :
| >        Error: "Can't divide by zero." 
| >        signalled during compile-time evaluation of (/ 3.141592653589793 0) .
| > Type Command-. to abort.
| See the RestartsI menu item for further choices.
| 1 > (local 7)
| #<DIVISION-BY-ZERO #x1924C49>
| 1 > (type-of (local 7))
| DIVISION-BY-ZERO
| 1 > 
| Aborted
| ? 
| 
| Am I doing something wrong or is handler-case used-up?
| Thanks.
--->

The problem is that the error occurs during compilation. The compiler
recognizes 0 as a constant and sees that a division by zero must occur
and so saves you from the error occuring at runtime.

Try the following:

(let ((x 0))
  (handler-case (/ pi x) (DIVISION-BY-ZERO (x) (print x))))

Guillaume.

*********************************************************************
* Guillaume Cartier                 (514) 844-5294 (maison)         *
* L.A.C.I.M.                        (514) 987-4290 (bureau)         *
* Universite du Quebec a Montreal   (514) 987-8477 (telecopieur)    *
* Montreal, Quebec, Canada          cartier@math.uqam.ca (internet) *
*********************************************************************
Newsgroups: comp.lang.lisp.mcl
From: firby@avarice.uchicago.edu (Jim Firby)
Subject: The Radius Rocket MCL Incantation?
Organization: University of Chicago Computing Organizations
Distribution: na
Date: Mon, 23 Nov 1992 18:35:04 GMT

There has been some discussion lately about running MCL on the Radius
Rocket.  Well, I just got one and everything runs but MCL.

Could someone who has it working send me the magic incantation that I
need?  Do I need a particular combination of System 7 and the TuneUp?
Do I need some strange patch?  Do I have to make sure that my Mac
faces the rising sun?

Thanks a lot.

Jim Firby
University of Chicago
From: UK0392@AppleLink.Apple.COM (EHN & DIJ Oakley,GB,IDV)
Newsgroups: comp.lang.lisp.mcl
Subject: GA posting to archive
Date: 16 Nov 92 20:20:00 GMT

Friends,
 
I have posted the following to /pub/MCL2/contrib on cambridge.apple.com:
 
GAL.sea.Hqx
 
being Bill Spears' genetic algorithm (GA) suite ported to MCL 2.0 by myself.
If you have wanted to try out GAs in Common Lisp, this is an excellent start
for you.  Documentation is fairly minimal - but sufficient for anyone who
understands the concepts etc. - but the code is clear and adaptable for most
variants of the basic GA.  I should emphasise that all the work on this was
done by Bill Spears, of NRL, and all I have done is a little porting to MCL
2.0.  Any improvements and adaptations should be sent to Bill Spears himself,
although queries on the MCL port should come to me, please.
 
I anticipate improving and enhancing this code over the coming months, and will
post updates in the Cambridge archive in due course.
 
Howard.
Howard Oakley, EHN & DIJ Oakley,    * Howard@quercus.demon.co.uk
EHN & DIJ Oakley, Brooklands Lodge, * AppleLink UK0392
Park View Close, Wroxall, Ventnor,  * CompuServe 70734,120
Isle of Wight UK PO38 3EQ           * Tel +44 983 853605, fax 853253
From: george@hsvaic.boeing.com (George Williams)
Newsgroups: comp.lang.lisp.mcl
Subject: GECO v1.0 now in the cambridge archive
Date: 16 Nov 92 14:03:23 GMT


I'm announcing public distribution of a genetic algorithm shell I have
been working on in my spare time for the last couple of months.  It's
available on cambridge.apple.com in /pub/mcl2/contrib/ as the following
files:

GECO-v1.0.cpt.hqx	binhex'd Compact Pro archive
GECO-v1.0.tar.Z		compressed tar file for Unix machines (no MCL fonts)
GECO.abstract		a brief description

I've also updated the ABSTRACTS and README files.  The abstract file is
appended to this message.

George Williams            BCS Huntsville Artificial Intelligence Center
Boeing Computer Services   Internet: george@hsvaic.boeing.com
POBox 240002, M/S JY-58    UUCP: ...!uw-beaver!bcsaic!hsvaic!george
Huntsville AL 35824-6402   Phone: 205+464-4968 FAX: 205+464-4930

Genetic Evolution through Combination of Objects (GECO)

GECO is a toolbox for constructing genetic algorithms. It provides a set
of extensible classes and methods designed for generality. Some simple
examples are also provided to illustrate the intended use.

Author:
    George P. W. Williams, Jr.
    1334 Columbus City Rd.
    Scottsboro, AL 35768
    george@hsvaic.boeing.com

Bug reports, improvements, and feature requests should be sent to
george@hsvaic.boeing.com. I will try to respond to them. Ports to other
lisps are also welcome.

GECO should be completely portable among CLtL2 compliant Common Lisps,
though it has presently been tested only with the following lisp
implementations:
 - MCL 2.0 (Apple's Macintosh Common Lisp)

Version History:
1.0 16-Nov-92	GPW	Initial public release.
Newsgroups: comp.lang.lisp.mcl