infix notation for more functions

[my-little-repository]

This is a feature request. The in function has both a prefix and infix notation. It would be nice to have infix notation for the functions beginswith, endswith and contains, e.g.

julia> "julialang" beginswith 'j'
true

[lindahua]

If we provide infix form for beginswith, then a large number of other functions may want to get this privilege. I think it is enough to provide a very small number of infix operators that cover the most common operations.

Also "julialang" beginswith 'j' doesn't seem to be a huge improvement over beginswith("julialang", 'j') to me.

[my-little-repository]

I beg to differ. There are not a large number of functions that may be written in infix notation. When it comes to string manipulation, I have not seen any other functions than the ones I am describing above.

And "julialang" beginswith 'j' seems to give the same improvement over beginswith("julialang", 'j')
that x in y gives over in(x,y). I would even dare to say that it is in fact a better improvement because the infix in notation introduces an ambiguity in the language (in is also a synonym for = in for loops). There is no such ambiguity with beginswith.

[johnmyleswhite]

I agree with Dahua: there's no reason to do this unless we make it possible to use all binary functions as infix operators.

[quinnj]

Also see here for the discussion on infix operators.

#2703

This was closed when the in syntax was added, but there was also discussion
of allowing for user specified infix functions along these lines. Perhaps
another issue could be opened for the generalized case.

-Jacob
On Oct 13, 2013 1:00 PM, "John Myles White" notifications@github.com
wrote:

I agree with Dahua: there's no reason to do this unless we make it
possible to use all binary functions as infix operators.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/4498#issuecomment-26221653
.

[JeffBezanson]

There are some problems with that, such as [1 + 2] and [x in y] being 1-element arrays and [x f y] being a 3-element array. Maybe a haskell-like x f y could work.

[johnmyleswhite]

I would be pretty into the Haskell approach to infix functions.

[diegozea]

I like the Haskell approach.
There is something similar on R: You can define an infix function in R using % around the name

[ssfrr]

Haskell automatically treats all-symbol functions as infix, and alphanumeric functions can be treated as infix with the backtics, as @JeffBezanson mentions. I like this in the sense that it's less special case ("these are the operators that we've hard-coded into the parser to be infix"). Of course with the unicode support it's a little more complicated to define clearly what's alphanumeric.

Though the trade off of making it easy to define custom symbolic infix operators is that people will. :)

Making symbolic functions infix and allowing alphanumeric functions to be "infixed" using backtics are orthogonal questions though, so perhaps if there's much more discussion on it we should split it out into a separate issue.

[ssfrr]

Reading around a little more on this, the backticks have been discussed here where @StefanKarpinski is not a fan. In #552 @JeffBezanson also says that this isn't happening because of limited ascii space.

Unicode/symbolic operators were discussed in #552 as a possible future feature but not a high priority.

[damiendr]

The Haskell approach would be especially nice in the context of mini-domain specific languages.
Eg. being able to create a graph this way:

a -> b -> c

with -> being the "connect" function.

The downside of restricting infix functions to unicode characters is that there is no easy way to type →.

[StefanKarpinski]

\rightarrow<tab>

[jiahao]

I'm tempted to close this in light of #552, #6929.

[damiendr]

@StefanKarpinski This doesn't work on any of my code editors, and neither do MacOSX's substitution rules (seems like they only work when editing rich text). But even then, that's 5 times the number of keystrokes (6 times on a fr keyboard), plus remembering the macro name. Also → confuses both Terminal.app and iTerm.app at the time being. I'm not entirely against the use of unicode in source code, but it feels like it's a bit ahead of its time...

The ability to neatly express embedded DSLs is a really, really powerful feature for a language, especially when coupled with Julia's metaprogramming. And freedom in defining your own infix operators is crucial for that! For instance let's say you want to use <- or :=. These operators can be typed in a completely obvious way with 2 keystrokes in Graphviz and Pascal, respectively. It would seem a bit impractical to require \colonequals<tab> or \leftarrow<tab> or alt-2254 in Julia... especially when ASCII == is accepted.

My feeling is that the current approach to infixes in Julia is a bit too restrictive for embedded DSLs, also because it's totally not obvious which of the many unicode math operators will work. An explicit approach would be much clearer IMHO.