[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
mcl2.1, mcl3.2, mcl4.1, ...
- To: firstname.lastname@example.org
- Subject: mcl2.1, mcl3.2, mcl4.1, ...
- From: email@example.com
- Date: Fri, 15 May 92 17:53:06 +0200
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
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
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,
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
hypertext links, etc. Why not extend the functionality for fred. Fred
could be the base for advanced text editors. Items in a fred buffer
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
across a network. A lisp _program_ should be started from but not within
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
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.
are macintosh developers using MacApp. They were really impressed. I showed
how to develop graphical interfaces with MCL using conditions, interface
restarting from the debugger, etc. They are not switching to MCL, because
reasons (time to learn common lisp and getting experience, ...), but they
mcl is an alternative for some of their development. For them it was
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
perfect software environment for universities.). Maybe apple should promote
version more aggressively. Ages ago I have read articles in Byte, MacWorld
MacWeek about MCL. Maybe they don't know that MCL is alive and doing well?
_MCL_is_a_great_product_. More people should know and use it.
Just some of my ideas.