Re: [elixir-core:9911] Validating keywords keys

[Andrea Leopardi]

Considering how straightforward the code you showed is, and that for more
complex scenarios we have libraries like nimble_options, I might be
slightly hesitant to add this to core.

Andrea

On Wed, 30 Dec 2020 at 08:53, José Valim  wrote:

> Hi everyone,
>
> I am working on a new project and yesterday I spent a couple hours on a
> bug due to a in a keyword list. In a nutshell, I was supposed to pass
> parenthesis: 10 as keywords to a function but I passed parentheses: 10.
>
> I have fixed the issue by adding the following code:
>
> for {k, _} <- keyword, k not in [:parentheses, :other_options], do:
> raise "unknown key #{inspect(k)} in #{inspect(keyword)}"
>
> The code is super straight-forward but I am wondering if we should add it
> to Elixir to promote said validation. What do you think? Any suggestions on
> where it should be defined and with which name?
>
> Thank you!
>
> --
> 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/CAGnRm4J8_RG5eeCZSw_c75Q4y19YFt-ipdnTAEa1cE2GnvwjrQ%40mail.gmail.com
> 
> .
>

-- 
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/CAM9Rf%2BJPu8tF2VzNB4beDqO9jc%2BF-SDE6u%3D724EZm9271jY2ug%40mail.gmail.com.

[elixir-core:9910] Validating keywords keys

[José Valim]

Hi everyone,

I am working on a new project and yesterday I spent a couple hours on a bug
due to a in a keyword list. In a nutshell, I was supposed to pass
parenthesis: 10 as keywords to a function but I passed parentheses: 10.

I have fixed the issue by adding the following code:

for {k, _} <- keyword, k not in [:parentheses, :other_options], do:
raise "unknown key #{inspect(k)} in #{inspect(keyword)}"

The code is super straight-forward but I am wondering if we should add it
to Elixir to promote said validation. What do you think? Any suggestions on
where it should be defined and with which name?

Thank you!

-- 
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/CAGnRm4J8_RG5eeCZSw_c75Q4y19YFt-ipdnTAEa1cE2GnvwjrQ%40mail.gmail.com.

Re: [elixir-core:9909] [Proposal] Inspection using a function

[Zach Daniel]

Ah, you’re right. Apologies. I think I’d still prefer not to overload it,
but you are correct that it wouldn’t conflict.

On Tue, Dec 29, 2020 at 10:23 PM Austin Ziegler 
wrote:

> Using an alternate form of `apply/2` would work, because, while there’s no
> guard from the Elixir side, the second parameter of `apply/2` must be an
> array.
>
> ```
> iex(1)> apply(fn q -> q end, fn -> nil end)
> ** (ArgumentError) argument error
> :erlang.length(#Function<21.126501267/0 in :erl_eval.expr/5>)
> iex(1)> apply(fn q -> q end, [fn -> nil end])
> #Function<21.126501267/0 in :erl_eval.expr/5>
> iex(2)> apply(& &1, 3)
> ** (ArgumentError) argument error
> :erlang.length(3)
> iex(2)> apply(& &1, [3])
> 3
> iex(3)> apply(& &1, [])
> ** (BadArityError) #Function<7.126501267/1 in :erl_eval.expr/5> with arity
> 1 called with no arguments
> ```
>
> -a
>
> On Tue, Dec 29, 2020 at 3:59 PM Zach Daniel 
> wrote:
>
>> That variant doesn’t really work because what if you want to pass a
>> function as the first argument to what you’re calling? I don’t think
>> muddying the behavior of “apply” is worth the extra confusion. I think
>> either `tap/2` or a `with` Inspect option is the way. People will
>> ultimately need to look this function up anyway, I don’t think the merit of
>> the name is “would I guess this name based on what I want”, because most
>> things on programming fail that litmus test . We just need a
>> memorable/reasonable name.
>>
>> On Tue, Dec 29, 2020 at 3:53 PM Louis Pilfold 
>> wrote:
>>
>>> Heya
>>>
>>> "apply" is the name I first thought of here. In fact I've tried to use
>>> apply like this before!
>>>
>>> Cheers,
>>> Louis
>>>
>>> On Tue, 29 Dec 2020, 20:22 Austin Ziegler,  wrote:
>>>
 Couldn’t this be a special case of `Kernel.apply/2`?

 ```elixir
 @spec apply(fun | any, list(any) | fun) :: any
 def apply(arg, fun) when is_function(fun, 1)) do
   fun.(arg)
 end

 def apply(fun, args) do
   :erlang.apply(fun, args)
 end
 ```

 This would read really well (IMO):

 ```elixir
 [1, 2, 3, 5, 7]
 |> apply((&1, fn x -> x * 2 end))
 ```

 If it’s preferred not to make a special form of apply/2, then perhaps
 `then_apply/2`?

 -a

 On Tue, Dec 29, 2020 at 1:11 PM Paul Clegg 
 wrote:

> On Tue, Dec 29, 2020 at 1:47 AM José Valim 
> wrote:
>
>> I propose we simply add two functions to Kernel: tap and then.
>>
>> 1. tap receives an anonymous function, invokes it, and returns the
>> argument. It can be found in Ruby and .NET Rx.
>>
>> 2. then receives an anonymous function, invokes it, and returns the
>> result of the anonymous function. It will be how we can pipe to anonymous
>> functions in Elixir. It is named andThen in Scala and known as then in 
>> many
>> promise libraries across ecosystems.
>>
>
> I'm all for "tap"; I've been writing this function myself for a while
> now, as easy as it is...  Not as sure about "then", though, I've been able
> to get this to work without much problem, ala;
>
> iex(30)> foo = &(IO.puts(&1))
> /1
> iex(31)> "biff" |> (foo).()
> biff
> :ok
> iex(32)> foo = &(&1 <> &2)
> #Function<43.97283095/2 in :erl_eval.expr/5>
> iex(33)> "biff" |> (foo).("bar")
> "biffbar"
>
> The parens + .() combination seem to work just fine without any
> additional work.  It's just the tap that gets messy if you want to do it
> "inline" often:
>
> iex(34)> "biff" |> (fn x -> IO.puts("foo"); x; end).()
> foo
> "biff"
>
> ...so for that, I'd love 'tap()' so I don't forget to return the
> original x.  :D
>
> ...Paul
>
>
>
>
>
>
> --
> 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/CAD3kWz-MCWvdbmTRe0qP5gz57%3Diy5fOcsmNLNT1cZRe5N_D9MA%40mail.gmail.com
> 
> .
>


 --
 Austin Ziegler • halosta...@gmail.com • aus...@halostatue.ca
 http://www.halostatue.ca/ • http://twitter.com/halostatue

 --
 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/CAJ4ekQtrodwKZsN0KE_omixojeuge1N2-3DDZjMbwvtNR_naSA%40mail.gmail.com
 

Re: [elixir-core:9908] [Proposal] Inspection using a function

[Austin Ziegler]

Using an alternate form of `apply/2` would work, because, while there’s no
guard from the Elixir side, the second parameter of `apply/2` must be an
array.

```
iex(1)> apply(fn q -> q end, fn -> nil end)
** (ArgumentError) argument error
:erlang.length(#Function<21.126501267/0 in :erl_eval.expr/5>)
iex(1)> apply(fn q -> q end, [fn -> nil end])
#Function<21.126501267/0 in :erl_eval.expr/5>
iex(2)> apply(& &1, 3)
** (ArgumentError) argument error
:erlang.length(3)
iex(2)> apply(& &1, [3])
3
iex(3)> apply(& &1, [])
** (BadArityError) #Function<7.126501267/1 in :erl_eval.expr/5> with arity
1 called with no arguments
```

-a

On Tue, Dec 29, 2020 at 3:59 PM Zach Daniel 
wrote:

> That variant doesn’t really work because what if you want to pass a
> function as the first argument to what you’re calling? I don’t think
> muddying the behavior of “apply” is worth the extra confusion. I think
> either `tap/2` or a `with` Inspect option is the way. People will
> ultimately need to look this function up anyway, I don’t think the merit of
> the name is “would I guess this name based on what I want”, because most
> things on programming fail that litmus test . We just need a
> memorable/reasonable name.
>
> On Tue, Dec 29, 2020 at 3:53 PM Louis Pilfold 
> wrote:
>
>> Heya
>>
>> "apply" is the name I first thought of here. In fact I've tried to use
>> apply like this before!
>>
>> Cheers,
>> Louis
>>
>> On Tue, 29 Dec 2020, 20:22 Austin Ziegler,  wrote:
>>
>>> Couldn’t this be a special case of `Kernel.apply/2`?
>>>
>>> ```elixir
>>> @spec apply(fun | any, list(any) | fun) :: any
>>> def apply(arg, fun) when is_function(fun, 1)) do
>>>   fun.(arg)
>>> end
>>>
>>> def apply(fun, args) do
>>>   :erlang.apply(fun, args)
>>> end
>>> ```
>>>
>>> This would read really well (IMO):
>>>
>>> ```elixir
>>> [1, 2, 3, 5, 7]
>>> |> apply((&1, fn x -> x * 2 end))
>>> ```
>>>
>>> If it’s preferred not to make a special form of apply/2, then perhaps
>>> `then_apply/2`?
>>>
>>> -a
>>>
>>> On Tue, Dec 29, 2020 at 1:11 PM Paul Clegg 
>>> wrote:
>>>
 On Tue, Dec 29, 2020 at 1:47 AM José Valim 
 wrote:

> I propose we simply add two functions to Kernel: tap and then.
>
> 1. tap receives an anonymous function, invokes it, and returns the
> argument. It can be found in Ruby and .NET Rx.
>
> 2. then receives an anonymous function, invokes it, and returns the
> result of the anonymous function. It will be how we can pipe to anonymous
> functions in Elixir. It is named andThen in Scala and known as then in 
> many
> promise libraries across ecosystems.
>

 I'm all for "tap"; I've been writing this function myself for a while
 now, as easy as it is...  Not as sure about "then", though, I've been able
 to get this to work without much problem, ala;

 iex(30)> foo = &(IO.puts(&1))
 /1
 iex(31)> "biff" |> (foo).()
 biff
 :ok
 iex(32)> foo = &(&1 <> &2)
 #Function<43.97283095/2 in :erl_eval.expr/5>
 iex(33)> "biff" |> (foo).("bar")
 "biffbar"

 The parens + .() combination seem to work just fine without any
 additional work.  It's just the tap that gets messy if you want to do it
 "inline" often:

 iex(34)> "biff" |> (fn x -> IO.puts("foo"); x; end).()
 foo
 "biff"

 ...so for that, I'd love 'tap()' so I don't forget to return the
 original x.  :D

 ...Paul






 --
 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/CAD3kWz-MCWvdbmTRe0qP5gz57%3Diy5fOcsmNLNT1cZRe5N_D9MA%40mail.gmail.com
 
 .

>>>
>>>
>>> --
>>> Austin Ziegler • halosta...@gmail.com • aus...@halostatue.ca
>>> http://www.halostatue.ca/ • http://twitter.com/halostatue
>>>
>>> --
>>> 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/CAJ4ekQtrodwKZsN0KE_omixojeuge1N2-3DDZjMbwvtNR_naSA%40mail.gmail.com
>>> 
>>> .
>>>
>> --
>> 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 

Re: [elixir-core:9907] [Proposal] Inspection using a function

[Zach Daniel]

That variant doesn’t really work because what if you want to pass a
function as the first argument to what you’re calling? I don’t think
muddying the behavior of “apply” is worth the extra confusion. I think
either `tap/2` or a `with` Inspect option is the way. People will
ultimately need to look this function up anyway, I don’t think the merit of
the name is “would I guess this name based on what I want”, because most
things on programming fail that litmus test . We just need a
memorable/reasonable name.

