On Friday, May 1, 2015 at 3:54:08 PM UTC-4, Nicola Mometto wrote: > > > Fluid Dynamics writes: > > > That's weirdly inconsistent with e.g. (defn ^String prefix [s n]...). > > It can be surprising behaviour, but it's not an inconsistency. > As per the documentation, metadata on the symbol being def'd *is* > evaluated, metadata on the argvec isn't. > Evaluating `String` produces the java.lang.String Class -- a valid tag, > evaluating `longs` produces the clojure.core/longs function -- not a > valid tag. OTOH 'longs is a valid tag that the compiler understands. > > > It also doesn't negate the original bug report. That VerifyError means > that > > the Clojure compiler emitted invalid bytecode, instead of either > emitting > > valid bytecode or reporting a sensible error. Any way you slice it the > > compiler is buggy if it can quietly emit broken bytecode. > > The reported exception is not all of what happens. > If you try to execute that code you'll see that you get two exceptions, > the first one being "java.lang.IllegalArgumentException: Unable to > resolve classname: clojure.core$longs@3f91beef" which tells you exactly > what I told you before -- clojure.core/long is not a valid type hint. > > The VerifyError is thrown later and is caused by the fact that the > compiler emits partial bytecode as it gets interrupted by the > IllegalArgumentException. > > Now, if you want to argue that the compiler should immediately throw an > error as soon as the wrong type hint is used rather than silently ignore > it and fail when the type-hinted form is used, I'll agree with you and > I've proposed to make the compiler stricter a number of times on the > clojure-dev ML and talked about it on IRC but I guess either it's not a > priority for the clojure/core team or they're simply not interested in > more compile-time checks. > Either way the reported issue was a user error, not a compiler bug. >
Seems to me it's both. Certainly if the compiler were bug-free there would never be a VerifyError while running clojure, other than maybe when dynamically loading a buggy class that originated somewhere else. (e.g. (eval '(.some.pkg.BuggyClass 42 606)) with a broken some/pkg/BuggyClass.class in the classpath.) -- 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 Note that posts from new members are moderated - please be patient with your first post. 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 --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.