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
smime.p7s
Description: S/MIME cryptographic signature
