mcl2.1, mcl3.2, mcl4.1, ...

[joswig@informatik.uni-hamburg.de]

Well,

where to start? I haven t yet seen MCL 2.0f and shall say something
about MCL 2.1 ... hmmmmm ....... thinking ......

Okay, let s go (Not everything is for MCL2.1 but maybe for MCL3.2, MCL 4.1
or ...):


1) I do like MCL 2.0. But some of the user interface components
lack sophistication. There is too much to do by hand.
There are mumerous examples for this:
 - Lack of keyboard controlled scrolling of table-dialog-items.
 - Poor grapher example.
 - Scrolling windows are not very functional (fixed size).
 - No automatic update facilities.
 - Size box in window -> no automatic adjustment of a view with a
   single vertical scrollbar.
 - No layout facilities for dialog-items.
 - ...
I want to have access to all aspects of user interface programming, but
there should be mighty library components ready to use.


2) User interface polishing. Some elements of the mcl user interface are
violating the guidelines (IMHO) from apple (pop-up menus for starting
actions, "Inspector Central" window, ...). This should be changed.


3) CLOS is ok. But a full MOP for CLOS would be _very_ welcome.


4) OOP-Streams are ok, but these may be to slow for some purposes (fast
file-io). So what I really like to have is a highly optimizing compiler,
especially for CLOS-constructs. The (speed-) penalty of using OOP should be
as little as possible.
What about type-inferencing, type-checking ... The CMU-CL compiler is an
interesting
example for this.


5) CLIM ... hmmm ... Actually I do like the Symbolics interface and Dynamic
Windows. But CLIM and the port to mcl hasn t impressed me yet. There are to
many bugs (updating, ...). And the integration in mcl isn t very good. The
examples were crippled, full of bugs and full of undocumented forms. Maybe
CLIM 2.0 will change all that. Although I do like the ideas of CLIM 2.0 (as
far as I know them), ILA has to come up with a useable implementation
(Maybe with some help from Apple). At the moment I wouldn t want to use
CLIM 1.0. :-(


6) There should be a defsystem tool. This one should be written in an
oop style. New types of subsystems should be subclasses of existing
subsystems. One should be able to write methods for the systems,
subsystems,
modules, etc. Maybe a graphical user interface for the system definition
and for starting methods on selected systems will simplify the use
of such a complex tool.


7) Stepper. Hiding of levels in the stepper window should be possible.
This could work as in the list views of the finder.
   

8) Interface designer. There is much to do. Until now it is only possible
to do the earliest design steps with the interface designer.


9) Persistence. This one is really important! One should have the choice of
which implementation type of persistence one would like to use: Objects in
resources (!), plain text files, databases (integrated or written in lisp),
external databases (sql), etc.


10) Improved fred : Multiple fonts, multiple styles, different line
spacing,
hypertext links, etc. Why not extend the functionality for fred. Fred
could be the base for advanced text editors. Items in a fred buffer
shouldn t
be only characters but many different type of objects (views).


11) Multiple processes from within lisp (futures).


12) Code walker.


13) Better facilities for printing code listings to paper.


14) Multiple communicating lisp images sharing objects on the same machine
or
across a network. A lisp _program_ should be started from but not within
one
lisp. Crashing one image should have no effect on other images or on the
image which is the development environment. The core of the lisp system
could be sharable in rom or as a system extension.


15) Maybe sometime we will have a Macintosh with a different processor or
we will use new operating systems from apple (Pink, PowerOS, ...). So the
compiler should be portable to different environments.


16) Talk to the hardware people to give the PowerBook 170 more than 8 MB
RAM.
Some MCL and PowerBook users would like to have more ram. These highend
powerbooks could be the ideal machines to bring MCL on the road.
("Why do you want to have more than 8 MB in your PowerBook?" "We are using
 Macintosh Common Lisp!. "What s that?" "Grrr...")


...


2001) MCL as the Operating System. ;-)


-------------------------------------------------------------------------
By the way, MCL shouldn t create fasls with file type "TEXT" and then
change it to type "FASL". This confuses a tool like PreVersion.
This tool creates versions of files of a specific type and creator
in selected folders. If one want s only to save versions of text files, you
will also get versions of fasls.
-------------------------------------------------------------------------


Some time ago I have given a demo of MCL2.0b1p3 for some friends of mine.
They
are macintosh developers using MacApp. They were really impressed. I showed
them
how to develop graphical interfaces with MCL using conditions, interface
designer,
restarting from the debugger, etc. They are not switching to MCL, because
of many
reasons (time to learn common lisp and getting experience, ...), but they
saw that
mcl is an alternative for some of their development. For them it was
important that
apple is continuing to support the programming language or development
system over a
long period of time (Well, now they will have to switch from Object Pascal
to C++ :-( ).
Not a lot of people do know MCL or have used it for development (IMHO it is
a
perfect software environment for universities.). Maybe apple should promote
the final
version more aggressively. Ages ago I have read articles in Byte, MacWorld
and
MacWeek about MCL. Maybe they don't know that MCL is alive and doing well? 

Rainer Joswig

_MCL_is_a_great_product_. More people should know and use it.

Just some of my ideas.