On Tue, Dec 29, 2020 at 3:53 PM Louis Pilfold 
wrote:

> Heya
>
> "apply" is the name I first thought of here. In fact I've tried to use
> apply like this before!
>
> Cheers,
> Louis
>
> On Tue, 29 Dec 2020, 20:22 Austin Ziegler,  wrote:
>
>> Couldn’t this be a special case of `Kernel.apply/2`?
>>
>> ```elixir
>> @spec apply(fun | any, list(any) | fun) :: any
>> def apply(arg, fun) when is_function(fun, 1)) do
>>   fun.(arg)
>> end
>>
>> def apply(fun, args) do
>>   :erlang.apply(fun, args)
>> end
>> ```
>>
>> This would read really well (IMO):
>>
>> ```elixir
>> [1, 2, 3, 5, 7]
>> |> apply((&1, fn x -> x * 2 end))
>> ```
>>
>> If it’s preferred not to make a special form of apply/2, then perhaps
>> `then_apply/2`?
>>
>> -a
>>
>> On Tue, Dec 29, 2020 at 1:11 PM Paul Clegg 
>> wrote:
>>
>>> On Tue, Dec 29, 2020 at 1:47 AM José Valim 
>>> wrote:
>>>
 I propose we simply add two functions to Kernel: tap and then.

 1. tap receives an anonymous function, invokes it, and returns the
 argument. It can be found in Ruby and .NET Rx.

 2. then receives an anonymous function, invokes it, and returns the
 result of the anonymous function. It will be how we can pipe to anonymous
 functions in Elixir. It is named andThen in Scala and known as then in many
 promise libraries across ecosystems.

>>>
>>> I'm all for "tap"; I've been writing this function myself for a while
>>> now, as easy as it is...  Not as sure about "then", though, I've been able
>>> to get this to work without much problem, ala;
>>>
>>> iex(30)> foo = &(IO.puts(&1))
>>> /1
>>> iex(31)> "biff" |> (foo).()
>>> biff
>>> :ok
>>> iex(32)> foo = &(&1 <> &2)
>>> #Function<43.97283095/2 in :erl_eval.expr/5>
>>> iex(33)> "biff" |> (foo).("bar")
>>> "biffbar"
>>>
>>> The parens + .() combination seem to work just fine without any
>>> additional work.  It's just the tap that gets messy if you want to do it
>>> "inline" often:
>>>
>>> iex(34)> "biff" |> (fn x -> IO.puts("foo"); x; end).()
>>> foo
>>> "biff"
>>>
>>> ...so for that, I'd love 'tap()' so I don't forget to return the
>>> original x.  :D
>>>
>>> ...Paul
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>> 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/CAD3kWz-MCWvdbmTRe0qP5gz57%3Diy5fOcsmNLNT1cZRe5N_D9MA%40mail.gmail.com
>>> 
>>> .
>>>
>>
>>
>> --
>> Austin Ziegler • halosta...@gmail.com • aus...@halostatue.ca
>> http://www.halostatue.ca/ • http://twitter.com/halostatue
>>
>> --
>> 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/CAJ4ekQtrodwKZsN0KE_omixojeuge1N2-3DDZjMbwvtNR_naSA%40mail.gmail.com
>> 
>> .
>>
> --
> 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/CABu8xFA%2BUen_jgrt96skqmv91JCdV3-1JiRNz1fyL_w6B0SuWQ%40mail.gmail.com
> 
> .
>

-- 
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/CAK-yb0AE1rH--%2BLoNFD54euC%2BSuvYVYWtn1bgBORh%3D3mMVuLOw%40mail.gmail.com.

Re: [elixir-core:9906] [Proposal] Inspection using a function

[Louis Pilfold]

Heya

"apply" is the name I first thought of here. In fact I've tried to use
apply like this before!

Cheers,
Louis

On Tue, 29 Dec 2020, 20:22 Austin Ziegler,  wrote:

> Couldn’t this be a special case of `Kernel.apply/2`?
>
> ```elixir
> @spec apply(fun | any, list(any) | fun) :: any
> def apply(arg, fun) when is_function(fun, 1)) do
>   fun.(arg)
> end
>
> def apply(fun, args) do
>   :erlang.apply(fun, args)
> end
> ```
>
> This would read really well (IMO):
>
> ```elixir
> [1, 2, 3, 5, 7]
> |> apply((&1, fn x -> x * 2 end))
> ```
>
> If it’s preferred not to make a special form of apply/2, then perhaps
> `then_apply/2`?
>
> -a
>
> On Tue, Dec 29, 2020 at 1:11 PM Paul Clegg 
> wrote:
>
>> On Tue, Dec 29, 2020 at 1:47 AM José Valim  wrote:
>>
>>> I propose we simply add two functions to Kernel: tap and then.
>>>
>>> 1. tap receives an anonymous function, invokes it, and returns the
>>> argument. It can be found in Ruby and .NET Rx.
>>>
>>> 2. then receives an anonymous function, invokes it, and returns the
>>> result of the anonymous function. It will be how we can pipe to anonymous
>>> functions in Elixir. It is named andThen in Scala and known as then in many
>>> promise libraries across ecosystems.
>>>
>>
>> I'm all for "tap"; I've been writing this function myself for a while
>> now, as easy as it is...  Not as sure about "then", though, I've been able
>> to get this to work without much problem, ala;
>>
>> iex(30)> foo = &(IO.puts(&1))
>> /1
>> iex(31)> "biff" |> (foo).()
>> biff
>> :ok
>> iex(32)> foo = &(&1 <> &2)
>> #Function<43.97283095/2 in :erl_eval.expr/5>
>> iex(33)> "biff" |> (foo).("bar")
>> "biffbar"
>>
>> The parens + .() combination seem to work just fine without any
>> additional work.  It's just the tap that gets messy if you want to do it
>> "inline" often:
>>
>> iex(34)> "biff" |> (fn x -> IO.puts("foo"); x; end).()
>> foo
>> "biff"
>>
>> ...so for that, I'd love 'tap()' so I don't forget to return the original
>> x.  :D
>>
>> ...Paul
>>
>>
>>
>>
>>
>>
>> --
>> 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/CAD3kWz-MCWvdbmTRe0qP5gz57%3Diy5fOcsmNLNT1cZRe5N_D9MA%40mail.gmail.com
>> 
>> .
>>
>
>
> --
> Austin Ziegler • halosta...@gmail.com • aus...@halostatue.ca
> http://www.halostatue.ca/ • http://twitter.com/halostatue
>
> --
> 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/CAJ4ekQtrodwKZsN0KE_omixojeuge1N2-3DDZjMbwvtNR_naSA%40mail.gmail.com
> 
> .
>

