For the plugs example, how is it better than the alternative that exists
today?
browser_pipeline =
fn conn -> conn |> accepts("html") |> fetch_session() |> fetch_flash() |>
protect_from_forgery() end
This would allow pipelines to be composed. Think Plug, but functional.
>
I think this is a preculiarity of how the plug/phoenix DSL works and not an
issue with Elixir itself. Assuming there is a problem with the way
pipelines are defined, wouldn't that call for a different design at the
library level instead of a change in Elixir itself?
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, as it's more "idiomatic"
to write programs that operate on a data structure and not by composing
functions together. We say that two functions compose when the input of one
matches the input of the other and we fully leverage that to write
pipelines, but we don't write programs by defining more functions via
functional composition.
El mar, 25 oct 2022 a las 21:46, pragdave (<pragd...@gmail.com>) escribió:
> I know this has been discussed before, in different forms, but I thought
> I’d just have another go following my recent earth-shattering PR :)
>
> I’d like to propose a new unary operator, &>. It works just like the
> pipeline |>, but doesn’t take a left argument. Instead it returns an
> arity 1 function that, when called, executes the pipeline.
>
> toCamel = &> downcase |> split("_") |> map(&capitalize/1) |> join
>
> toCamel.("now is") # => "NowIs""the_time" |> toCamel.() # =>
> "the time"
>
> Why?
>
> -
>
> Function composition is a key part of FP. It would be nice to support
> it natively.
> -
>
> The current pipeline semantic both defines a processing flow *and
> executes it*. Splitting this into two would allow a lot more
> expressiveness.
> -
>
> This would allow pipelines to be composed. Think Plug, but functional .
>
> pipeline :browser do
>
> plug :accepts, ["html"]
>
> plug :fetch_session
>
> plug :fetch_flash
>
> plug :protect_from_forgeryend
>
> would become
>
> browser_pipeline =
> &> accepts("html") |> fetch_session |> fetch_flash |> protect_from_forgery
>
> The cool thing here is that each of the elements of the pipe is simply a
> function, and could be a nested pipeline. For example, we could create an
> authenticated pipeline by embedding the browser pipeline:
>
> authenticated_pipeline = &> browser_pipeline.() |> authenticate
>
> How?
>
> If we created a new prefix operator in the interpreter, then we could
> implement a proof of concept as a library. Folks could then use this for a
> while to see if the idea has merit, and if so, possibly roll this into the
> language syntax.
>
> I’d be happy to do this if there’s interest.
>
> Dave
>
>
> --
> 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/a5b1186c-a4ea-4f50-8143-354738f47632n%40googlegroups.com
> <https://groups.google.com/d/msgid/elixir-lang-core/a5b1186c-a4ea-4f50-8143-354738f47632n%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/CAKE-5T70SiLFqbCkQvEWqEAXavj_9XrtG49cHh%2BsrX7x0H45qg%40mail.gmail.com.
