From: bill coderre
Subject: Coral/Franz Extended Common Lisp PRESS RELEASE
Date: 
Message-ID: <1563@apple.UUCP>
Alright, it's time to post a press release for Coral Extended Common
Lisp (Allegro). {Note: "ECL" is sometimes used elsewhere to refer to
ExperCommonLisp, an entirely unrelated product.}

First, be aware that Coral developed the Mac kernel mentioned here,
to which will be added the Franz ECL extensions. ECL is being renamed
"Allegro".

Second, be aware that I was a tester of the product. Now I am a user.
I have never been paid by them, nor do I have any stake in the
product. I am only working for Apple for the summer, do not confuse
my return address with any official endorsement from Apple.

Anyway, this is a press release I made up, not them. I've brought it
in line with their releases, but mine has considerably more detail.
Any errors in specification are probably my fault.

			 Allegro Common Lisp
			    Coral Software
			      POBox 307
			  Cambridge MA 02142
			    (617)547-2662
		 Outside Massachusetts: (800)521-1027

	    "A programming environment for the CDR of us."

Allegro Common Lisp for the Macintosh line of personal computers is
now shipping for $399.95, INTRODUCTORY PRICE. Allegro is not copy
protected and includes a money-back guarantee.

Allegro CL contains the FULL Common Lisp as specified in *Common
Lisp: the Language* by Guy Steele. Everything mentioned in the book
is implemented. 

Allegro CL will run off floppy disks and will run in a 1MB MacPlus.
At least 2MB and a hard disk are recommended. (Related files
currently clock in at 1.6MByte.)

Allegro will run approximately 5 times faster on a 16MHz 68020
machine, for example a Mac II or a third-party processor upgrade.

When a 68881 coprocessor is present, Allegro will call it directly.

Alegro also supports "leading brand" large screen monitors.

But that's just the start.....

Allegro uses a fast, incremental native code compiler, and is truly
tail-recursive. File compilation is provided now, but standalone
applications are "coming soon."

There is also a low-level interface to allow acess to any Mac OS or
toolbox trap. It provides all the necessary glue to build stack
records, pascal data types, registers, etc. In addition, a Lisp
Assembly-language Programming (LAP) package is "coming soon", and a
foreign function interface will be available (to MPW C, Pascal, and
Assembler). 

