{"action":"created","issue":{"url":"https://api.github.com/repos/JuliaLang/julia/issues/15483","repository_url":"https://api.github.com/repos/JuliaLang/julia","labels_url":"https://api.github.com/repos/JuliaLang/julia/issues/15483/labels{/name}","comments_url":"https://api.github.com/repos/JuliaLang/julia/issues/15483/comments","events_url":"https://api.github.com/repos/JuliaLang/julia/issues/15483/events","html_url":"https://github.com/JuliaLang/julia/issues/15483","id":140534763,"number":15483,"title":"Infix operator definition syntax needs documentation","user":{"login":"tkelman","id":5934628,"avatar_url":"https://avatars.githubusercontent.com/u/5934628?v=3","gravatar_id":"","url":"https://api.github.com/users/tkelman","html_url":"https://github.com/tkelman","followers_url":"https://api.github.com/users/tkelman/followers","following_url":"https://api.github.com/users/tkelman/following{/other_user}","gists_url":"https://api.github.com/users/tkelman/gists{/gist_id}","starred_url":"https://api.github.com/users/tkelman/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/tkelman/subscriptions","organizations_url":"https://api.github.com/users/tkelman/orgs","repos_url":"https://api.github.com/users/tkelman/repos","events_url":"https://api.github.com/users/tkelman/events{/privacy}","received_events_url":"https://api.github.com/users/tkelman/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/JuliaLang/julia/labels/doc","name":"doc","color":"02d7e1"},{"url":"https://api.github.com/repos/JuliaLang/julia/labels/needs-docs","name":"needs-docs","color":"d4c5f9"},{"url":"https://api.github.com/repos/JuliaLang/julia/labels/needs-tests","name":"needs-tests","color":"5319e7"}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":11,"created_at":"2016-03-13T22:09:11Z","updated_at":"2016-08-02T03:13:46Z","closed_at":null,"body":"I had no idea we support the below syntax for defining infix operators. AFAICT it's not in the manual, and before https://github.com/JuliaLang/julia/commit/f07485f89461047531a2c9e10b51dc1301b9c699 I don't think it was in any tests either. Am I the only one who was unaware of this?\r\n```\r\njulia> import Base.+\r\njulia> immutable wrapper\r\n           val\r\n       end\r\njulia> a::wrapper + b::wrapper = wrapper(a.val + b.val)\r\n+ (generic function with 172 methods)\r\njulia> wrapper(1) + wrapper(2)\r\nwrapper(3)\r\n```"},"comment":{"url":"https://api.github.com/repos/JuliaLang/julia/issues/comments/236783322","html_url":"https://github.com/JuliaLang/julia/issues/15483#issuecomment-236783322","issue_url":"https://api.github.com/repos/JuliaLang/julia/issues/15483","id":236783322,"user":{"login":"vtjnash","id":330950,"avatar_url":"https://avatars.githubusercontent.com/u/330950?v=3","gravatar_id":"","url":"https://api.github.com/users/vtjnash","html_url":"https://github.com/vtjnash","followers_url":"https://api.github.com/users/vtjnash/followers","following_url":"https://api.github.com/users/vtjnash/following{/other_user}","gists_url":"https://api.github.com/users/vtjnash/gists{/gist_id}","starred_url":"https://api.github.com/users/vtjnash/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/vtjnash/subscriptions","organizations_url":"https://api.github.com/users/vtjnash/orgs","repos_url":"https://api.github.com/users/vtjnash/repos","events_url":"https://api.github.com/users/vtjnash/events{/privacy}","received_events_url":"https://api.github.com/users/vtjnash/received_events","type":"User","site_admin":false},"created_at":"2016-08-02T03:13:46Z","updated_at":"2016-08-02T03:13:46Z","body":"Is it OK to agree with both sides?\r\n\r\nComing from the perspective of the parser, I agree with Jeff that `a + b` is the same function call as `+(a, b)`. This simplifies syntax rules, since there's no need to make a distinction between the two parsed forms. Thus, fewer parser bugs, macro bugs, edge-cases, yada yada yada\r\n\r\nComing from the perspective of the user, I'm on the side of disallowing this on the LHS as unnecessary and too feature-y for something the user probably will never encounter \"in the wild\" other than in typos. Of course, simply encountering `+(a, b) = a-function-definition` is probably surprising to many users (coming from languages where even `+(a, b)` isn't a valid), but in counter-point, this form is common to see in Julia code, thereby making it idiomatic.\r\n\r\nFwiw, as Jeff said, it's fundamental that `a + b` and `+(a, b)` both lower to `Expr(:call, :(+), :a, :b)`. But it doesn't follow that needed to parse to the same syntax. For instance, the infix form could parse to `Expr(:+, ...)` or `Expr(:infixcall, :(+), ...)` or variations on this theme. It's then completely trivial to disallow method definitions that came from an infix call syntax.\r\n\r\nSince I believe the sole job of the parser is to interpret user intent, I don't believe that there's anything \"fundamental\" about the rules about how it should be coded (sorry lisp, but it seems mexprs won over the ease of writing a parser for sepxrs. http://c2.com/cgi/wiki?EmExpressions)\r\n\r\n> If you're confused, the right response is to look at the reasons actually in play and see if they make sense.\r\n\r\nHuh? This advice seems to miss the point. I interpret Tony's OP as essentially: \"hey, this unexpectedly worked instead of giving a syntax error seemingly because it was easier to parse that way instead of trying to infer user intent, but I'm not sure it is making sense\" (which is what this statement says for him to do). Also, isn't our job as language designer developers to make it so the user doesn't need to stop and say \"I'm confused, what does the compiler think is going on here?\""}}
{"actor":{"display_login":"vtjnash"}}