GSOC | Extending Common Lisp support

[Jamison Hope]

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