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

Postfix notation not typing #9509

Closed
dlfivefifty opened this issue Dec 31, 2014 · 4 comments
Closed

Postfix notation not typing #9509

dlfivefifty opened this issue Dec 31, 2014 · 4 comments

Comments

@dlfivefifty
Copy link
Contributor

I was under the impression f(g) and g|>f are synonyms, so the following is strange:

julia> foo(cfs)=length(cfs)
foo (generic function with 1 method)

julia> foo2(cfs)=cfs|>length
foo2 (generic function with 1 method)

julia> @code_typed foo([1,2,3])
1-element Array{Any,1}:
:($(Expr(:lambda, Any[:cfs], Any[Any[],Any[Any[:cfs,Array{Int64,1},0]],Any[]], :(begin # none, line 1:
return (top(arraylen))(cfs::Array{Int64,1})::Int64
end::Int64))))

julia> @code_typed foo2([1,2,3])
1-element Array{Any,1}:
:($(Expr(:lambda, Any[:cfs], Any[Any[],Any[Any[:cfs,Array{Int64,1},0]],Any[]], :(begin # none, line 1:
return (length::F)(cfs::Array{Int64,1})
end))))

@simonster
Copy link
Member

|> is a function like any other; cfs |> length behaves the same way as g(cfs, length) where g(x, f) = f(x). We can't (yet) optimize cases where functions are passed to functions (see "function-valued argument inlining" in #3440), but this is planned.

@dlfivefifty
Copy link
Contributor Author

OK I guess its best to avoid |> in library code for the time being.

Could a work around be to force |>(f,g)  to be inlined?  (If forced inlining is possible.)

On 31 Dec 2014, at 11:23 am, Simon Kornblith notifications@github.com wrote:

|> is a function

|>(x, f::Callable) = f(x)
like any other; cfs |> length behaves the same way as g(cfs, length) where g(x, f) = f(x). We can't (yet) optimize cases where functions are passed to functions (see "function-valued argument inlining" in #3440 #3440), but this is planned.


Reply to this email directly or view it on GitHub #9509 (comment).

@simonster
Copy link
Member

In the code above, |> is actually inlined into foo2, but inlining happens after type inference so it doesn't provide any type information. We really want to inline length into |> and then inline |> into foo2 so that the type information propagates, or else rerun type inference after inlining.

@vtjnash
Copy link
Member

vtjnash commented Dec 31, 2014

covered by #210

@vtjnash vtjnash closed this as completed Dec 31, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants