José, you are so gracious in dealing with the Elixir community. I appreciate
that very much. It has inspired me to work to be more gracious in my own life.
-Greg Vaughn
> On Apr 16, 2019, at 7:18 PM, José Valim <jose.va...@plataformatec.com.br>
> wrote:
>
> Hi Tom,
>
> You probably meant it as a joke but just keep in mind jokes do not translate
> well to text.
>
> Evaluating the language proposals is often tiresome and it is work that is
> not always appreciated, so it is probably best for everyone to stay in topic.
>
> Thanks,
>
> On Wed, Apr 17, 2019 at 02:03 <t...@scalpel.com> wrote:
> Ok we'll paint the bikeshed green.
>
> On Tuesday, April 16, 2019 at 7:36:51 PM UTC-4, José Valim wrote:
> They probably shouldn't been lists in the first place but that ship sailed a
> long time ago.
>
> If you need to work with them dynamically, the API is there. It just
> shouldn't be encouraged and adding functions such as Tuple.wrap could end-up
> having the opposite effect: encouraging more dynamic work making everyone's
> life harder, rather than easier.
>
>
> José Valim
> www.plataformatec.com.br
> Skype: jv.ptec
> Founder and Director of R&D
>
>
> On Wed, Apr 17, 2019 at 1:32 AM <t...@scalpel.com> wrote:
> I agree that they are rarely used dynamically, but when they are they can be
> quite the pain to work with.
>
> For example, if you are doing any work with ASN.1 dynamic tuples are
> everywhere. Any advanced work in cryptography or telecom becomes harder to
> work with than I would like it to be.
>
> On Tuesday, April 16, 2019 at 7:24:15 PM UTC-4, José Valim wrote:
> Well, the difference is really in their usage. Tuples are rarely used
> dynamically, you usually want to see tuples as literals in your code. The
> Tuple docs also mention it:
>
> > The functions in this module that add and remove elements from tuples are
> > rarely used in practice, as they typically imply tuples are being used as
> > collections. To append to a tuple, it is preferable to use pattern matching
>
>
> José Valim
> www.plataformatec.com.br
> Skype: jv.ptec
> Founder and Director of R&D
>
>
> On Wed, Apr 17, 2019 at 1:20 AM <t...@scalpel.com> wrote:
> I see your point.
>
> I was thinking more along the lines of consistency in the API design. If you
> can wrap an item in a list why can't you wrap it in a tuple? If you could
> wrap things in tuples then you could insert a value at the front of said
> tuple.This is more of an exercise in "you could" rather than "you should".
>
> On Tuesday, April 16, 2019 at 7:07:33 PM UTC-4, José Valim wrote:
> If the choice is between:
>
> value |> Tuple.wrap() |> Tuple.insert_at(0, :ok)
>
> and
>
> {:ok, value}
>
> I believe we should choose the second every time.
>
> If the choice is between:
>
> value
> |> very()
> |> long()
> |> pipeline()
> |> Tuple.wrap()
> |> Tuple.insert_at(0, :ok)
>
> and:
>
> value
> |> very()
> |> long()
> |> pipeline()
> |> OkError.ok()
>
> and:
>
> var =
> value
> |> very()
> |> long()
> |> pipeline()
>
> {:ok, var}
>
> I don't see any reason why we should ever do the first one.
>
> So I really don't see which problem Tuple.wrap is supposed to solve.
>
> José Valim
> www.plataformatec.com.br
> Skype: jv.ptec
> Founder and Director of R&D
>
>
> On Wed, Apr 17, 2019 at 12:58 AM <t...@scalpel.com> wrote:
> I understand that this is possible, and thank you for the suggestion but I'm
> not the biggest fan of anonymous functions.
>
> When I go back and read programs written this way I can't tell if I wrote the
> code or a cat walked on my keyboard.
>
> On Tuesday, April 16, 2019 at 6:54:16 PM UTC-4, Ryan Winchester wrote:
> Yeah, sorry
>
> value |> (&{:ok, &1}).()
>
> On April 16, 2019 at 3:51:28 PM, Ryan Winchester (he...@ryanwinchester.ca )
> wrote:
>
>> value |> (&{&1}).() |> Tuple.insert_at(0, :ok)
>>
>> On April 16, 2019 at 3:47:58 PM, t...@scalpel.com (t...@scalpel.com ) wrote:
>>
>>> Fair enough, I know when to give up on a losing battle.
>>>
>>> Would you consider an alternative like Tuple.wrap/1. It would work exactly
>>> like List.wrap/1 but doesn't carry the baggage that "error" and "ok" would
>>> have. This way I could still accomplish the goal of keeping pipe chains
>>> clean with something like.
>>>
>>> value |> Tuple.wrap() |> Tuple.insert_at(0, :ok)
>>>
>>> Which is a bit wordier but functionally equivalent to the original
>>> proposal.
>>>
>>> On Tuesday, April 16, 2019 at 6:04:55 PM UTC-4, José Valim wrote:
>>> Hi Tom,
>>>
>>> You don't have to buy the arguments, we can agree to disagree, but they are
>>> still the reason for not adding such functions to Elixir. :)
>>>
>>> I also agree with is_even and is_odd being similar convenience functions
>>> but they do have a rationale. They were added before defguard existed. At
>>> the time, writing guards was a bit more bureaucratic. But if is_odd/is_even
>>> were proposed today, they would most likely have been rejected as well.
>>>
>>> Elixir already has a perfectly fine syntax via curly brackets for creating
>>> ok and error tuples, that also works on matching, so my recommendation is
>>> still to build an extra vocabulary in your app or as a separate library.
>>>
>>> José Valim
>>> www.plataformatec.com.br
>>> Skype: jv.ptec
>>> Founder and Director of R&D
>>>
>>>
>>> On Tue, Apr 16, 2019 at 11:46 PM <t...@scalpel.com > wrote:
>>> I disagree that this should be a library. (I've already done this in my app
>>> and would be fine extracting it into one though) I don't buy the slippery
>>> slope argument. The functions are very simple to create and maintain, and
>>> it's not like the Tuple module is overflowing with complexity. We have
>>> things like 'is_even' and 'is_odd' because they are common to work with.
>>> :ok and :error are insanely common in elixir codebases. Why not add
>>> convenience methods?
>>>
>>> On Tuesday, April 16, 2019 at 5:22:38 PM UTC-4, José Valim wrote:
>>> Hi Tom, thanks for the proposal.
>>>
>>> As OvermindDL1 already hinted, this can lead to a slippery slope where we
>>> need to add bang variants, question mark variants, ok/1/2/3/4 to deal with
>>> arities and so on. I would suggest building this vocabulary as necessary in
>>> your applications or, if you want to share it with the world, it could be a
>>> nice library. Hint: the package ok_error seems to be available. :)
>>>
>>> José Valim
>>> www.plataformatec.com.br
>>> Skype: jv.ptec
>>> Founder and Director of R&D
>>>
>>>
>>> On Tue, Apr 16, 2019 at 11:12 PM OvermindDL1 <overm...@gmail.com > wrote:
>>> On Tuesday, April 16, 2019 at 3:04:13 PM UTC-6, t...@scalpel.com wrote:
>>> It is often the case that you want to wrap the result of an operation in an
>>> ":ok" or ":error" Tuple. We should add convenience wrapper functions since
>>> this is so common and it cleans up otherwise ugly code.
>>>
>>> def ok(value), do: {:ok, value}
>>> def error(value), do: {:error, value}
>>>
>>> This could be quite useful! On the other side it would be useful to add
>>> functions like these as well:
>>>
>>> def ok!({:ok, value}), do: value
>>>
>>> def ok?({:ok, _value}), do: true
>>> def ok?(_), do: false
>>>
>>> And so forth for error as well. They are not really useful on their own
>>> because matching is better, but for use in pipes that would be quite useful
>>> (right now I use the exceptional library, which does similar things and
>>> more).
>>> --
>>> 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-l...@googlegroups.com .
>>> To view this discussion on the web visit https://groups.google.com/d/
>>>
>>> msgid/elixir-lang-core/ 30614530-7e33-4cb8-bffb-
>>> 63c18248d340%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-l...@ googlegroups.com .
>>> To view this discussion on the web visit https://groups.google.com/d/
>>> msgid/elixir-lang-core/ 0314757d-eff2-4b23-8130-
>>> a19ee921b254%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-l...@googlegroups.com .
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/elixir-lang-core/2e7204c7-6d06-49f9-8edc-7c631f75063a%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-l...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/elixir-lang-core/721abcf1-0cfd-4824-b54a-ff2aa22487f3%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-l...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/elixir-lang-core/5607dc54-2c5d-452c-a5a5-fa6ec03864c3%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-l...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/elixir-lang-core/50776062-e75d-4f31-8266-2b633e78bf89%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/f1c5a753-6964-466b-aabb-5f8cdb7c7ec0%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
> --
>
>
> José Valim
> www.plataformatec.com.br
> Skype: jv.ptec
> Founder and Director of R&D
>
> --
> 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/CAGnRm4%2Bmvy5%3DC3cgwMPquPsrM32JjNdn0mxdsvOthLt0eXU4yg%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/0482DC4E-5021-44C1-846C-ABABF265BAD3%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