There is an object-oriented programming system incorporated: a
version of ObjectLisp, which was developed by Gary Drescher. Despite
being easy to learn and use, ObjectLisp provides powerful multiple
inheritance features. CLOS (the official Common Lisp Object System)
will be "coming soon." (The spec isn't done yet, after all!) Flavors
is "coming soon."

There is also object oriented support for windows. Your window
subclass can fully build on the pre-existing window class. Windows
are also a subclass of streams, so all the CL stream commands will
work. Many quickdraw primitives are provided in high-level form, too,
including operations on regions and pictures.

Menu items, menus, and menubars are provided as objects. Support is
provided so that when a user selects a menu item, an associated
function is called. Menus have all the style and features of regular
Macintosh menus, except for icons and hierarchical menus. Users may
make their own menus and change the menubar, menus, and menu items in
any way.

Dialogs (both modal and modeless) are provided as high-level objects.
Dialog items, similar to menu items, can be subclassed, and call a
function when triggered. Normal dialog items are supported, as well
as one-dimensional scrollable lists, and 2-D scrollable tables.

Simple event-handling is provided. It is easy to write Allegro CL
code that works similarly to a "standard" Macintosh event-driven
program.

A pathname subsystem, which extends and customises CLtL's File System
Interface to the Macintosh environment, is provided.

Built-in is FRED the Editor, an editor which provides many commands
from EMACS, as well as the standard Macintosh editing modes, extended
for a Lisp environment. FRED can be used in your programs, to edit
your own buffers. Of course, full documentation is provided for
extending and modifying FRED's behavior. FRED has a key bindings
window that shows current bindings.

A stack backtrace window is provided for debugging. It also allows
the inspection of call frames, and the temporary binding of call
values, modification of values, evaluation of functions in the
call-frame environment, etc.

A visual stepper is provided, for watching functions execute, and has
similar functionality to the backtrace window.

An inspector with features to examine any CL or Mac datatype included.
The user need merely click on a field or value to inspect it further.

Meta-point is provided, and works across multiple source files.
Edit-definition is provided. An Apropos window is provided.

A kill ring is maintained, has a window interface, and hooks into the
Macintosh Clipboard.

Windows are provided for user preferences for printing and environment
variables. A windows menu is provided for selecting any window.

A "List of Definitions" buffer is provided, with buttons for buffer
and alphabetical order. It also allows jumping directly to a function.

Also "Coming Soon":
Macintosh User Interface Designer
Stack Groups
Common Windows

From: Joel West
Subject: Re: Coral/Franz Extended Common Lisp PRESS RELEASE
Date: 
Message-ID: <3700@sdcsvax.UCSD.EDU>
I'm not a big Lisp fan, but $400 seems steep for a single-language
development system on the Mac.  Borland and Think seem to have the
right idea in pricing between $125 and $200.

At least it's not the $800 (or whatever it is) for ExperCommon Lisp.
But $400 is enough to make a guy try Scheme...
From: Gordon E. Banks
Subject: Re: Coral/Franz Extended Common Lisp PRESS RELEASE
Date: 
Message-ID: <792@cadre.dsl.PITTSBURGH.EDU>
In article <····@sdcsvax.UCSD.EDU> ···@sdcsvax.UCSD.EDU (Joel West) writes:
>I'm not a big Lisp fan, but $400 seems steep for a single-language
>development system on the Mac.  

But with the University discount, it is only $200, which is quite 
reasonable.
From: Chris Sterritt
Subject: Re: Coral/Franz Extended Common Lisp PRESS RELEASE
Date: 
Message-ID: <337@ge-mc3i.UUCP>
>In article <···@cadre.dsl.PITTSBURGH.EDU> ···@cadre.dsl.pittsburgh.edu.UUCP (Gordon E. Banks) writes:
>>In article <····@sdcsvax.UCSD.EDU> ···@sdcsvax.UCSD.EDU (Joel West) writes:
>>I'm not a big Lisp fan, but $400 seems steep for a single-language
>>development system on the Mac.  
>But with the University discount, it is only $200, which is quite 
>reasonable.

Well what about us NON-Univ types?

Seriously, PLEASE give Coral a call at 800-521-1027.  I talked to a very
friendly and knowledgable person there, who even understood my is-it-like-
Symbolics-in-this way questions.  

The upshot is that there will be a cheap ("Coral Lisp") version, and an 
expensive version ("Allegro Extended common lisp").  He was pretty vague
on what the differences would be (Coral Lisp, the cheap one at ~$100, is due
out in about two months), but DID indicate that the cheap one would have the
compiler, and would be 'pretty full' common lisp.  He thought that they might
not add the programmable editor, packages, and defstructs.  I complained, and
he was nice, but firm.

THIS IS THE TIME THAT WE SHOULD ALL START A PHONE-IN CAMPAIGN to get them to
bring out the 'full' CL for the cheap price!  They just don't believe that they
will sell more than four times as many at one-quarter the price, as I do.
(I'll bet that Think technologies thinks this way too, but I dunno :-).

I said that I thought that they might lose to the Scheme that's out, but they
said that the scheme compiler system is $400; the $125 scheme DOES NOT have
a compiler, and so is slow.  Their cheap one will.

Oh well... I did hope that they would do the right thing.  I guess they have
their reasons for making it expensive, BUT I'll bet a good call-in campaign
could have SOME effect...

thanks,
chris sterritt
From: Joel West
Subject: Re: Coral/Franz Extended Common Lisp PRESS RELEASE
Date: 
Message-ID: <3729@sdcsvax.UCSD.EDU>
The cheap one for $100 is what I was after.  If it's the same
exact language (compatible in both directions), and they
offer a $300 upgrade when you outgrow the original, then
this is very reasonable (and smart on their part).
-- 
	Joel West  (c/o UCSD)
	Palomar Software, Inc., P.O. Box 2635, Vista, CA  92083
	{ucbvax,ihnp4}!sdcsvax!jww 	···@sdcsvax.ucsd.edu
   or	ihnp4!crash!palomar!joel	····@palomar.cts.com
From: bill coderre
Subject: Re: Coral/Franz Extended Common Lisp PRESS RELEASE
Date: 
Message-ID: <3733@apple.UUCP>
Well, please consider the following points:

1) Reducing the retail price by 75% will reduce their profit margin
by some amount a lot more than 75%, more like 90%, since the fixed
cost of the package stays constant. (These numbers do not necessarily
represent reality and are provided for argument only.)

Therefore, they would have to sell more like 10 times as many
copies to make up for the price redux. See an introductory Economics
book for further details....

2) That no piece of software intrinsically "costs" any fixed amount.
A better measure is to examine the VALUE of the system to you. If you
are a "Sunday bitdiddler", Allegro might not seem valuable enough to
merit its cost. Coral will be creating "Coral Lisp" in the near
future, which will be less powerful and cost less.

For people who use Lisp a lot, the hundreds and hundreds of extra
features that Allegro supplies are invaluable for the expedient
creation of powerful programs.

(There are over 7000 entries in the symbol and function tables on
booting, not counting internal functions users shouldn't use.)

3) Coral offers educational and volume discounts. Call for details.

4) The price of $399.95 should be considered INTRODUCTORY.

5) The author is a beta-tester and satisfied user of the product, who
believes in it strongly enough to buy it.

6) The opinions expressed in this post are not necessarily those of
Apple, Coral, or MIT.

10) Any further discussion of the value of Lisps should be routed via
email..............................................................bc
From: ···@faccs.UUCP
Subject: Re: Coral/Franz Extended Common Lisp PRESS RELEASE
Date: 
Message-ID: <120@faccs.UUCP>
In article <···@cadre.dsl.PITTSBURGH.EDU>, ···@cadre.dsl.PITTSBURGH.EDU (Gordon E. Banks) writes:
> In article <····@sdcsvax.UCSD.EDU> ···@sdcsvax.UCSD.EDU (Joel West) writes:
> >I'm not a big Lisp fan, but $400 seems steep for a single-language
> >development system on the Mac.  
> 
> But with the University discount, it is only $200, which is quite 
> reasonable.

Great, I think I'll start one so I can get software at (somewhat) reasonable
prices!
-- 
Think Green,
Patrick Logan (···@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!"
From: Doug Alan
Subject: Re: Coral/Franz Extended Common Lisp PRESS RELEASE
Date: 
Message-ID: <1367@bloom-beacon.MIT.EDU>
In article <····@sdcsvax.UCSD.EDU> ···@sdcsvax.UCSD.EDU (Joel West) writes:

> I'm not a big Lisp fan, but $400 seems steep for a single-language
> development system on the Mac.  Borland and Think seem to have the
> right idea in pricing between $125 and $200.

> At least it's not the $800 (or whatever it is) for ExperCommon Lisp.
> But $400 is enough to make a guy try Scheme...

[You should try scheme anyway!]

Actually, $400 is quite reasonable considering the quality of this
product.  Running on a Mac II, it's performance is pretty incredible.
Think of how much cheaper it is than a Symbolics machine!

In any case, the people at Coral are going to come out with another
version of their Common Lisp that has a couple features removed
(packages and a couple other things) but costs under $100.

|>oug /\lan
From: ·····@mind.UUCP
Subject: Re: Coral/Franz Extended Common Lisp PRESS RELEASE
Date: 
Message-ID: <1189@mind.UUCP>
I've been working with Franz Lisp on a Minivax 2 over the past year and
I'm wondering if any other users have noted difficulties - or bugs -
in the following not unsignificant areas:
1. the debugger, when called in the break loop, doesn't access the stack
   and so is entirely useless. (It does work if inserted somewhere within a
   function definition but that makes it tedious to use.) Wilensky's book
   makes it clear that this ought not to be the case. Not being inclined
   to perform the hack, I tried recompiling a later version of fixit.l
   that we got with a couple of RT's, but I got an error msg after the gc
   (and of course the package is useless unless compiled). Any ideas?

2. Similar problems with step.l, which doesn't do what the manual claims
  it should, unless inserted in a fn def.

Besides this, I was wondering if there is an X interface for franz around?
And generally passing lispvals to c routines? I've done this, but it only
works in limited contexts - now I can't be alone in this.

Thanks for all replies -
From: bill coderre
Subject: Re: Coral/Franz Extended Common Lisp PRESS RELEASE
Date: 
Message-ID: <6021@apple.UUCP>
Hang on a sec.

The Coral product for Macintosh was completely implemented by Coral,
not by Franz. Soon, it will have lots of the Franz extensions, but
for now, it is a disparate product.

Also, since it is a Mac product, asking questions about a different
Microvax product is inappropriate.

I hope someone over in comp.lang.lisp can help, but please remove
comp.sys.mac from the newsgroups.

Incidentally, Coral has a pretty neat debugger. It's loads better than
any other Mac lisp debugger, but not as good as the Symbolics debugger
(not surprising)...................................................bc
From: Dave Seaman
Subject: Re: Coral/Franz Extended Common Lisp PRESS RELEASE
Date: 
Message-ID: <5204@j.cc.purdue.edu>
In article <····@mind.UUCP> ·····@mind.UUCP (Eliot Handleman) writes:
>I've been working with Franz Lisp on a Minivax 2 over the past year and
>I'm wondering if any other users have noted difficulties - or bugs -
>in the following not unsignificant areas:
>1. the debugger, when called in the break loop, doesn't access the stack
>   and so is entirely useless. 

I have noticed under 4.3bsd and predecessors that the Franz debugger seems
to lose track of the stack when it autoloads.  My solution has been to exit
the debugger and re-invoke the function that caused the error.  The
debugger works from then on.

>2. Similar problems with step.l, which doesn't do what the manual claims
>  it should, unless inserted in a fn def.

I don't use the stepper, but you might try the same technique on it.
-- 
Dave Seaman	  					
···@j.cc.purdue.edu