This is the mail archive of the
kawa@sourceware.org
mailing list for the Kawa project.
Re: GSOC | Extending Common Lisp support
On Jun 21, 2012, at 1:35 PM, Charles Turner wrote, in a different order:
Another thing I just quickly did. I mentioned earlier that APPLY was
broken in CL because Apply#getArguments wanted an Object[] parameter,
but the rest list was a LList, and we couldn't set the type early
enough in the parameter list because :: has another interpretation in
CL. Helmut pointed out that it didn't make sense in CL for this type
to be specified, so what I've got now is:
(defun apply (f &rest args)
(declare (gnu.lists.LList args))
...)
and then I added the following method in Apply:
public static Object[] getArguments (LList args, int skip, Procedure
proc)
{
return getArguments(args.toArray(), skip, proc);
}
Hope that's reasonable!
Seems OK to me. But isn't the
else if (mode == restKeyword)
decl.setType(LangObjType.listType);
at Lambda.java:271 supposed to automatically set args to be of type
LList
if no type is specified? Your DECLARE there should be harmless but
unneeded.
On 21 June 2012 17:35, Jamison Hope <jrh@theptrgroup.com> wrote:
Maybe instead have CommonLisp override #'eqv? with its own instance
of
IsEqv? That way scheme-case can still call Scheme.isEqv and get #f,
and lisp-case
(defun lisp-case ()
(case 'b ((a) 'yes) (else 'no)))
can call CommonLisp.isEqv and get NIL.
Thanks Jamison! That worked flawlessly. I went ahead and added
override for eq? and equal? in CommonLisp too.
OK, glad it worked. It's kind of unfortunate that we need language-
appropriate
versions for any predicate function used by a macro. For now, let's
stick with
that and move on, but perhaps it's something to revisit in the long run.
I've been thinking about it a bit today, though, and since I'll forget
if I
don't write it down now...
tl;dr: Making languages play nice with each other is complicated.
The solution that we have now means that macros expand and compile
differently
depending upon the Language in use at the point of expansion. We need
the
different IsEqv instances because ConditionalTarget#compileFromStack
does
comp.compileConstant(language == null ? Boolean.FALSE
: language.booleanObject(false));
hard-coding booleanObject(false) from the Language, and so we need the
predicate procedure to match.
That's OK, but it means that if we want to write a cross-platform
macro -- in
the sense that it can be used from Scheme or CL -- then we have to be
careful
about which functions we use in that macro.
One solution could be to always use Language.getDefault().booleanValue()
when returning a boolean object, and always use
Language.getDefault().isTrue()
to test those returned objects. So, change ConditionalTarget so it
doesn't
inline the test using the compile-time language. Then we could have a
single
IsEqv and "(if (eqv? x y) ...)" would always compile to the
equivalent of
if (Language.getDefault().isTrue(isEqv.apply2(x,y))) { ... }
instead of the current
if (isEqv.apply2(x,y) != language.booleanObject(false)) { ... }
The other idea that's been floating around in my head today is this:
leave ConditionalTarget and IsEqv as they are now, and instead
(optionally?)
treat "language" as part of a macro definition's lexical scope -- when
defining
a macro take note of the current language, and then in Macro#expand
put it all
in a try-finally block that calls Language#setSaveCurrent and
Language#restoreCurrent.
An intriguing possibility would then be to define a macro like this in a
Scheme file:
(define-syntax begin-scheme
save-language: #t
(syntax-rules ()
((begin-scheme e ...) (begin e ...))))
et voilà, you can embed Scheme code inside of CL:
(defun f ()
(begin-scheme
;; this is compiled as Scheme, so returns 'true
(if () 'true 'false)))
Just something to ponder later.
-Jamie
--
Jamison Hope
The PTR Group
www.theptrgroup.com