-- 
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/CABu8xFA%2BUen_jgrt96skqmv91JCdV3-1JiRNz1fyL_w6B0SuWQ%40mail.gmail.com.

Re: [elixir-core:9905] [Proposal] Inspection using a function

[Austin Ziegler]

Couldn’t this be a special case of `Kernel.apply/2`?

```elixir
@spec apply(fun | any, list(any) | fun) :: any
def apply(arg, fun) when is_function(fun, 1)) do
  fun.(arg)
end

def apply(fun, args) do
  :erlang.apply(fun, args)
end
```

This would read really well (IMO):

```elixir
[1, 2, 3, 5, 7]
|> apply((&1, fn x -> x * 2 end))
```

If it’s preferred not to make a special form of apply/2, then perhaps
`then_apply/2`?

-a

On Tue, Dec 29, 2020 at 1:11 PM Paul Clegg  wrote:

> On Tue, Dec 29, 2020 at 1:47 AM José Valim  wrote:
>
>> I propose we simply add two functions to Kernel: tap and then.
>>
>> 1. tap receives an anonymous function, invokes it, and returns the
>> argument. It can be found in Ruby and .NET Rx.
>>
>> 2. then receives an anonymous function, invokes it, and returns the
>> result of the anonymous function. It will be how we can pipe to anonymous
>> functions in Elixir. It is named andThen in Scala and known as then in many
>> promise libraries across ecosystems.
>>
>
> I'm all for "tap"; I've been writing this function myself for a while now,
> as easy as it is...  Not as sure about "then", though, I've been able to
> get this to work without much problem, ala;
>
> iex(30)> foo = &(IO.puts(&1))
> /1
> iex(31)> "biff" |> (foo).()
> biff
> :ok
> iex(32)> foo = &(&1 <> &2)
> #Function<43.97283095/2 in :erl_eval.expr/5>
> iex(33)> "biff" |> (foo).("bar")
> "biffbar"
>
> The parens + .() combination seem to work just fine without any additional
> work.  It's just the tap that gets messy if you want to do it "inline"
> often:
>
> iex(34)> "biff" |> (fn x -> IO.puts("foo"); x; end).()
> foo
> "biff"
>
> ...so for that, I'd love 'tap()' so I don't forget to return the original
> x.  :D
>
> ...Paul
>
>
>
>
>
>
> --
> 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/CAD3kWz-MCWvdbmTRe0qP5gz57%3Diy5fOcsmNLNT1cZRe5N_D9MA%40mail.gmail.com
> 
> .
>


-- 
Austin Ziegler • halosta...@gmail.com • aus...@halostatue.ca
http://www.halostatue.ca/ • http://twitter.com/halostatue

-- 
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/CAJ4ekQtrodwKZsN0KE_omixojeuge1N2-3DDZjMbwvtNR_naSA%40mail.gmail.com.

Re: [elixir-core:9903] [Proposal] Inspection using a function

[Louis Pilfold]

Heya

No polymorphic dispatch, so `result.then` as you've said. I think that is
also true of all the languages I've listed there, JavaScript's duck typing
aside.

Cheers,
Louis


On Tue, 29 Dec 2020, 13:42 José Valim,  wrote:

