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: CL implementation questions


Thanks Jamison & Per for the comments.

On 28 March 2012 07:47, Per Bothner <per@bothner.com> wrote:
> There may be other problems implementing Common Lisp primitives using
> Common Lisp, but declare a good thing to tackle first.

Some questions whilst thinking about how to start:

- Environments, to which parts of a variables extent the DECLARE form affects.

Not sure where such information would go, possibly NamedLocation? I
originally thought Symbol might be a good idea, but it seems like
going against the design decision of Kawa.

- Its special semantics, i.e. it appears computationally invisible,
only making a difference in certain forms.

I would modify the reader to check for declarations at the start of
each body. Seems a bit excessive, but I don't know how else to achieve
this. If any declarations are found, maybe just stuff them in
Procedure (or whatever does represent this.) Then just lookup the
appropriate information in the appropriate extents of the variable (no
idea how to approach the last part).

- Macro forms cannot expand into DECLARE exprs.

This seems easy, just check that the transformed code doesn't contain
a DECLARE form, but I've limited knowledge of even using macros, never
mind their implementation.

- Code generation

I suppose there's existing examples of similar generation. I imagine
it would just about to emitting the byte code equivalent of if (var
instanceof type) .. when assigning values to variables and such like.

I only considered type declarations for now, not any of the other ones.

BTW - I plan on applying to Kawa for GSoC again this year, for the
extension of CL support project. Is it OK to use the information in
the back-and-forth we're having in my proposal, or is that considered
"dirty pool".

>> I plan on adding a new Kawa type for Java arrays to avoid the
>> getClass().isArray() dance when implementing sequences.
>
> Not sure what you mean. ÂThere is a Kawa type for Java arrays:
> For example java.lang.String[] .

I meant exactly what you described below about java-array.

> It would be reasonable to add a Kawa type-specifier for a generic
> Java array. ÂPerhaps java-array:
>
>
> (define-procedure length
> Âmethod: (lambda (proseq ::java.util.List) ::int (proseq:size))
> Âmethod: (lambda (proseq ::java.lang.CharSequence) ::int (proseq:length))
> Âmethod: (lambda (proseq :: java-array) ::int
> Â Â Â Â Â Â Â (java.lang.reflect.Array:get-length proseq)))

Thanks,
Charles.


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