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: GSOC | Extending Common Lisp support


* Jamison Hope [2012-06-08 16:02] writes:

> 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?

MAKE could be a function, e.g. it could call MAKE-INSTANCE and
MAKE-INSTANCE could have a method for the string case.

> 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.

At least the CL package must have exactly those symbols, otherwise it's
not a standard conforming implementation.

> 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.

Making java.util.Date a function would require some special rule like
"if the symbol is not fboundp, ask the classloader for a class with that
name, or if the symbols happens to end in with a ? or a -p or p then
also ask the classloader with last char stripped".  I'm pretty sure that
I don't want any other than the standard name resolution rules.

Also, I'm pretty sure that such a rule will break down when
DO-ALL-SYMBOLS is used to find all defined functions.

> 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

Maybe.  But I would be surprised if much of the existing CL code in the
wild could be compiled with :inverted readtable case.

Helmut


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