> Thanks Louis!
>
> Quick question: in Gleam, do you have polymorphic dispatch? Or do you have
> to do Result.then, Option.then, etc? If that's the case, then I think we
> could argue Kernel.then for identity monad and people can provide their own
> variants, as in Gleam, if they want to go down this route.
>
> I think then would only be a problem if we want to introduce a polymorphic
> monadic then in the future in Kernel.
>
> On Tue, Dec 29, 2020 at 2:26 PM Louis Pilfold  wrote:
>
>> Hello!
>>
>> As a data point JavaScript, TypeScript, Rust, Gleam, and
>> Rescript/ReasonML/Bucklescript all use then or and_then as the name for
>> that monadic function in their standard libraries.
>>
>> It seems to be a fairly common name these days so I'd probably favour
>> using a different one to avoid any confusion.
>>
>> Cheers,
>> Louis
>>
>>
>> On Tue, 29 Dec 2020, 12:30 José Valim,  wrote:
>>
>>> Hi Marten,
>>>
>>> Thanks for the feedback!
>>>
>>> The only reason I picked "then" is exactly because, if we ever introduce
>>> something akin to monads, I wouldn't pick "then" because I don't think it
>>> is clear enough on its monadic value. Also note that:
>>>
>>> 1. "andThen" in Scala is function composition and not bind. bind is
>>> flatMap (which I personally prefer)
>>>
>>> 2. "andThen" in Elm is indeed bind but it is not polymorphic, so you
>>> have Task.then, Maybe.then, etc. Therefore, even if we decide to go with
>>> "then" in the future, there is no naming conflict, unless we choose a
>>> polymorphic monad implementation. In fact, Kernel.then could then be used
>>> as an introduction to other monadic modules.
>>>
>>> So overall I think we are clear. This will be a bad choice only if all
>>> of the below are true:
>>>
>>> 1. We introduce monads
>>> 2. We pick "then" as the name for bind
>>> 3. Monads are polymorphic so we are accessing them via an imported
>>> "then" instead of qualified per module
>>>
>>> Happy holidays!
>>>
>>> On Tue, Dec 29, 2020 at 12:32 PM w...@resilia.nl  wrote:
>>>
 1. tap:
 I think adding tap will be very useful. I often am doing something like

 ```
 ast = quote do ... end
 IO.puts(Macro.to_string(ast)
 ast
 ```
 when debugging macros.
 Being able to change this to
 ```
 quote do ... end
 |> tap((Macro.to_string(&1))
 ```
 will be very welcome. :-)

 2. then:
 What José is referring to (when talking about `then` in relation to
 other languages where it is also used for e.g. promises) is the monadic
 'bind' operation. You might also know it as `>>=` as well as `andThen`:
 - `>>=` is the (non-descriptive) symbolic name that is used in Haskell,
 PureScript, and F# as well as many papers.
 - `bind` is the name given to above operation. It is also a
 frequently-used name whenever an operator is not used. In fact, `bind` is
 used in the Elixir ecosystem right now. One example that comes to mind is
 `StreamData`. There are probably others.
 - `andThen` sees usage in Scala, Elm and as already mentioned by José
 in many other contexts whether they deal with only promises, only parsers,
 only nondeterminism, etc... or monads in general.

 Even if it is more verbose, I think the name `andThen` is more
 descriptive than plain `then`. Therefore I prefer `andThen`.

 But rather I'd not add it at all:
 This proposed function will only be specialized to the "identity
 monad".
 The bind operation is the place where the unwrapping of the monadic
 value ought to happen. The identity monad is the one case where there is
 nothing to unwrap.
 `then/2` as described is a function that does nothing over using the
 function directly, except for "circumventing" the parsing precedence issue
 of `&` vs `|>` (if you need a refresher, find prior discussion about
 allowing anonymous functions and captures in pipes here
 ).
 `then/2` only exists for improved syntax, not for improved semantics.
 The fact that we are specializing it for this single syntactic purpose
 makes me consider that maybe we'd be better off choosing a different name
 that does not have this pre-existing meaning attached.

 Even if you're unfamiliar with monads or algebraic datatypes in
 general, you'll be able to understand the problem of restricting a general
 operation to one specific case.
 It's a bit like saying "Let's add a `Kernel.sum/1` that sums (only)
 lists of integers." It 'works' but what about lists of floats? sets of
 integers? lists of decimals? etc.
 There is a lot of missed potential.
 There is a high possibility that a decision 

Re: [elixir-core:9902] [Proposal] Inspection using a function

[José Valim]

Thanks Louis!

Quick question: in Gleam, do you have polymorphic dispatch? Or do you have
to do Result.then, Option.then, etc? If that's the case, then I think we
could argue Kernel.then for identity monad and people can provide their own
variants, as in Gleam, if they want to go down this route.

I think then would only be a problem if we want to introduce a polymorphic
monadic then in the future in Kernel.

On Tue, Dec 29, 2020 at 2:26 PM Louis Pilfold  wrote:

> Hello!
>
> As a data point JavaScript, TypeScript, Rust, Gleam, and
> Rescript/ReasonML/Bucklescript all use then or and_then as the name for
> that monadic function in their standard libraries.
>
> It seems to be a fairly common name these days so I'd probably favour
> using a different one to avoid any confusion.
>
> Cheers,
> Louis
>
>
> On Tue, 29 Dec 2020, 12:30 José Valim,  wrote:
>
>> Hi Marten,
>>
>> Thanks for the feedback!
>>
>> The only reason I picked "then" is exactly because, if we ever introduce
>> something akin to monads, I wouldn't pick "then" because I don't think it
>> is clear enough on its monadic value. Also note that:
>>
>> 1. "andThen" in Scala is function composition and not bind. bind is
>> flatMap (which I personally prefer)
>>
>> 2. "andThen" in Elm is indeed bind but it is not polymorphic, so you have
>> Task.then, Maybe.then, etc. Therefore, even if we decide to go with "then"
>> in the future, there is no naming conflict, unless we choose a polymorphic
>> monad implementation. In fact, Kernel.then could then be used as an
>> introduction to other monadic modules.
>>
>> So overall I think we are clear. This will be a bad choice only if all of
>> the below are true:
>>
>> 1. We introduce monads
>> 2. We pick "then" as the name for bind
>> 3. Monads are polymorphic so we are accessing them via an imported "then"
>> instead of qualified per module
>>
>> Happy holidays!
>>
>> On Tue, Dec 29, 2020 at 12:32 PM w...@resilia.nl  wrote:
>>
>>> 1. tap:
>>> I think adding tap will be very useful. I often am doing something like
>>>
>>> ```
>>> ast = quote do ... end
>>> IO.puts(Macro.to_string(ast)
>>> ast
>>> ```
>>> when debugging macros.
>>> Being able to change this to
>>> ```
>>> quote do ... end
>>> |> tap((Macro.to_string(&1))
>>> ```
>>> will be very welcome. :-)
>>>
>>> 2. then:
>>> What José is referring to (when talking about `then` in relation to
>>> other languages where it is also used for e.g. promises) is the monadic
>>> 'bind' operation. You might also know it as `>>=` as well as `andThen`:
>>> - `>>=` is the (non-descriptive) symbolic name that is used in Haskell,
>>> PureScript, and F# as well as many papers.
>>> - `bind` is the name given to above operation. It is also a
>>> frequently-used name whenever an operator is not used. In fact, `bind` is
>>> used in the Elixir ecosystem right now. One example that comes to mind is
>>> `StreamData`. There are probably others.
>>> - `andThen` sees usage in Scala, Elm and as already mentioned by José in
>>> many other contexts whether they deal with only promises, only parsers,
>>> only nondeterminism, etc... or monads in general.
>>>
>>> Even if it is more verbose, I think the name `andThen` is more
>>> descriptive than plain `then`. Therefore I prefer `andThen`.
>>>
>>> But rather I'd not add it at all:
>>> This proposed function will only be specialized to the "identity monad".
>>> The bind operation is the place where the unwrapping of the monadic
>>> value ought to happen. The identity monad is the one case where there is
>>> nothing to unwrap.
>>> `then/2` as described is a function that does nothing over using the
>>> function directly, except for "circumventing" the parsing precedence issue
>>> of `&` vs `|>` (if you need a refresher, find prior discussion about
>>> allowing anonymous functions and captures in pipes here
>>> ).
>>> `then/2` only exists for improved syntax, not for improved semantics.
>>> The fact that we are specializing it for this single syntactic purpose
>>> makes me consider that maybe we'd be better off choosing a different name
>>> that does not have this pre-existing meaning attached.
>>>
>>> Even if you're unfamiliar with monads or algebraic datatypes in general,
>>> you'll be able to understand the problem of restricting a general operation
>>> to one specific case.
>>> It's a bit like saying "Let's add a `Kernel.sum/1` that sums (only)
>>> lists of integers." It 'works' but what about lists of floats? sets of
>>> integers? lists of decimals? etc.
>>> There is a lot of missed potential.
>>> There is a high possibility that a decision like this cannot be extended
>>> or altered later on in a backwards-compatible way.
>>> There is a high likelihood of people trying to use it in contexts where
>>> it cannot be used and being confused by it or introducing bugs.
>>>
>>>
>>> So I'd seriously consider using a different naming scheme for `then`.
>>> I'd prefer a simpler name with less of 

