Porting between MCL and ACL

["Rodney Daughtrey" <proact!rodney@uunet.UU.NET>]

Subject:  Porting between MCL and ACL/PC
In response to recent requests for information about porting & differences
between MCL and Franz' ACL/PC, here's some mail that co-worker Don Mitchell sent
out to the MCL list a while back that may be of interest...

In porting a large program we've written from MCL to ACL/PC, the biggest problem
by far (as one would expect) was the UI.  We chose to write a portable UI
substrate ourselves (nothing near as ambitious as CLIM) that's centered around
portable, subclassed versions of the standard dialog items provided by each
platform, and then wrote all of our code using the substrate.  Probably the most
important recommendation I could make w/ respect to minimizing porting headaches
between these two lisps would be to minimize use of non-standard-dialog-item MCL
views -- originally, we tried to make a portable substrate for MCL-like views --
but largely abandoned the effort mainly due to performance problems on ACL/PC. 
The ACL/PC view model is significantly different, and is nowhere near as clean,
well-thought-out, or as fast as the MCL model.

-- Rodney

--------------------------------------
Date: 4/20/1994 7:07 AM
From: Don Mitchell
>From cambridge.apple.com!owner-info-mcl  Wed Apr 20 06:07:37 1994 remote from
uunet
Received: from brazil.cambridge.apple.com by relay2.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AAwmku05108; Wed, 20 Apr 94 06:07:37 -0400
Received: from ministry.cambridge.apple.com by brazil.cambridge.apple.com with
SMTP (5.64/25-eef)
	id AA03590; Wed, 20 Apr 94 06:04:04 -0400
	for dhm%proact@uunet.UU.NET
Received: by cambridge.apple.com (5.64/25-eef)
	id AA11687; Wed, 20 Apr 94 06:03:04 -0400
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP
(5.64/25-eef)
	id AA11683; Wed, 20 Apr 94 06:02:59 -0400
Received: from relay2.UU.NET by brazil.cambridge.apple.com with SMTP
(5.64/25-eef)
	id AA03572; Wed, 20 Apr 94 06:02:31 -0400
	for info-mcl@cambridge.apple.com
Received: from uucp5.uu.net by relay2.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AAwmku04564; Wed, 20 Apr 94 06:02:50 -0400
Message-Id: <9404201002.AAwmku04564@relay2.UU.NET>
Received: from proact.UUCP by uucp5.uu.net with UUCP/RMAIL
        ; Wed, 20 Apr 1994 06:02:50 -0400
Date: 19 Apr 1994 18:49:09 -0600
From: "Don Mitchell" <uunet!proact!dhm>
Subject: Re: MCL v. ACLPC
To: "Info-mcl" <cambridge.apple.com!info-mcl>, "stephen strom" <ACM.ORG!strom>

Subject:   RE>MCL v. ACLPC
Disclaimer: I'm under a non-disclosure with Franz wrt to some unannounced
features and products.  Plus, I am paying Franz to develop new aclpc add-ons
and to allow me to use those add-ons in my commercial software.

Franz purchased ACLPC from Procyon and, I believe, added the common-
graphics interface.  They've done no substantive work on the compiler.
The compiler is very rough.  ACLPC requires much more memory than MCL.

Due to porting difficulties and some platform differences in my code, I've 
not had an opportunity to judge execution speed differences.  

ACL provides a good high-level interface to native windows GUI widgets;
however, it's not comparable to views nor does it provide the type of control
that mcl provides with its access to traps.

ACL provides most of the CLOS MOP whereas mcl leaves a good bit out
(some intentionally for performance).

ACL's documentation is VERY poor.  Some of it is misleading.  A lot is 
difficult to find with two sections for each facility and some functions
only being documented in the introductory section.  Most of the documentation
is imprecise wrt argument types and return values.  Many of the functions
you need are not documented.  It's difficult to understand how and what
classes to specialize for interface functionality.

ACL's editor is limited to 32K characters although Windows no longer 
imposes that constraint on text-edit widgets.  ACL does not support
long filenames nor UNC naming (new discoveries in Windows).  The editor
is sluggish and awkward.

I don't believe the inspector allows you to change slot values or other
such information.  ACL does provide an inspect-object which is analogous
to describe-object and print-object.

ACL's debugger provides minimal support (inspecting objects in the
stack is about it, no restarts, no jump to function definitions).  There's
no geta-browser type class browser.  Disassembling a function provides
no useful debugging information (unlike mcl).

ACL is somewhat flakey with GPF or Dr.Watson drops occurring rather
frequently.

ACL does not let you create qualified methods before creating the primary.
This problem can be VERY vexing!

ACL is very touchy with forward referencing class names especially as types.
If you use :type slot options, then you must ensure that the given classes
are known prior to compiling the referencing classes.

ACL not only doesn't support but gets an error on dynamic-extent declarations.


ACLPC's bbs is a joke due to lack of participation by customers and
Franz.  ACLPC does not have a mailing list analog to info-mcl.

ACL's product support is generally very good (as is mcl's).

ACL is missing logical pathnames although I've converted Kantrowitz's.
It's also missing defsys although I've converted that too.

Unlike Apple, Franz is actively working on the product and not sitting on
its laurels.  It recognizes much of its weaknesses.

ACL provides backin-store on windows and seems to actively update widget
contents when their values change (no need to invalidate views).

---------------------
Donald H. Mitchell             Domain:  dhm@pro-solution.com
Proactive Solutions Inc.         UUCP:  uunet!proact!dhm   
5314 S. Yale Ave., Suite 402    Voice:  918.492.5192
Tulsa, OK  74135                  FAX:  918.492.5193


---------------------
Rodney Daughtrey               Domain: 
rodney@pro-solution.com
Proactive Solutions Inc.         UUCP:  uunet!proact!rodney  

5314 S. Yale Ave., Suite 402    Voice:  918.497.2332
Tulsa, OK  74135                  FAX:  918.497.2323