Hi Dave!
I think Plug is a misleading example because Plug should actually be
implemented with `with`:
with %Plug.Conn{halt: false} = conn <- plug1(conn, opts),
%Plug.Conn{halt: false} = conn <- plug2(conn, opts),
do: conn
That's because a Plug pipeline can abort at any moment. In this sense, we
already have a construct that captures Plug needs. Other than that, Plug is
compile-time exactly to provide compile-time initialization of (module)
plugs to avoid runtime work.
Of course, one could argue that a pipeline should then be further decoupled
into: functions, flow, and execution. This way, we could customize how a
pipeline connects its functions, but at this point we are into monad
territory. :)
The other thing is that the original code can be written as this:
& &1 |> downcase |> split("_") |> map(&capitalize/1) |> join
Which is only 5 characters longer. If the goal is to experiment and measure
adoption, I would say we have a construct close enough for devs to explore,
and then discuss streamlining it if it is common enough (like |> (expr).()
became then/2).
Finally, I want to note that function composition *may* be expensive.
Recent compilers optimizations certainly removed part of the cost, my gut
feeling tells me the performance difference likely won't matter, but in
terms of completeness, I would say it may be worth measuring in actual code.
On Wed, Oct 26, 2022 at 5:49 PM pragdave <pragd...@gmail.com> wrote:
>
>
> On Tuesday, October 25, 2022 at 9:56:14 PM UTC-5 dorga...@gmail.com wrote:
>
>> For the plugs example, how is it better than the alternative that exists
>> today?
>>
>
> Because it is written without the magic. The way Plug currently works is
> needlessly nonfunctional and opaque. With this small change, we could turn
> it from "some compile time magic" into "just more code.
>
> Why write `Plug :accept, ["html"]` when you can just write
> `accept("html")` as part of a standard Elixir pipeline?
>
>
> Function composition is a key part of FP.
>>>
>> Agreed, but functional composition(h = g ∘ f) is not the way the
>> overwhelming majority of elixir code is written.
>>
>
> Of course, because Elixir doesn't support it. I'm suggesting a simple,
> non-breaking and noninvasice change that would add support. Then, in a
> year's time, we can see if there's any adoption.
>
>
> --
> 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/4debfa0c-7489-4e70-8025-be746a40d63an%40googlegroups.com
> <https://groups.google.com/d/msgid/elixir-lang-core/4debfa0c-7489-4e70-8025-be746a40d63an%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/CAGnRm4LzQNi_YOP9fyojE%3DZxrNBzXWA%3Dk58XTak2w9KdfQB6bQ%40mail.gmail.com.
