Hello,
Thanks for taking time thinking about this idea!
Your solution is indeed close to what I had in mind in terms of
requirements. I was currently hacking with clojure java class Compiler to
enhance Timothy's patch and add a variation on what you described.
My concern is that it should also work with AOT compilation, so I'm not sure
if a solution just at the clojure clj code level would be sufficient then ?
Anyway, I'm facing difficulties with my understanding of the java code. Here
are a couple of questions, if you have the answers, you're welcome ! :-) :
* does the Compiler.load() process happen all in the same thread ? (And if
yes, is that a guaranteed feature, or could that change in the future ?)
* How do you correctly deref, ref-set! from java code by directly using a
Var instance ?
--
Laurent
2009/3/17 Stephen C. Gilardi <squee...@mac.com>
>
> On Mar 16, 2009, at 6:59 PM, Elena wrote:
>
> Furthermore, if I understand Rich's opinion in that regards, this
>> code:
>>
>> (defn myfun []
>> (another-fun 5))
>>
>> should be rejected if definition of "another-fun" is missing (but I'd
>> say: only in code to be released).
>>
>
> I don't mind the current behavior of requiring a var to be def'd before
> it's referenced. I do find the idea of relaxing that requirement
> interesting, though, so I thought about one possible way to accomplish it.
>
> To support auto-defining of unresolved symbols, either at the repl or in
> loaded files, Clojure could provide a var:
>
> *autodef-unresolved-symbols*
>
> When true, any symbol references that would have triggered the "unable to
> resolve symbol" exception would instead be auto-def'd as unbound and
> resolved. (Note that since they would be unbound, they still could not be
> dereferenced which is cool.)
>
> The repl could allow this to be set!-able.
>
> If *autodef-unresolved-symbols* is true, and if "a" has never been
> mentioned before, this interaction with Clojure:
>
> user=> a
> java.lang.Exception: Unable to resolve symbol: a in this context
>
> would become:
>
> user=> a
> java.lang.IllegalStateException: Var user/a is unbound.
>
> When a symbol is auto-def'd (presumably in ns-resolve, or in the Java code
> that supports it), the corresponding resolved symbol would be added to an
> internal ref (bound to a set):
>
> *autodefs*
>
> One could retrieve the names of any (currently/still) unbound autodef'd
> vars via a call:
>
> (unbound-autodefs)
>
> This call would first update the value bound to the ref *autodefs* by
> removing any of its entries that now have root bindings and return its value
> after the update. In this way, updating the set of unbound autodefs is lazy
> and not done until someone is interested.
>
> For the case of loading files, load could be wrapped with something like:
>
> (binding [*autodef-unresolved-symbols* true *autodefs* (ref #{})]
> (load...)
> (when-let unbound (seq (unbound-autodefs))
> (throw Exception. (str "The following vars were not defined: "
> unbound))))
>
> Under this system:
>
> - the behavior is optional at the repl. anybody not using it sees no
> change in behavior there
> - Clojure would relax its ordering requirements in source files
> while still ensuring that all forward references are satisfied by the end of
> each file.
> - any vars that are intended to be unbound would (still) have to be
> def'd explicitly.
>
> This system seems workable and desirable to me, but I gather that Common
> Lisp packages have some subtle and sometimes undesirable behaviors
> associated with a similar capability. I don't know whether other Clojure
> goodness would make any such issues unimportant in practice or if they would
> still be a problem.
>
> --Steve
>
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~----------~----~----~----~------~----~------~--~---
