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, <jose.va...@dashbit.co> 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 <lo...@lpil.uk> 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, <jose.va...@dashbit.co> 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 <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(&IO.puts(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 >>>> <https://github.com/elixir-lang/elixir/issues/10154>). >>>> `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 <zachary....@gmail.com> >>>>> 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 <johnson7...@gmail.com> >>>>>> 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(&Map.keys/1, [&IO.inspect/1, &KafkaEx.produce("foo", 0, >>>>>>> &Poison.encode!(&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 >>>>>>> <https://groups.google.com/d/msgid/elixir-lang-core/CAAkfbUr9Ud1iKo0X1bCu1tcL5V1M-Z0um6-8JyFA0kOeh7fUmA%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>>> . >>>>>>> >>>>>> -- >>>>>> 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/CAK-yb0CYHpkZ5-qhM3CMx-VcUnkk16SC55_hOK-b%3DSPg%3DFzqXA%40mail.gmail.com >>>>>> <https://groups.google.com/d/msgid/elixir-lang-core/CAK-yb0CYHpkZ5-qhM3CMx-VcUnkk16SC55_hOK-b%3DSPg%3DFzqXA%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>> . >>>>>> >>>>> -- >>>> 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/4375daa4-9e65-4f4c-95a1-2d9147718d48n%40googlegroups.com >>>> <https://groups.google.com/d/msgid/elixir-lang-core/4375daa4-9e65-4f4c-95a1-2d9147718d48n%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- >>> 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/CAGnRm4Jo-z4oGUimj0GZTL1HD8sFi91aWNTSvkLLkAiB63egpg%40mail.gmail.com >>> <https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4Jo-z4oGUimj0GZTL1HD8sFi91aWNTSvkLLkAiB63egpg%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- >> 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/CABu8xFAuRPQ1hgoRJ6UFn5YWd%2BJ-%3Da812LJ9NTy3SfLr%3D5eTzA%40mail.gmail.com >> <https://groups.google.com/d/msgid/elixir-lang-core/CABu8xFAuRPQ1hgoRJ6UFn5YWd%2BJ-%3Da812LJ9NTy3SfLr%3D5eTzA%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- > 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/CAGnRm4L9X8GGoj1-M9_SQ2F2-VDRAFpoPPRXYbfnmoz9pJR3GA%40mail.gmail.com > <https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4L9X8GGoj1-M9_SQ2F2-VDRAFpoPPRXYbfnmoz9pJR3GA%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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/CABu8xFBm6F%2BD0n2GPMfboas55_6Pz362%2BHgbKMr%3DiW8aNtWBdA%40mail.gmail.com.
