This is the mail archive of the
kawa@sourceware.org
mailing list for the Kawa project.
Re: GSOC | Extending Common Lisp support
On Jun 8, 2012, at 8:30 AM, Helmut Eller wrote:
I think this SHOULD NOT work. java.util.Date is clearly not a CL
function and isn't this supposed to be a CL implementation?
Despite that, the standard CL reader upcases all symbols. If this
gets
fixed the compiler would see |JAVA.UTIL.DATE|. So using symbols to
denote Java classes will cause problems later when we get a real
reader.
I'd use (make "java.util.Date" ...).
Well, MAKE isn't a standard CL function either, is it? Or INVOKE-STATIC?
I think it's pretty clear that we're going to have to have a superset of
the 978 standard symbols; the question is one of degree. I have no issue
with (make "java.util.Date" ...), but I don't see anything intrinsically
wrong with (java.util.Date ...) either, OTHER THAN the case folding
issue.
But re that, the standard CL reader only upcases all symbols *by
default*;
this can be avoided by escaping with vertical bars, or by using
READTABLE-CASE:
http://www.cliki.net/Case%20sensitivity
I would have no problem with Kawa working like this [simulated REPL
interaction]:
$ java kawa.repl --lisp
#|kawa:1|# (make "java.util.Date")
Fri Jun 08 11:49:36 EDT 2012
#|kawa:2|# (|java.util.Date|)
Fri Jun 08 11:50:27 EDT 2012
#|kawa:3|# (setf (readtable-case *readtable*) :invert)
:invert
#|kawa:4|# (cons 'Hello nil)
(Hello)
#|kawa:5|# (java.util.Date)
Fri Jun 08 11:52:12 EDT 2012
However, all of that can be an eventual enhancement, just like it was
for Scheme. For now, sticking to MAKE is good enough.
--
Jamison Hope
The PTR Group
www.theptrgroup.com