[elixir-core:7968] Re: Pipe and anonymous functions

2018-04-18 Thread Dylan Johnston

>
> Sorry to dredge up an old thread but I wanted to push back against this 
> again. The point of the pipe operator is to be able to clearly express the 
> flow of data through a transformation. Claiming the pipe operator shouldn't 
> be able to handle captured or anonymous functions because it confuses how 
> it works is confusing an implementation detail of how the pipe operator 
> macro works now to how it is semantically expected to behave. Having to 
> wrap them in parenthesis and an invocation introduces a great deal of noise 
> to what could be an extremely simple syntax. As Wojtek Mach showed, it's 
> fairly easy to get the pipe operator to handle these cases, especially 
> since you're pattern matching against them anyway to give error messages. 
> Why pattern match only to give an error when it's easy and straightforward 
> to just make it work, what else could a user intend other than to call the 
> function?. There's a pull request here I made than extends his work so that 
> captured functions and anonymous functions both work. 
> https://github.com/wojtekmach/pipe_capture/pull/1
>
 
"Hello"
|> fn x -> IO.puts x end
|> &IO.puts/1
|> &IO.puts(:stderr, &1)

 vs

"Hello"
|> (fn x -> IO.puts x; x end).()
|> (&IO.puts/1).()
|> (&IO.puts(:stderr, &1)).()

It seems weird to me that the pipe macro works exclusively on already 
invoked functions and doesn't know what to do with a function reference.

-- 
You received this message because you are subscribed to the Google Groups 
"elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elixir-lang-core+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/elixir-lang-core/b2182e21-939e-4762-b603-9cd492e1650b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [elixir-core:7967] Re: Pipe and anonymous functions

2018-04-18 Thread Louis Pilfold
It's not that weird when you think about it in terms of the AST that the
macro operates on, and not in terms of types.

The former would require rewriting the forms into anon function calls,
while the latter just prepends a value onto the argument list. `|>` is a
very very simple macro that can be implemented in a single line. There's a
bunch of friendly error handling in the one in Kernel, but it's still just
as simple.

Cheers,
Louis

On Wed, 18 Apr 2018 at 11:36 Dylan Johnston 
wrote:

> Sorry to dredge up an old thread but I wanted to push back against this
>> again. The point of the pipe operator is to be able to clearly express the
>> flow of data through a transformation. Claiming the pipe operator shouldn't
>> be able to handle captured or anonymous functions because it confuses how
>> it works is confusing an implementation detail of how the pipe operator
>> macro works now to how it is semantically expected to behave. Having to
>> wrap them in parenthesis and an invocation introduces a great deal of noise
>> to what could be an extremely simple syntax. As Wojtek Mach showed, it's
>> fairly easy to get the pipe operator to handle these cases, especially
>> since you're pattern matching against them anyway to give error messages.
>> Why pattern match only to give an error when it's easy and straightforward
>> to just make it work, what else could a user intend other than to call the
>> function?. There's a pull request here I made than extends his work so that
>> captured functions and anonymous functions both work.
>> https://github.com/wojtekmach/pipe_capture/pull/1
>>
>
> "Hello"
> |> fn x -> IO.puts x end
> |> &IO.puts/1
> |> &IO.puts(:stderr, &1)
>
>  vs
>
> "Hello"
> |> (fn x -> IO.puts x; x end).()
> |> (&IO.puts/1).()
> |> (&IO.puts(:stderr, &1)).()
>
> It seems weird to me that the pipe macro works exclusively on already
> invoked functions and doesn't know what to do with a function reference.
>
> --
> You received this message because you are subscribed to the Google Groups
> "elixir-lang-core" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elixir-lang-core+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/elixir-lang-core/b2182e21-939e-4762-b603-9cd492e1650b%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elixir-lang-core+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/elixir-lang-core/CABu8xFDB7oMcaXNfrYbkh%3DrLz7YcZMRzcuODjHWaJKp5DkNxZw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [elixir-core:7968] Re: Pipe and anonymous functions

2018-04-18 Thread OvermindDL1
Going on that route though, it is weird when compared to the vast variety
of languages that had pipes before elixir though.  Still though, it's not
easy to change the current pattern without either lots of case's being
generated in the backend or for the language to get a somewhat half decent
type system.


On Wed, Apr 18, 2018, 06:27 Louis Pilfold  wrote:

> It's not that weird when you think about it in terms of the AST that the
> macro operates on, and not in terms of types.
>
> The former would require rewriting the forms into anon function calls,
> while the latter just prepends a value onto the argument list. `|>` is a
> very very simple macro that can be implemented in a single line. There's a
> bunch of friendly error handling in the one in Kernel, but it's still just
> as simple.
>
> Cheers,
> Louis
>
> On Wed, 18 Apr 2018 at 11:36 Dylan Johnston 
> wrote:
>
>> Sorry to dredge up an old thread but I wanted to push back against this
>>> again. The point of the pipe operator is to be able to clearly express the
>>> flow of data through a transformation. Claiming the pipe operator shouldn't
>>> be able to handle captured or anonymous functions because it confuses how
>>> it works is confusing an implementation detail of how the pipe operator
>>> macro works now to how it is semantically expected to behave. Having to
>>> wrap them in parenthesis and an invocation introduces a great deal of noise
>>> to what could be an extremely simple syntax. As Wojtek Mach showed, it's
>>> fairly easy to get the pipe operator to handle these cases, especially
>>> since you're pattern matching against them anyway to give error messages.
>>> Why pattern match only to give an error when it's easy and straightforward
>>> to just make it work, what else could a user intend other than to call the
>>> function?. There's a pull request here I made than extends his work so that
>>> captured functions and anonymous functions both work.
>>> https://github.com/wojtekmach/pipe_capture/pull/1
>>>
>>
>> "Hello"
>> |> fn x -> IO.puts x end
>> |> &IO.puts/1
>> |> &IO.puts(:stderr, &1)
>>
>>  vs
>>
>> "Hello"
>> |> (fn x -> IO.puts x; x end).()
>> |> (&IO.puts/1).()
>> |> (&IO.puts(:stderr, &1)).()
>>
>> It seems weird to me that the pipe macro works exclusively on already
>> invoked functions and doesn't know what to do with a function reference.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "elixir-lang-core" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to elixir-lang-core+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/elixir-lang-core/b2182e21-939e-4762-b603-9cd492e1650b%40googlegroups.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "elixir-lang-core" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elixir-lang-core+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/elixir-lang-core/CABu8xFDB7oMcaXNfrYbkh%3DrLz7YcZMRzcuODjHWaJKp5DkNxZw%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elixir-lang-core+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/elixir-lang-core/CAJhqboGLoxbiLOog_OokSing%2B6VRdF9thzYKEQmF034i1HwgJA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.