Re: CL implementation questions

[Jamison Hope <jrh at theptrgroup dot com>]

Hi Charles,

On Mar 27, 2012, at 7:33 PM, Charles Turner wrote:

> I don't understand how the CL namespace gets setup. I see in
> CommonLisp that several Scheme libraries are pulled in
> (prim_syntax.scm & friends) as well as a start on CL (PrimOps.scm) but
> none of these symbols appear to be available in the global namespace.
> For instance, (defun foo (x) (+ x 1)) works fine, but typing "defun"
> yields a unbound location error. Why is that?

That'll happen in a complete CL implementation, too. One of the
differences between Scheme and Common Lisp is that the latter has
separate namespaces for functions and values; if you want to
find the function (or macro/special form/whatever) called "defun",
then you have to type "#'defun" or equivalently "(function defun)".

$ kawa --lisp
#|kawa:1|# #'defun
#<syntax defun>
#|kawa:2|# (function defun)
#<syntax defun>
#|kawa:3|# defun
<unknown>: warning - no declaration seen for defun
...

It's a "Lisp 1" vs "Lisp 2" thing (which is why
gnu.commonlisp.lang.CommonLisp extends gnu.commonlisp.lang.Lisp2).
See http://www.nhplace.com/kent/Papers/Technical-Issues.html


> It's mentioned in PrimOps.scm that it should be written in CL, but for
> that's not possible yet due to a lack of CL support. Is the correct
> approach to build some primitive transformers for CL (as in
> prim_syntax.scm) and then rewrite the stuff in PrimOps.scm with them?
> I don't understand why the %define-syntax & define-syntax methods are
> required, I assume for bootstrapping purposes, but I've yet to see the
> forest for the trees (sadly the Makefiles have failed to evince the
> process for me).

I defer to Per on this. I haven't grokked all of that, either.

> I plan on adding a new Kawa type for Java arrays to avoid the
> getClass().isArray() dance when implementing sequences. I can't find
> the mail, but I remember Jamison talking about this. Once the new type
> is added to LangObjType, where in the package hierachy would the
> implementation go? gnu.lists?

Uh oh, using Past Me against me! I don't think that that particular  
message
went to the Kawa list, so I'll repeat my complaint here. The context was
that I was telling Charles about how I was toying with an implementation
of CL's #'length, which is supposed to work on any "sequence". It  
seems to
me that the natural idea of a sequence for Kawa would be the union of
java.util.List, java.lang.CharSequence, and Java arrays.

I was complaining that they (the Java designers back in the day) didn't
put an abstract "array" superclass in between java.lang.Object and
all the array types (e.g. int[] or com.example.Foo[]). So to test if an
object is an array, we can't use the instanceof operator or built in  
method
dispatching but rather have to call getClass().isArray(). See the method
signatures in java.lang.reflect.Array.

Notice the breakdown in symmetry and elegance:

(define-procedure length
 method: (lambda (proseq ::java.util.List) ::int (proseq:size))
 method: (lambda (proseq ::java.lang.CharSequence) ::int  
(proseq:length))
 method: (lambda (proseq) ::int
           (if (*:array? (*:get-class proseq))
               (java.lang.reflect.Array:get-length proseq)
               (error length "Cannot get length:" proseq))))

All arrays of Object types can be cast to Object[], so there's that,
but you still have to use raw Object if you want to handle both object
arrays and primitive arrays. Hence java.util.Arrays and its 9 versions
of each method, one for Object[] and each of the 8 primitive types.

-Jamie

--
Jamison Hope
The PTR Group
www.theptrgroup.com