[Openmcl-devel] MOP support and porting UncommonSQL

[Gary Byers]

On Sun, 16 Mar 2003, Ram Krishnan wrote:

> Hello,
>
> Firstly, thanks to Gary and all the others who've been doing a
> fantastic job with OpenMCL.
>
> Has anyone on this list looked at porting UncommonSQL to OpenMCL?
>
> I started looking at layering UncommonSQL on top of CL-SQL but ran into
> problems with its use of `compute-effective-slot-definition'  which
> isn't available in OpenMCL (at least 0.13.4). Is there an alternate way
> to define new slot options in OpenMCL?

There isn't too much of a MOP in OpenMCL: there are some bits and pieces,
but there isn't any sort of extensible slot-definition protocol (or even
any distinct type of slot-definition object.)

The reasons for that are mostly historical: MCL's CLOS implementation had
to run reasonably well in what now seems like an extremely memory-constrained
environment, and trying to satisfy those constraints took precedence over
making the implementation extensible in MOP-like ways.  OpenMCL's CLOS
implementation is basically the same as MCL, but the constraints are
certainly different than they were 15 years or so ago.

In some cases, making the implementation "closed" didn't buy much
performance-wise: SLOT-VALUE and related functions do a linear search
of a table of slot names at runtime (over and over again, with no caching.)
This was intended to keep space overhead to a minimum: one double-indirection
scheme would have sped slot lookup substantially, but was rejected because
it would have caused the image to get 50K bytes larger.  It seems likely
that opening up the slot-definition and access protocol in a MOP-like way -
combined with a much more reasonable lookup strategy - could lead to a
significant performance increase (and the memory overhead wouldn't seem
too significant.)

In other cases, I think that the closed implementation strategy has
offered performance benefits and continues to do so: generic function
dispatch performance in MCL/OpenMCL is generally pretty good, and -
at least partly - is as good as it is because it feels free to ignore
issues of representation and protocl that the MOP raises. (It's certainly
possible that some other implementaion supports the MOP fully and offers
faster generic function dispatch, but that -shouldn't- be the case.)

Even if these remaining concerns are valid, there are tradeoffs: if
things got a little slower but more useful things could be done, that's
arguably a better situation than the status quo.

>
> And I've attached a simple patch below for a typo in
> ccl/lib/numbers.lisp in the `ccl' module CVS head.
>

Thanks (and sorry not to have noticed this earlier.)

> Regards,
>
> -ram
>
> ---
> Index: lib/numbers.lisp
> ===================================================================
> RCS file: /usr/local/publiccvs/ccl/lib/numbers.lisp,v
> retrieving revision 1.5
> diff -u -r1.5 numbers.lisp
> --- lib/numbers.lisp	11 Mar 2003 23:30:26 -0000	1.5
> +++ lib/numbers.lisp	17 Mar 2003 05:25:57 -0000
> @@ -645,7 +645,7 @@
>     (setq float-powers-of-5 (make-array 23))
>     (let ((array float-powers-of-5))
>       (dotimes (i 23)
> -      (setf (svref array i)  (float (expt 5 i) 0,0d0))))
> +      (setf (svref array i)  (float (expt 5 i) 0.0d0))))
>     (setq integer-powers-of-5 (make-array (+ 12 (floor 324 12))))
>     (let ((array integer-powers-of-5))
>       (dotimes (i 12)
>
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/cgi-bin/mailman/listinfo/openmcl-devel
>
>


_______________________________________________
Openmcl-devel mailing list
Openmcl-devel at clozure.com
http://clozure.com/cgi-bin/mailman/listinfo/openmcl-devel