cox@renoir.Berkeley.EDU (Charles A. Cox) (01/01/70)
>In article <1189@mind.UUCP> eliot@mind.UUCP (Eliot Handleman) writes: >>I've been working with Franz Lisp on a Minivax 2 over the past year and It's important not to confuse the two products available from Franz Inc. in this discussion about the new Coral/Franz Common Lisp (known as "Allegro CL"). Franz Inc.'s earlier product Franz Lisp is a dialect of Lisp that precedes Common Lisp and is still being sold and supported by Franz Inc. Since it's origins predate Common Lisp, Franz Lisp is not a Common Lisp (in particular, the interpreter is dynamically scoped which conflicts with Common Lisp semantics). However, Franz Lisp is a fairly small Lisp and takes up much less runtime memory than the Common Lisp products. Furthermore, many Common Lisp features and extensions have been added to Franz Lisp. Franz Lisp is *not* the Lisp product being put on the Macintosh in this joint Franz Inc/Coral effort. Allegro CL, the lisp product that *is* being put out by Franz Inc. and Coral Inc., is a complete Common Lisp with extensions. Allegro CL is available now under the mac OS and will also be available under the Unix OS. One more thing that may be confusing is that Franz Inc. has recently renamed its Common Lisp product on other machines from "Extended Common Lisp" to "Allegro CL". Now that we're straight on all that, the rest of this note will be about the questions regarding Franz Lisp... >>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. There are two debuggers available with Franz Lisp, (debug) which is contributed software, and, beginning with Opus 40, the default debugger which is in the top level. If you have a specific example where the debugger fails, it may be useful to move this discussion to comp.lang.lisp.franz. >>2. Similar problems with step.l, which doesn't do what the manual claims >> it should, unless inserted in a fn def. Beginning with Opus 43.1, there is a new and improved stepper which is part of the top level. It seems to fix most of the problems of the previous steppers, plus adds some new features. Charley Cox cox@renoir.Berkely.EDU
bc@apple.UUCP (bill coderre) (08/21/87)
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 Windowsjww@sdcsvax.UCSD.EDU (Joel West) (08/21/87)
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...
geb@cadre.dsl.PITTSBURGH.EDU (Gordon E. Banks) (08/23/87)
In article <3700@sdcsvax.UCSD.EDU> jww@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.
sterritt@ge-mc3i.UUCP (Chris Sterritt) (08/26/87)
>In article <792@cadre.dsl.PITTSBURGH.EDU> geb@cadre.dsl.pittsburgh.edu.UUCP (Gordon E. Banks) writes: >>In article <3700@sdcsvax.UCSD.EDU> jww@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
nessus@gaffa.mit.edu (Doug Alan) (08/26/87)
In article <3700@sdcsvax.UCSD.EDU> jww@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
jww@sdcsvax.UCSD.EDU (Joel West) (08/26/87)
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 jww@sdcsvax.ucsd.edu
or ihnp4!crash!palomar!joel joel@palomar.cts.comdbt@faccs.UUCP (08/26/87)
In article <792@cadre.dsl.PITTSBURGH.EDU>, geb@cadre.dsl.PITTSBURGH.EDU (Gordon E. Banks) writes: > In article <3700@sdcsvax.UCSD.EDU> jww@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 (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!"
bc@apple.UUCP (bill coderre) (08/27/87)
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
eliot@mind.UUCP (08/28/87)
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 -
bc@apple.UUCP (bill coderre) (08/28/87)
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
jlc@goanna.oz (J.L Cybulski) (08/31/87)
I think your question is directed to the wrong newsgroup, but here you have the answer: 1. Franz debugger or stepper should be loaded before you run your (crashing) program. Then (and only then) the two utilities will be able to properly interpret the break conditions. You may load them (fixit, stepper) automatically from ".lisprc". 2. See 1. Jacob o | o \_/
ags@j.cc.purdue.edu (Dave Seaman) (08/31/87)
In article <1189@mind.UUCP> eliot@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 ags@j.cc.purdue.edu