Thanks for considering those Chouser,
> It might be nice to get a "useless bare symbol" warning in
> cases like this.
That sounds useful to me!
Another special case similar to 'bare symbol' which would be nice to
have reported is when a lazy sequence is created and thrown away.
Usually this means it was intended for side-effects which will never
occur. Unfortunately I have no idea how to detect such a thing seeing
it would look like a list. I suppose an explicit check could be made
for map which is the common one.
(map println [1 2 3 4])
is usually an error. The tricky thing is that from the REPL its not
such an error in that it gets forced, so might need to be treated
differently (I'd argue even then it should be an error - but don't
have much to base that on).
> Would you recommend a more general and therefore more
> accurate message? Something like "your if-let syntax is
> incorrect"?
My expectation was that (if-let binding a b c) would complain about
the extraneous c specifically, and only about the binding if it was
not a vector. But I see now as you described there is an & oldform to
catch the old style. For this kind of situation the signature can
greatly clarify:
"Too many args passed to if-let: (if-let ([bindings then] [bindings
then else]))"
;; assuming & oldform gets fully deprecated at some point
Leaving aside if-let with its oldform perhaps this would be useful in
other scenarios:
user=> (mod 1 2 3)
java.lang.IllegalArgumentException: Wrong number of args passed to:
core$mod (NO_SOURCE_FILE:0)
"Too many args passed to mod: (mod ([num div]))"
> I suppose the compiler
> could look for a no-arg method by that name and suggest that
> specific cause in the message.
This is a special case where the compiler could hint to me, "oh that's
a method call, not a field". The symbol is resolvable and has a
meaning, the fact that it is a method and can't be passed like so is
the real problem from my (stupid user) perspective. From the compiler
perspective not found makes perfect sense because it is specifically
looking for a field. If I see "that's a method not a field", or "can't
pass method" I will realise, oh I forgot to call it! But when I see
"not found" I start looking in all the wrong places.
> I agree that it'd be helpful to list the arg types passed in:
> "No 'abs' method found for [clojure.lang.Ratio]"
Yes, that would make it nice and obvious.
Candidate method hints would also be nice (again, showing the
signatures but this time java signatures which involve types). Ethan
Herdrick gave some good examples where showing candidate signatures
really helps. In this case there are:
static double abs(double a)
static float abs(float a)
static int abs(int a)
static long abs(long a)
Just another one that can be a bit hard to decipher:
user=> (1 2 3)
java.lang.ClassCastException: java.lang.Integer cannot be cast to
clojure.lang.IFn (NO_SOURCE_FILE:0)
;; obviously very correct, but might be easier to understand as
"(1 2 3) is a function call, but 1 is not a function"
However (1 2 3) might be a really long string so this might not be
practical.
Maybe "<symbol> is not a function." and optionally suggest "Perhaps
you meant to specify a list? '()"
This does seem to turn up a bit hence I think it warrants special
handling.
Regards,
Tim.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
