A simple proposal for |> and <|

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

A simple proposal for |> and <|

Glen O
It has occurred to me that a few nice features could be introduced into Julia by making just one change and one addition.

The change is simple - raise the <| operator to have just slightly higher precedence than |>. That is, if I'm understanding the julia-parser.scm file correctly, "(define prec-pipe '(|\|>| |<\||))" would be replaced by "(define prec-pipeforward '(|\|>|))" and then "(define prec-pipebackward '(|<\||))" on the next line, with appropriate changes to the "define prec-names" line. I admit that I may not be correctly understanding that file.

The addition is even simpler, in whichever jl file is appropriate:

<|(f::Function,x::Tuple)=i->f(i,x...)
<|(f::Function,x)=i->f(i,x)

It could also be supplemented with

|>(x::Tuple,f::Function)=f(x...)

but that's an optional idea relative to the rest of this.

The idea, here, is simple: it allows custom infix functions as well as easier use of commands like map in at least a subset of cases.

man |>eat<| steak would parse first as man|>(i->eat(i,steak)), and then as eat(man, steak). But what's more, you might want to do map(fill<|1,A) rather than map(i->fill(i,1),A).

I've already kind of tested the idea in Julia 0.3 by using .. instead of <|, as .. has higher precedence at present. It seems to work nicely. And assuming that it's a good idea and that my understanding of julia-parser.scm is accurate, I'd be happy to implement it myself, etc. I just don't want to do that work if it's seen as a bad idea, so I'm floating the idea here first.
Reply | Threaded
Open this post in threaded view
|

Re: A simple proposal for |> and <|

mschauer
That is a nice observation that a right curry operator <|(f,y) = x->f(x,y) and a chaining operator |> make infix notation.
What are the current anticipated uses of <|, was it introduced with having a package in mind or as free operator symmetric to |>?




On Friday, October 9, 2015 at 9:33:14 AM UTC+2, Glen O wrote:
It has occurred to me that a few nice features could be introduced into Julia by making just one change and one addition.

The change is simple - raise the <| operator to have just slightly higher precedence than |>. That is, if I'm understanding the julia-parser.scm file correctly, "(define prec-pipe '(|\|>| |<\||))" would be replaced by "(define prec-pipeforward '(|\|>|))" and then "(define prec-pipebackward '(|<\||))" on the next line, with appropriate changes to the "define prec-names" line. I admit that I may not be correctly understanding that file.

The addition is even simpler, in whichever jl file is appropriate:

<|(f::Function,x::Tuple)=i->f(i,x...)
<|(f::Function,x)=i->f(i,x)

It could also be supplemented with

|>(x::Tuple,f::Function)=f(x...)

but that's an optional idea relative to the rest of this.

The idea, here, is simple: it allows custom infix functions as well as easier use of commands like map in at least a subset of cases.

man |>eat<| steak would parse first as man|>(i->eat(i,steak)), and then as eat(man, steak). But what's more, you might want to do map(fill<|1,A) rather than map(i->fill(i,1),A).

I've already kind of tested the idea in Julia 0.3 by using .. instead of <|, as .. has higher precedence at present. It seems to work nicely. And assuming that it's a good idea and that my understanding of julia-parser.scm is accurate, I'd be happy to implement it myself, etc. I just don't want to do that work if it's seen as a bad idea, so I'm floating the idea here first.
Reply | Threaded
Open this post in threaded view
|

Re: A simple proposal for |> and <|

Michael Louwrens
In reply to this post by Glen O
This is similar to the proposed use for the colon operator. What is nice about this is that it doesn't change the meaning of the operators as the colon proposal would.
The operators still retain their meaning without introducing anything new (from my understanding). If the changes were not too large, why not submit it as a pull request anyway?

On Friday, 9 October 2015 09:33:14 UTC+2, Glen O wrote:
It has occurred to me that a few nice features could be introduced into Julia by making just one change and one addition.

The change is simple - raise the <| operator to have just slightly higher precedence than |>. That is, if I'm understanding the julia-parser.scm file correctly, "(define prec-pipe '(|\|>| |<\||))" would be replaced by "(define prec-pipeforward '(|\|>|))" and then "(define prec-pipebackward '(|<\||))" on the next line, with appropriate changes to the "define prec-names" line. I admit that I may not be correctly understanding that file.

The addition is even simpler, in whichever jl file is appropriate:

<|(f::Function,x::Tuple)=i->f(i,x...)
<|(f::Function,x)=i->f(i,x)

It could also be supplemented with

|>(x::Tuple,f::Function)=f(x...)

but that's an optional idea relative to the rest of this.

The idea, here, is simple: it allows custom infix functions as well as easier use of commands like map in at least a subset of cases.

man |>eat<| steak would parse first as man|>(i->eat(i,steak)), and then as eat(man, steak). But what's more, you might want to do map(fill<|1,A) rather than map(i->fill(i,1),A).

I've already kind of tested the idea in Julia 0.3 by using .. instead of <|, as .. has higher precedence at present. It seems to work nicely. And assuming that it's a good idea and that my understanding of julia-parser.scm is accurate, I'd be happy to implement it myself, etc. I just don't want to do that work if it's seen as a bad idea, so I'm floating the idea here first.
Reply | Threaded
Open this post in threaded view
|

Re: A simple proposal for |> and <|

Michael Louwrens
In reply to this post by Glen O
I do apologise if this is a duplicate. Posted 3 days ago but it never went through.

Anyway! Why not make a PR? It doesn't change the meaning of the pipe operators which was the issue with a similar proposal for colon. Or open an issue with this proposal at the very least.

On Friday, 9 October 2015 09:33:14 UTC+2, Glen O wrote:
It has occurred to me that a few nice features could be introduced into Julia by making just one change and one addition.

The change is simple - raise the <| operator to have just slightly higher precedence than |>. That is, if I'm understanding the julia-parser.scm file correctly, "(define prec-pipe '(|\|>| |<\||))" would be replaced by "(define prec-pipeforward '(|\|>|))" and then "(define prec-pipebackward '(|<\||))" on the next line, with appropriate changes to the "define prec-names" line. I admit that I may not be correctly understanding that file.

The addition is even simpler, in whichever jl file is appropriate:

<|(f::Function,x::Tuple)=i->f(i,x...)
<|(f::Function,x)=i->f(i,x)

It could also be supplemented with

|>(x::Tuple,f::Function)=f(x...)

but that's an optional idea relative to the rest of this.

The idea, here, is simple: it allows custom infix functions as well as easier use of commands like map in at least a subset of cases.

man |>eat<| steak would parse first as man|>(i->eat(i,steak)), and then as eat(man, steak). But what's more, you might want to do map(fill<|1,A) rather than map(i->fill(i,1),A).

I've already kind of tested the idea in Julia 0.3 by using .. instead of <|, as .. has higher precedence at present. It seems to work nicely. And assuming that it's a good idea and that my understanding of julia-parser.scm is accurate, I'd be happy to implement it myself, etc. I just don't want to do that work if it's seen as a bad idea, so I'm floating the idea here first.
Reply | Threaded
Open this post in threaded view
|

Re: A simple proposal for |> and <|

ggggg
In reply to this post by Michael Louwrens


I wonder if using bold, italics, or some other way to make text look different could be useful for allowing convenient syntax. Consider the man |>eat<| steak, if "eat" were indicated as an infix by making it bold it might look like:
man eat steak

That uses google group's formatting tool, but there are unicode only options, many of which seem to have problems displaying in the REPL. Here are screen shots of a few options I found using this site. None of them actually look very good. Maybe in a world with better unicode support it would be useful.