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 <[email protected] <javascript:>> 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 <[email protected]> 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 <[email protected]> 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 ( >>>>>>> [email protected] ) wrote: >>>>>>> >>>>>>> value |> (&{&1}).() |> Tuple.insert_at(0, :ok) >>>>>>> >>>>>>> On April 16, 2019 at 3:47:58 PM, [email protected] ([email protected] >>>>>>> ) 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 <[email protected] > 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 <[email protected] >>>>>>>>>> > wrote: >>>>>>>>>> >>>>>>>>>>> On Tuesday, April 16, 2019 at 3:04:13 PM UTC-6, [email protected] >>>>>>>>>>> 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 [email protected] . >>>>>>>>>>> To view this discussion on the web visit >>>>>>>>>>> https://groups.google.com/d/ >>>>>>>>>>> msgid/elixir-lang-core/ 30614530-7e33-4cb8-bffb- >>>>>>>>>>> 63c18248d340%40googlegroups. com >>>>>>>>>>> <https://groups.google.com/d/msgid/elixir-lang-core/30614530-7e33-4cb8-bffb-63c18248d340%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>>>>>>> >>>>>>>>>>> . >>>>>>>>>>> For more options, visit https://groups.google.com/d/ optout >>>>>>>>>>> <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 >>>>>>>>> <https://groups.google.com/d/msgid/elixir-lang-core/0314757d-eff2-4b23-8130-a19ee921b254%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>>>>> >>>>>>>>> . >>>>>>>>> For more options, visit https://groups.google.com/d/ optout >>>>>>>>> <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 [email protected] . >>>>>>> To view this discussion on the web visit >>>>>>> https://groups.google.com/d/msgid/elixir-lang-core/2e7204c7-6d06-49f9-8edc-7c631f75063a%40googlegroups.com >>>>>>> >>>>>>> <https://groups.google.com/d/msgid/elixir-lang-core/2e7204c7-6d06-49f9-8edc-7c631f75063a%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>>> >>>>>>> . >>>>>>> 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 [email protected]. >>>>>> To view this discussion on the web visit >>>>>> https://groups.google.com/d/msgid/elixir-lang-core/721abcf1-0cfd-4824-b54a-ff2aa22487f3%40googlegroups.com >>>>>> >>>>>> <https://groups.google.com/d/msgid/elixir-lang-core/721abcf1-0cfd-4824-b54a-ff2aa22487f3%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>> . >>>>>> 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 [email protected]. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/elixir-lang-core/5607dc54-2c5d-452c-a5a5-fa6ec03864c3%40googlegroups.com >>>> >>>> <https://groups.google.com/d/msgid/elixir-lang-core/5607dc54-2c5d-452c-a5a5-fa6ec03864c3%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> 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 [email protected] <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/elixir-lang-core/50776062-e75d-4f31-8266-2b633e78bf89%40googlegroups.com >> >> <https://groups.google.com/d/msgid/elixir-lang-core/50776062-e75d-4f31-8266-2b633e78bf89%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> 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 [email protected]. 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.