Re: [elixir-core:9901] [Proposal] Inspection using a function

[Louis Pilfold]

Hello!

As a data point JavaScript, TypeScript, Rust, Gleam, and
Rescript/ReasonML/Bucklescript all use then or and_then as the name for
that monadic function in their standard libraries.

It seems to be a fairly common name these days so I'd probably favour using
a different one to avoid any confusion.

Cheers,
Louis


On Tue, 29 Dec 2020, 12:30 José Valim,  wrote:

> Hi Marten,
>
> Thanks for the feedback!
>
> The only reason I picked "then" is exactly because, if we ever introduce
> something akin to monads, I wouldn't pick "then" because I don't think it
> is clear enough on its monadic value. Also note that:
>
> 1. "andThen" in Scala is function composition and not bind. bind is
> flatMap (which I personally prefer)
>
> 2. "andThen" in Elm is indeed bind but it is not polymorphic, so you have
> Task.then, Maybe.then, etc. Therefore, even if we decide to go with "then"
> in the future, there is no naming conflict, unless we choose a polymorphic
> monad implementation. In fact, Kernel.then could then be used as an
> introduction to other monadic modules.
>
> So overall I think we are clear. This will be a bad choice only if all of
> the below are true:
>
> 1. We introduce monads
> 2. We pick "then" as the name for bind
> 3. Monads are polymorphic so we are accessing them via an imported "then"
> instead of qualified per module
>
> Happy holidays!
>
> On Tue, Dec 29, 2020 at 12:32 PM w...@resilia.nl  wrote:
>
>> 1. tap:
>> I think adding tap will be very useful. I often am doing something like
>>
>> ```
>> ast = quote do ... end
>> IO.puts(Macro.to_string(ast)
>> ast
>> ```
>> when debugging macros.
>> Being able to change this to
>> ```
>> quote do ... end
>> |> tap((Macro.to_string(&1))
>> ```
>> will be very welcome. :-)
>>
>> 2. then:
>> What José is referring to (when talking about `then` in relation to other
>> languages where it is also used for e.g. promises) is the monadic 'bind'
>> operation. You might also know it as `>>=` as well as `andThen`:
>> - `>>=` is the (non-descriptive) symbolic name that is used in Haskell,
>> PureScript, and F# as well as many papers.
>> - `bind` is the name given to above operation. It is also a
>> frequently-used name whenever an operator is not used. In fact, `bind` is
>> used in the Elixir ecosystem right now. One example that comes to mind is
>> `StreamData`. There are probably others.
>> - `andThen` sees usage in Scala, Elm and as already mentioned by José in
>> many other contexts whether they deal with only promises, only parsers,
>> only nondeterminism, etc... or monads in general.
>>
>> Even if it is more verbose, I think the name `andThen` is more
>> descriptive than plain `then`. Therefore I prefer `andThen`.
>>
>> But rather I'd not add it at all:
>> This proposed function will only be specialized to the "identity monad".
>> The bind operation is the place where the unwrapping of the monadic value
>> ought to happen. The identity monad is the one case where there is nothing
>> to unwrap.
>> `then/2` as described is a function that does nothing over using the
>> function directly, except for "circumventing" the parsing precedence issue
>> of `&` vs `|>` (if you need a refresher, find prior discussion about
>> allowing anonymous functions and captures in pipes here
>> ).
>> `then/2` only exists for improved syntax, not for improved semantics.
>> The fact that we are specializing it for this single syntactic purpose
>> makes me consider that maybe we'd be better off choosing a different name
>> that does not have this pre-existing meaning attached.
>>
>> Even if you're unfamiliar with monads or algebraic datatypes in general,
>> you'll be able to understand the problem of restricting a general operation
>> to one specific case.
>> It's a bit like saying "Let's add a `Kernel.sum/1` that sums (only) lists
>> of integers." It 'works' but what about lists of floats? sets of integers?
>> lists of decimals? etc.
>> There is a lot of missed potential.
>> There is a high possibility that a decision like this cannot be extended
>> or altered later on in a backwards-compatible way.
>> There is a high likelihood of people trying to use it in contexts where
>> it cannot be used and being confused by it or introducing bugs.
>>
>>
>> So I'd seriously consider using a different naming scheme for `then`.
>> I'd prefer a simpler name with less of a pre-existing meaning.
>> Possibly just `fun/2`.
>>
>>
>> Happy holidays! :-)
>>
>> ~Marten/Qqwy
>> On Tuesday, December 29, 2020 at 10:47:17 AM UTC+1 José Valim wrote:
>>
>>> I propose we simply add two functions to Kernel: tap and then.
>>>
>>> 1. tap receives an anonymous function, invokes it, and returns the
>>> argument. It can be found in Ruby and .NET Rx.
>>>
>>> 2. then receives an anonymous function, invokes it, and returns the
>>> result of the anonymous function. It will be how we can pipe to anonymous
>>> functions in Elixir. It is named andThen in Scala and known 

