Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use \mapsto ( ↦ ) for anonymous functions #11223

Open
dpsanders opened this issue May 10, 2015 · 32 comments
Open

Use \mapsto ( ↦ ) for anonymous functions #11223

dpsanders opened this issue May 10, 2015 · 32 comments
Labels
breaking This change will break code needs decision A decision on this change is needed

Comments

@dpsanders
Copy link
Contributor

It would be nice to be able to use the correct mathematical notation " ↦ " (\mapsto) for anonymous functions, x ↦ f(x), in addition to x -> f(x)

This sounds like it should be a relatively easy addition to the parser (but I don't know where to start).

@StefanKarpinski
Copy link
Member

+1

@jakebolewski
Copy link
Member

If you want to try it out

diff --git a/src/julia-parser.scm b/src/julia-parser.scm
index 36981c0..b4a1423 100644
--- a/src/julia-parser.scm
+++ b/src/julia-parser.scm
@@ -64,7 +64,7 @@
 ; operators that are special forms, not function names
 (define syntactic-operators
   '(= := += -= *= /= //= .//= .*= ./= |\\=| |.\\=| ^= .^= ÷= .÷= %= .%= |\|=| &= $= =>
-      <<= >>= >>>= -> --> |\|\|| && |.| ... |.+=| |.-=|))
+      <<= >>= >>>= -> ↦ --> |\|\|| && |.| ... |.+=| |.-=|))
 (define syntactic-unary-operators '($ & |::|))

 (define syntactic-op? (Set syntactic-operators))
@@ -74,7 +74,7 @@
 (define ctrans-op (string->symbol "'"))
 (define vararg-op (string->symbol "..."))

-(define operators (list* '~ '! '¬ '-> '√ '∛ '∜ ctrans-op trans-op vararg-op
+(define operators (list* '~ '! '¬ '-> '↦ '√ '∛ '∜ ctrans-op trans-op vararg-op
                          (delete-duplicates
                           (apply append (map eval prec-names)))))

@@ -897,7 +897,7 @@
       (case t
         ((|::|) (take-token s)
          (loop (list t ex (parse-call s))))
-        ((->)   (take-token s)
+        ((->  ↦)   (take-token s)
          ;; -> is unusual: it binds tightly on the left and
          ;; loosely on the right.
          (let ((lno (line-number-filename-node s)))

@tkelman
Copy link
Contributor

tkelman commented May 10, 2015

Would it need to be removed from prec-arrow?

@jakebolewski
Copy link
Member

Yes, it should be if this were the a formal PR. But -1 on this proposal, I don't like the use of unicode for special forms that have a perfectly sane ascii equivalent.

@jakebolewski
Copy link
Member

Similar to #8487

@dpsanders
Copy link
Contributor Author

@jakebolewski Great, thanks for the code sample.

I see where you're coming from, but it seems to me that basically all unicode would be excluded by your reasoning, e.g. using α (\alpha) instead of alpha.

From my point of view, one of the points of allowing unicode is that code can resemble hand-written (or LaTeX) equations as much as possible. \mapsto is a nice step in that direction. #8487 is not quite the same, since in maths you don't actually write for i ∈ 1:10.

@stevengj
Copy link
Member

+1. It seems like there is no other sane meaning for \mapsto other than ->, so if we are going to accept it at all, we might as make the two synonyms. No different from \sqrt for sqrt or \le for <=.

@JeffBezanson
Copy link
Member

One difference is that it's a special form, so can't be handled with a simple alias.

@stevengj
Copy link
Member

One counter-proposal: it might be useful to parse \mapsto as a macro @mapsto args body. e.g. @timholy's FastAnonymous package could then make x ↦ f(x) turn into @anon x -> f(x), and in general a package could use this for construction of new function-like objects.

@MithrandirMiles
Copy link

👍 That's a cool use of the Unicode character!

@MikeInnes
Copy link
Member

+1

@StefanKarpinski
Copy link
Member

I really don't think we should make an operator for something that is a stopgap for something that just ought to be fixed.

@tkelman
Copy link
Contributor

tkelman commented May 11, 2015

Reminds me of the macro-parsing of ~ which seems a bit arbitrary to me. If you want macro parsing, shouldn't you use a macro?

@shashi
Copy link
Contributor

shashi commented May 11, 2015

Yes, ~ being a macro was surprising

I like @stevengj's idea of allowing a few infix operators as macros, although I'm not sure if is a good candidate for it.

A bit unrelated: I'd really like to use ~> and <~ as aliases for lift in Reactive... e.g. lift(sqrt, signal) would be equivalent to signal ~> sqrt or sqrt <~ signal. Currently this is not possible though.

@stevengj
Copy link
Member

The reason I suggested a macro for is that if (a) we parse for overloading, the most sensible use for it would be for user-defined function-like syntaxes (FastAnonymous being just one example) and (b) if you want to define your own function-like operator syntax, you kind of need a macro.

@nalimilan
Copy link
Member

It would look less confusing to me to have and -> mean exactly the same thing.

@MikeInnes
Copy link
Member

~ is a slightly weird special case, but if anything I'd vote for fixing that by making more operators parse as macros, not fewer – and if that's not feasible I think the benefit of a few special cases outweighs the aesthetic cost. They're really, really useful for making intuitive APIs. As an example of a non-DataFrames use of ~ I'm working on an object system of sorts with syntax

object~method(x, y)

Of course, I could write this as

@call object.method(x, y)

but if you're using the system a lot this adds a ton of noise to the code. It's really nice to have an escape hatch here.

I agree that it wouldn't be right to make this work specifically for FastAnonymous, but as @stevengj says this could have plenty of uses for function-like things (Reactive.jl, function-like operators, etc.).

@shashi
Copy link
Contributor

shashi commented May 12, 2015

I was noting that should either parse as macro OR as a synonym for ->, and cannot have both meanings. I agree that is a useful symbol to parse as a macro. One more thing to note: the usefulness of a macro operator will go away if two packages define macros of the same name, i.e. you cannot use the infix notation (for one of them) anymore if both packages are loaded.

@tkelman
Copy link
Contributor

tkelman commented May 12, 2015

@one-more-minute I'm not convinced. In addition to macro-operators being poorly composable due to the lack of namespacing, there's already a quite straightforward escape hatch for dsl's to cut down on macro-call noise:

@dsl begin
    # anything you want
end

@ihnorton ihnorton added the needs decision A decision on this change is needed label May 13, 2015
@jasonmorton
Copy link

Julia's support of Latex notation for unicode makes it really easy to create mathematical DSLs that look and feel like the mathematics we are used to writing. I'm making liberal use of them as operators (\otimes, \circ) myself. However, every time a symbol is reserved in the base language, the ability to do this is diminished. Keep in mind that the same symbol, however standard it may seem to be, ends up used differently in different subfields of math, physics, economics, and so on where Julia may be used. For a non-unicode example, I had to rewrite a lot of code when capital I became UniformScaling, since I was using it to mean the monoidal identity in a monoidal category, where that use is also standard.

Another consideration is that unicode support is still buggy in many places (e.g. the red boxes in saved IJulia notebooks). For example, the default system font in Ubuntu 15.04 causes unicode characters to behave incorrectly (spacing issues causing illegibility or huge spaces) in the Julia terminal and in emacs until the font settings are changed.

You gave us unicode and you can take it away, but let me plead for extreme caution in reserving things.

@Jutho
Copy link
Contributor

Jutho commented Aug 11, 2017

I'll ask this here, as I did not right away find any other appropriate issue and I guess several of the Unicode & Julia experts are subscribed to this issue. I didn't want to open a new issue right away for something so small.

It's great that \mapsto at least parses as infix operator. Strangely enough, this is not true for \mapsfrom. \leftarrow and \rightarrow both work and could serve as an alternative if there is a good reason why this is the case.

So all of these work, in an expression:

:(a  b)
:(a  b)
:(a  b)

but this one :(a ↤ b) yields

ERROR: syntax: missing comma or ) in argument list

Any reason why this is so?

@JeffBezanson
Copy link
Member

\mapsfrom is somehow not included in our list of operators. Probably an oversight. It should be added.

@dpsanders
Copy link
Contributor Author

This just came up again on Slack. Maybe it's time to reconsider this?
It actually seems to have been closed prematurely despite quite a few +1s.

@sdewaele
Copy link

sdewaele commented Apr 7, 2020

+1.

-> is a frequently used construct. Using ↦ will make a lot of code look cleaner / compact / more like pseudocode.

@c42f
Copy link
Member

c42f commented Jul 22, 2020

I'm going to reopen this as there still seems to be broad interest, and there's no recorded reason for why it was closed.

@c42f c42f reopened this Jul 22, 2020
@StefanKarpinski
Copy link
Member

I think Jake just decided that he didn't like it.

@JeffBezanson
Copy link
Member

I can think of several points against this:

  • It adds spurious syntax variations. Code with a mix of -> and would be quite annoying.
  • It's breaking, since this currently parses as a normal function-like operator.
  • Use \mapsto ( ↦ ) for anonymous functions #11223 (comment) (which seems to be what triggered the closing): better not to "steal" syntax when we already have decent syntax for something.

@c42f
Copy link
Member

c42f commented Jul 23, 2020

I didn't find #11223 (comment) super convincing but you've got some good points.

The mathematician in me really wants this to work so I'm torn. I'll admit that personally I don't even use in code even though I love the look of it. It seems a bit spurious and confusing for readers to have to navigate that syntax variation.

@JeffBezanson
Copy link
Member

@musm
Copy link
Contributor

musm commented Jul 30, 2020

Cascadia code will also do the substitutions that @JeffBezanson linked to in Julia Mono

@ExpandingMan
Copy link
Contributor

I want to resurrect this, as every time I type -> I die a little bit inside. If I do a PR, is there any chance it would be accepted? Though, much to my chagrin, I'm sure it would have to wait for 1.8 because of deprecations.

@stevengj
Copy link
Member

I feel like there is a broad consensus of the core devs against this…

@mbauman mbauman added the breaking This change will break code label Feb 16, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
breaking This change will break code needs decision A decision on this change is needed
Projects
None yet
Development

No branches or pull requests