This is the mail archive of the kawa@sourceware.org mailing list for the Kawa project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GSOC | Extending Common Lisp support


* Charles Turner [2012-06-19 19:53] writes:

> Thanks again Helmut!
>
> My status so far is DECLARE processing of types is complete (although
> perhaps a little unrefined from an implementation point of view), many
> refactorings and minor fixes. As for packages, I have the following
> implemented which pass the tests I have enough infrastructure to run
> from the CLHS:
>
> find-package, make-package, find-symbol, keywordp, use-package,
> export, import, package-used-by-list, package-use-list and
> in-package. That still leaves quite a bit left, but of the following,
> what would you suggest working on for DEFMACRO? I'm guessing
> DEFPACKAGE is kinda important. I also need to reorganise the
> primitives.lisp code to export the core forms through packages&

Yes, DEFPACKAGE would be important.  I think DEFPACKAGE should be a
macro along the lines of
http://homepage1.nifty.com/bmonkey/lisp/sacla/html/lisp/package.lisp.html.
That definition of the DEFPACKAGE macro uses:

> ;shadow
> ;shadowing-import
> ;unintern
> ;rename-package

We would also need EVAL-WHEN.  Is that already working?  I guess
EVAL-WHEN is something the compiler knows about, otherwise IN-PACKAGE
would probably not work.  

Basically, I suggest that you take the code for DEFPACKAGE from Sacla
and try to get it to work in Kawa.  Our current version of DEFMACRO
should be up to that task.  Rewrite uses of LOOP, DOLIST with DO or
LABELS and see what is still missing.


Those two would be quite useful in practice:

> ;package-name
> ;unexport

The following are needed less frequently:

> ;do-all-symbols
> ;list-all-packages
> ;do-external-symbols
> ;do-symbols
> ;package-nicknames
> ;find-all-symbols
> ;package-shadowing-symbols
> ;unuse-package

Those have low priority and aren't actually related to packages:

> ;*modules*
> ;provide
> ;require

The spec for "modules" was never done very well and aren't used much.

> I've also extended the reader to support package prefixes CL
> style. The only changes to the code I sent the other day is Helmut's
> correction and a check to make sure we're in the CL language before
> processing the package lookup (+ some minor bug fixes). This has
> mean't that return types in primitives.lisp kicked the bucket&
>
> If you want to build up a list in Java to return to Lisp, what's the
> recommended way? It would be nice if LList implemented #add, but it
> doesn't,

Well, adding at the end would be inefficient.

> so I've resorted to the equivalent of CONS chaining a load of
> Pairs. Can't find examples of similar construction in the code base so
> far. This is for the package-uses-list support.

Seems fine to me as would building up a temporary ArrayList and call
makeList on it at the end.

Helmut


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]