Re: [elixir-core:9900] [Proposal] Inspection using a function

[José Valim]

Hi Marten,

Thanks for the feedback!

The only reason I picked "then" is exactly because, if we ever introduce
something akin to monads, I wouldn't pick "then" because I don't think it
is clear enough on its monadic value. Also note that:

1. "andThen" in Scala is function composition and not bind. bind is flatMap
(which I personally prefer)

2. "andThen" in Elm is indeed bind but it is not polymorphic, so you have
Task.then, Maybe.then, etc. Therefore, even if we decide to go with "then"
in the future, there is no naming conflict, unless we choose a polymorphic
monad implementation. In fact, Kernel.then could then be used as an
introduction to other monadic modules.

So overall I think we are clear. This will be a bad choice only if all of
the below are true:

1. We introduce monads
2. We pick "then" as the name for bind
3. Monads are polymorphic so we are accessing them via an imported "then"
instead of qualified per module

Happy holidays!

On Tue, Dec 29, 2020 at 12:32 PM w...@resilia.nl  wrote:

> 1. tap:
> I think adding tap will be very useful. I often am doing something like
>
> ```
> ast = quote do ... end
> IO.puts(Macro.to_string(ast)
> ast
> ```
> when debugging macros.
> Being able to change this to
> ```
> quote do ... end
> |> tap((Macro.to_string(&1))
> ```
> will be very welcome. :-)
>
> 2. then:
> What José is referring to (when talking about `then` in relation to other
> languages where it is also used for e.g. promises) is the monadic 'bind'
> operation. You might also know it as `>>=` as well as `andThen`:
> - `>>=` is the (non-descriptive) symbolic name that is used in Haskell,
> PureScript, and F# as well as many papers.
> - `bind` is the name given to above operation. It is also a
> frequently-used name whenever an operator is not used. In fact, `bind` is
> used in the Elixir ecosystem right now. One example that comes to mind is
> `StreamData`. There are probably others.
> - `andThen` sees usage in Scala, Elm and as already mentioned by José in
> many other contexts whether they deal with only promises, only parsers,
> only nondeterminism, etc... or monads in general.
>
> Even if it is more verbose, I think the name `andThen` is more descriptive
> than plain `then`. Therefore I prefer `andThen`.
>
> But rather I'd not add it at all:
> This proposed function will only be specialized to the "identity monad".
> The bind operation is the place where the unwrapping of the monadic value
> ought to happen. The identity monad is the one case where there is nothing
> to unwrap.
> `then/2` as described is a function that does nothing over using the
> function directly, except for "circumventing" the parsing precedence issue
> of `&` vs `|>` (if you need a refresher, find prior discussion about
> allowing anonymous functions and captures in pipes here
> ).
> `then/2` only exists for improved syntax, not for improved semantics.
> The fact that we are specializing it for this single syntactic purpose
> makes me consider that maybe we'd be better off choosing a different name
> that does not have this pre-existing meaning attached.
>
> Even if you're unfamiliar with monads or algebraic datatypes in general,
> you'll be able to understand the problem of restricting a general operation
> to one specific case.
> It's a bit like saying "Let's add a `Kernel.sum/1` that sums (only) lists
> of integers." It 'works' but what about lists of floats? sets of integers?
> lists of decimals? etc.
> There is a lot of missed potential.
> There is a high possibility that a decision like this cannot be extended
> or altered later on in a backwards-compatible way.
> There is a high likelihood of people trying to use it in contexts where it
> cannot be used and being confused by it or introducing bugs.
>
>
> So I'd seriously consider using a different naming scheme for `then`.
> I'd prefer a simpler name with less of a pre-existing meaning.
> Possibly just `fun/2`.
>
>
> Happy holidays! :-)
>
> ~Marten/Qqwy
> On Tuesday, December 29, 2020 at 10:47:17 AM UTC+1 José Valim wrote:
>
>> I propose we simply add two functions to Kernel: tap and then.
>>
>> 1. tap receives an anonymous function, invokes it, and returns the
>> argument. It can be found in Ruby and .NET Rx.
>>
>> 2. then receives an anonymous function, invokes it, and returns the
>> result of the anonymous function. It will be how we can pipe to anonymous
>> functions in Elixir. It is named andThen in Scala and known as then in many
>> promise libraries across ecosystems.
>>
>> I think this can improve the piping experience considerably while keeping
>> things functional.
>>
>> On Tue, Dec 29, 2020 at 4:20 AM Zach Daniel 
>> wrote:
>>
>>> That takes it a bit too far for my taste. That part can easily be done
>>> by passing an anonymous function and calling a series of functions.
>>>
>>> On Mon, Dec 28, 2020 at 9:55 PM Kevin Johnson 
>>> wrote:
>>>
  I would prefer to introduce a general approach to 

Re: [elixir-core:9900] [Proposal] Inspection using a function

[w...@resilia.nl]

1. tap: 
I think adding tap will be very useful. I often am doing something like

```
ast = quote do ... end
IO.puts(Macro.to_string(ast)
ast
```
when debugging macros.
Being able to change this to 
```
quote do ... end
|> tap((Macro.to_string(&1))
```
will be very welcome. :-)

