This is the mail archive of the
kawa@sourceware.org
mailing list for the Kawa project.
Re: GSOC | Extending Common Lisp support
* Charles Turner [2012-06-20 15:44] writes:
> Thanks for the information. I intended to do DEFPACKAGE today, but
> instead I've been stuck on a bug.
>
> I get a VerifyError when I try to use the DO form in CL. The same
> behaviour can be observed from the kawa-1.12 release jar.
>
> #|kawa:1|# (do ((temp-one 1 (+ 1 temp-one))
> (temp-two 0 (- temp-two 1)))
> ((> (- temp-one temp-two) 5) temp-one))
> /dev/stdin:1:1: warning - no declaration seen for %do-lambda1
> [ ... bunch of undefined variable errors ...]
> exception while initializing module atInteractiveLevel$1
> at gnu.expr.ModuleContext.findInstance(ModuleContext.java:84)
> at gnu.expr.ModuleExp.evalModule2(ModuleExp.java:289)
> at gnu.expr.ModuleExp.evalModule(ModuleExp.java:200)
> at kawa.Shell.run(Shell.java:279)
> at kawa.Shell.run(Shell.java:194)
> at kawa.Shell.run(Shell.java:175)
> at kawa.repl.main(repl.java:891)
> Caused by: java.lang.VerifyError: (class: atInteractiveLevel$1,
> method: run signature: (Lgnu/mapping/CallContext;)V) Accessing value
> from uninitialized register 3
> at java.lang.Class.getDeclaredFields0(Native Method)
> at java.lang.Class.privateGetDeclaredFields(Class.java:2308)
> at java.lang.Class.getDeclaredField(Class.java:1897)
> at gnu.expr.ModuleContext.findInstance(ModuleContext.java:74)
> ... 6 more
>
> The "no declaration seen for %do-lambda1" is perplexing, as it's
> definitely being loaded in the CL startup. It's interesting to note
> that evaluating "do" in Scheme causes the std_syntax.scm file to be
> evaluated once, but subsequent evals of "do" do not cause this. This
> behaviour is not seen when evaluating "#'do" in CL. Not sure if this
> is a useful data point or not.
>
> Another difference is that defSntxStFld("do", "kawa.lib.std_syntax");
> is in Scheme, but not CommonLisp, adding it made no difference to my
> error.
Sounds like a namespace issue: the Scheme macro binds %do-lambda1 in
variable namespace but CL looks it up in the function namespace and
doesn't find it. I guess that means that DO is broken and you must
iterate via tail-recursion. With MAKE-SYMBOL and LABELS it should also
be possible to write simple/partial versions of DOLIST or DO as macros,
no?
> The second problem I had to today is type declarations of &rest
> arguments. The following works as expect in Scheme
>
> (define apply (f #!rest (args :: Object[])) ...)
>
> but this fails (because rest args gets the type PairWithPosition too
> early I think, and so later cannot be cast to an Object[] later)
>
> (defun apply (f &rest args)
> (declare (Object[] args) ...)
>
> Any ideas how to approach fixing this (or what the real problem is?).
The rest argument is always a list in standard CL. So I would not
expect that that declaration works. (Object[] is also not a standard CL
type specifier; in standard CL one would write SIMPLE-VECTOR.)
> Sorry for the lack of progress!
Well, it's pretty hard to write anything in a language that hasn't even
an iteration construct :-)
Helmut