Bug: incorrect stack trace for function names containing ->

[Alex Nixon]

Hey all,

I believe I've come across a minor bug in Clojure 1.4.0 (and I see the same behaviour in 1.5.0-alpha5):

user=> (defn a->b [])

#'user/a->b

user=> (a->b 1)

ArityException Wrong number of args (1) passed to: user$a  clojure.lang.AFn.throwArity (AFn.java:437)

Note that the reported function name in the stack trace is "user$a", where it should be "user$a->b" (or some mangled variant thereof?)

Cheers,

--

Alex Nixon

Software Engineer | SwiftKey

al...@swiftkey.net | http://www.swiftkey.net/

++++++
WINNER - MOST INNOVATIVE MOBILE APP - GSMA GLOBAL MOBILE AWARDS 2012

Head office: 91-95 Southwark Bridge Road, London, SE1 0AX TouchType is a limited company registered in England and Wales, number 06671487. Registered office: 21 Lawn Terrace, Blackheath, London, SE3 9LL, United Kingdom.

[Jay Fields]

I noticed something similar, but I'm using 1.3. Maybe it's a bug in nrepl?

> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clo...@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+u...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en

[Chas Emerick]

The message is produced in AFn.throwArity:

https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/AFn.java#L434

It looks like any name that contains a hyphen followed by a "special character" (w.r.t. allowable chars in Java classnames) will result in a munged (i.e. Compiler.munge()'ed) name containing a double-underscore sequence that is assumed by throwArity to be a system-generated suffix.

This is perhaps another case where pushing var metadata (or some subset thereof) down to the function being defined in defns would be beneficial; AFunction could then override throwArity to just use the :name of the function being called, thus avoiding any confusion introduced by munged or un-munging names.

None of the above is related to nREPL.

- Chas

[Jay Fields]

Fair enough. I never noticed it before, and I know I've seen ->
converted to something similar to __GT_ in the debugger, so I
(mistakenly) thought it had something to do with the repl.

Looks like this has been around for awhile, or I'm doing something wrong.

jfields@wud-jfields01:~$ lein repl
REPL started; server listening on localhost port 44397

user=> (defn a->b [])
#'user/a->b
user=> (a->b 1)

java.lang.IllegalArgumentException: Wrong number of args (1) passed
to: user$a (NO_SOURCE_FILE:0)
user=> *clojure-version*
{:major 1, :minor 2, :incremental 1, :qualifier ""}

jfields@wud-jfields01:~$ lein --version
Leiningen 1.7.1 on Java 1.6.0_33 Java HotSpot(TM) 64-Bit Server VM

jfields@wud-jfields01:~$ lein2 repl
nREPL server started on port 49847
REPL-y 0.1.0-beta10
Clojure 1.4.0
Exit: Control+D or (exit) or (quit)
Commands: (user/help)
Docs: (doc function-name-here)
(find-doc "part-of-name-here")
Source: (source function-name-here)
(user/sourcery function-name-here)
Javadoc: (javadoc java-object-or-class-here)
Examples from clojuredocs.org: [clojuredocs or cdoc]
(user/clojuredocs name-here)
(user/clojuredocs "ns-here" "name-here")

user=> (defn a->b [])
#'user/a->b
user=> (a->b 1)
ArityException Wrong number of args (1) passed to: user$a
clojure.lang.AFn.throwArity (AFn.java:437)

user=> *clojure-version*
{:major 1, :minor 4, :incremental 0, :qualifier nil}
user=> Bye for now!

jfields@wud-jfields01:~$ lein2 --version
Leiningen 2.0.0-preview10 on Java 1.6.0_33 Java HotSpot(TM) 64-Bit Server VM

jfields@wud-jfields01:~/src/zubron$ lein2 repl
nREPL server started on port 42865
REPL-y 0.1.0-beta10
Clojure 1.3.0
Exit: Control+D or (exit) or (quit)
Commands: (user/help)
Docs: (doc function-name-here)
(find-doc "part-of-name-here")
Source: (source function-name-here)
(user/sourcery function-name-here)
Javadoc: (javadoc java-object-or-class-here)
Examples from clojuredocs.org: [clojuredocs or cdoc]
(user/clojuredocs name-here)
(user/clojuredocs "ns-here" "name-here")
user=> *clojure-version*
{:major 1, :minor 3, :incremental 0, :qualifier nil}

user=> (defn a->b [])
#'user/a->b
user=> (a->b 1)
ArityException Wrong number of args (1) passed to: user$a
clojure.lang.AFn.throwArity (AFn.java:437)

user=> *clojure-version*
{:major 1, :minor 3, :incremental 0, :qualifier nil}
user=> Bye for now!

Cheers, Jay

[Chas Emerick]

The classname backing the function in question is still named e.g. user$a__GT_b. You'll always see that in debuggers and other tools that use classnames. The arity mismatch exception message is the issue.

You have to go back to Clojure 1.1.0 to see user$a__GT_b in such messages instead of user$a.

- Chas

[Alex Nixon]

I've created a Jira issue CLJ-1083 and linked this conversation.  I don't think there's anything else I can add to the discussion so I'll leave it to the clojure team to take from here.

Thanks for the responses,

[Mauricio Aldazosa]

Hi there.

According to the reader documentation (http://clojure.org/reader), it seems that '>' is not a valid character for a symbol name:

Symbols begin with a non-numeric character and can contain alphanumeric characters and *, +, !, -, _, and ? (other characters will be allowed eventually, but not all macro characters have been determined)

[Andy Fingerhut]

Clojure itself creates symbols with -> in them (I think defrecord creates functions named by such symbols).

Andy

[Tassilo Horn]

Well, record and type constructors are named ->MyRecOrType, and records
generate conversion fns map->MyRec, so that statement seems outdated to
me.

Bye,
Tassilo