This is the mail archive of the
kawa@sourceware.org
mailing list for the Kawa project.
Re: GSOC | Extending Common Lisp support
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/