GSOC | Extending Common Lisp support

[Per Bothner]

On 05/31/2012 02:09 PM, Jamison Hope wrote:
> On May 31, 2012, at 12:19 PM, Charles Turner wrote:
>
>> Having perused the LOOP implementation of SBCL, I believe the
>> following CL features are required to implement it:
>>
>> * packages - maybe not, but it will probably get tricky in terms of
>> collisions if this isn't available
>
> Per, you've said that the guts of this are in there with namespaces.
> Could you give us some pointers about how you intended for CL packages
> to be layered on top of them?

There are two different aspects:
(1) The actual API (functions and macros) for working with symbols and
packages, as discussed in the respective HyperSpec chapters (10 and 11).
The intention is that a CommonLisp package object would be
implemented using the gnu.kawa.lispexpr.LispPackage class.  A lot of
the API is implemented at the Java level; just a matter of writing
functions that call the appropriate Java methods.

Of course implementing every function and rule of the spec isn't
essential - though it's nice to be able to "check it off" as done.

(2) Hooking of the reader (and printer).  This includes tweaks
to LispReader#readAndHandleToken.  There is a hook for "packageMarker",
which is where the colon is, but (alas) packageMarker isn't passed to the
ReadTable#makeSymbol function.  (makeSymbol needs to know if a colon
is an unesaped package marker, or an escaped symbol constituent.)  So
one option is to extend ReadTable#makeSymbol; other is to tweak
readAndHandleToken.

There are two sub-issues with creating a symbol from a stream:
(a) Use the current package as appropriate;
(b) handle package prefixes.

Neither is very complicated; one just needs to decide the
cleanest (and preferably most efficient) way to do them.


>> * FUNCALL
>
> We already have #'apply in primitives.lisp, so I *think* this should work:
> (defmacro funcall (fn &rest args) `(apply ,fn ,@args ()))

Note that funcall is a function, not a macro.  It should be easy enough to
implement as a short Java method or a CommonList function that
invokes Procedure#applyN.

> Perhaps the first version should be written in Java and then moved
> to Lisp after those missing pieces get filled in?
>
> Per, how long did it take you to write the hooks for Scheme's let?

Scheme's let is quite complicated, only you include named let, and
optional type specifiers.

> For instance, in the past I've written this Scheme version of flet:
>
> (define-syntax flet
> (syntax-rules ()
> ((_ ((fname parameters body ...) ...)
> e ...)
> (let ((fname (lambda parameters body ...)) ...)
> e ...))))

Maybe instead :
(define-syntax flet
   (syntax-rules ()
     ((_ ((fname parameters body ...) ...)
         e ...)
      (%flet ((fname (lambda parameters body ...)) ...)
        e ...))))

where %flet is implemented using kawa.standard.let,
except you need to do:
   decl.setProcedureDecl(true);

(See how defun.java does.)

I'd probably create an flet.java that extends
kawa.standard.let, but somehow does setProcedureDecl.
Perhaps let.java can call a protected method does nothing
in let.java, but does setProcedureDecl in flet.java.
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/