Dotted method invocations (and other reader niceties) do not work in #= forms

[Chas Emerick]

This works fine:

user/ (read-string "#=(java.lang.Float. \"5\")")
5.0

However, these two cases fail:

user/ (read-string "#=(.toCharArray \"foo\")")
java.lang.Exception: Can't resolve .toCharArray

user/ (read-string "#=(java.lang.Enum/valueOf java.lang.Thread$State
\"NEW\")")
java.lang.ClassCastException

In the first case, it looks like the dotted method invocation isn't
being expanded into the (. obj (methodname)) form, so a var named
'.toCharArray' is being searched for.

In the second case, I'm guessing that the classname provided as the
first argument is being interpreted as a symbol and not a Class. Just
for comparison's sake:

user/ (eval '(java.lang.Enum/valueOf java.lang.Thread$State "NEW"))
#<State NEW>

(Also puzzling to me is the fact that the ClassCastException is being
emitted by clojure's reflection apparatus; this is confusing to me, as
Enum/valueOf has no overloads, and in any case, the types of the
arguments is known -- Class and String, or in the case where the
reader isn't swapping out the symbol for the Thread$State class, a
Symbol and String. That's for another day, though.)

I'm not entirely clear on all of the implications of #=, but it seems
like a good deal of the reader functionality isn't available within #=
forms.

Is this known and/or expected behaviour?

Thanks,

- Chas

[Chas Emerick]

Replying to my own (old) post -- the reason why all reader
capabilities aren't available in #= forms is that the reader isn't
currently being recursively applied to the body of those forms. Only
certain aspects of the full reader's functionality (like dotted
constructor invocations) are being recruited there at the moment.
After tinkering, it looks like that's "just" an implementation limit
right now, probably due to the mandate and details of #= forms and
printable reading not being entirely fleshed out yet.

- Chas