2. then: 
What José is referring to (when talking about `then` in relation to other 
languages where it is also used for e.g. promises) is the monadic 'bind' 
operation. You might also know it as `>>=` as well as `andThen`:
- `>>=` is the (non-descriptive) symbolic name that is used in Haskell, 
PureScript, and F# as well as many papers.
- `bind` is the name given to above operation. It is also a frequently-used 
name whenever an operator is not used. In fact, `bind` is used in the 
Elixir ecosystem right now. One example that comes to mind is `StreamData`. 
There are probably others.
- `andThen` sees usage in Scala, Elm and as already mentioned by José in 
many other contexts whether they deal with only promises, only parsers, 
only nondeterminism, etc... or monads in general.

Even if it is more verbose, I think the name `andThen` is more descriptive 
than plain `then`. Therefore I prefer `andThen`.

But rather I'd not add it at all:
This proposed function will only be specialized to the "identity monad". 
The bind operation is the place where the unwrapping of the monadic value 
ought to happen. The identity monad is the one case where there is nothing 
to unwrap.
`then/2` as described is a function that does nothing over using the 
function directly, except for "circumventing" the parsing precedence issue 
of `&` vs `|>` (if you need a refresher, find prior discussion about 
allowing anonymous functions and captures in pipes here 
).
`then/2` only exists for improved syntax, not for improved semantics.
The fact that we are specializing it for this single syntactic purpose 
makes me consider that maybe we'd be better off choosing a different name 
that does not have this pre-existing meaning attached.

Even if you're unfamiliar with monads or algebraic datatypes in general, 
you'll be able to understand the problem of restricting a general operation 
to one specific case.
It's a bit like saying "Let's add a `Kernel.sum/1` that sums (only) lists 
of integers." It 'works' but what about lists of floats? sets of integers? 
lists of decimals? etc.
There is a lot of missed potential. 
There is a high possibility that a decision like this cannot be extended or 
altered later on in a backwards-compatible way.
There is a high likelihood of people trying to use it in contexts where it 
cannot be used and being confused by it or introducing bugs.


So I'd seriously consider using a different naming scheme for `then`.
I'd prefer a simpler name with less of a pre-existing meaning. 
Possibly just `fun/2`.


Happy holidays! :-)

~Marten/Qqwy
On Tuesday, December 29, 2020 at 10:47:17 AM UTC+1 José Valim wrote:

> I propose we simply add two functions to Kernel: tap and then.
>
> 1. tap receives an anonymous function, invokes it, and returns the 
> argument. It can be found in Ruby and .NET Rx.
>
> 2. then receives an anonymous function, invokes it, and returns the result 
> of the anonymous function. It will be how we can pipe to anonymous 
> functions in Elixir. It is named andThen in Scala and known as then in many 
> promise libraries across ecosystems.
>
> I think this can improve the piping experience considerably while keeping 
> things functional.
>
> On Tue, Dec 29, 2020 at 4:20 AM Zach Daniel  wrote:
>
>> That takes it a bit too far for my taste. That part can easily be done by 
>> passing an anonymous function and calling a series of functions.
>>
>> On Mon, Dec 28, 2020 at 9:55 PM Kevin Johnson  
>> wrote:
>>
>>>  I would prefer to introduce a general approach to this, such that:
>>>
>>> How general do you want it to be? 
>>> Is this to cater solely for conveniently inlining side-effects; e.g. 
>>> write to log, network, console or are there other use-cases that you 
>>> envision?
>>> Do you envision inlining multiple side-effects:
>>> `|> tap(/1, [/1, ("foo", 0,  
>>> !(&1)), ...])` to facilitate some fan-out strategy with 
>>> perhaps some desired options?
>>>
>>> -- 
>>> 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-co...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/elixir-lang-core/CAAkfbUr9Ud1iKo0X1bCu1tcL5V1M-Z0um6-8JyFA0kOeh7fUmA%40mail.gmail.com
>>>  
>>> 
>>> .
>>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "elixir-lang-core" group.
>> To unsubscribe from this 

Re: [elixir-core:9898] [Proposal] Inspection using a function

[José Valim]

I propose we simply add two functions to Kernel: tap and then.

1. tap receives an anonymous function, invokes it, and returns the
argument. It can be found in Ruby and .NET Rx.

2. then receives an anonymous function, invokes it, and returns the result
of the anonymous function. It will be how we can pipe to anonymous
functions in Elixir. It is named andThen in Scala and known as then in many
promise libraries across ecosystems.

I think this can improve the piping experience considerably while keeping
things functional.

On Tue, Dec 29, 2020 at 4:20 AM Zach Daniel 
wrote:

> That takes it a bit too far for my taste. That part can easily be done by
> passing an anonymous function and calling a series of functions.
>
> On Mon, Dec 28, 2020 at 9:55 PM Kevin Johnson 
> wrote:
>
>>  I would prefer to introduce a general approach to this, such that:
>>
>> How general do you want it to be?
>> Is this to cater solely for conveniently inlining side-effects; e.g.
>> write to log, network, console or are there other use-cases that you
>> envision?
>> Do you envision inlining multiple side-effects:
>> `|> tap(/1, [/1, ("foo", 0,
>> !(&1)), ...])` to facilitate some fan-out strategy with
>> perhaps some desired options?
>>
>> --
>> 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/CAAkfbUr9Ud1iKo0X1bCu1tcL5V1M-Z0um6-8JyFA0kOeh7fUmA%40mail.gmail.com
>> 
>> .
>>
> --
> 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/CAK-yb0CYHpkZ5-qhM3CMx-VcUnkk16SC55_hOK-b%3DSPg%3DFzqXA%40mail.gmail.com
> 
> .
>

-- 
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/CAGnRm4JQQ3ir22nTr_pA6mQw694u57F%2Bx-__zv2qB7r5sBGG8w%40mail.gmail.com.