> I would say it also benefits outside of EEx having a simpler if/else when matching on a single thing
Changes to the language are often more complex than they originally seem. Especially when we are adding special behaviour to a construct. Today "if" works with expressions. It doesn't modify its first argument in anyway, which is how most constructs in Elixir work. So let's say we add "if foo <- bar do". Then someone may ask: does it mean <- is supported everywhere? Or maybe does "if" now supports multiple <- clauses, like "when" and "for" (the only constructs to accept <-) do? Now imagine that you have: if foo <- bar do ... else ... end And now you want to add a new clause. In Elixir, this means we need to move to a "cond". Does we know need to support <- in a cond too? Would anyone think this is actually readable at first glance? cond do foo <- bar -> And this is just immediate consequences I can think from the top of my head. We are bound to have more. *José Valim* www.plataformatec.com.br Skype: jv.ptec Founder and Director of R&D On Thu, Oct 17, 2019 at 9:43 PM Michael St Clair <[email protected]> wrote: > I would say it also benefits outside of EEx having a simpler if/else when > matching on a single thing > > On Thursday, October 17, 2019 at 1:39:14 PM UTC-6, José Valim wrote: >> >> I think I expressed myself poorly. I was not proposing to support <- on >> if, I am saying with is already a great alternative which is very close to >> what is being proposed. >> >> The only complaint about “with” would be: 1. you want an else clause, 2. >> you find the else unpleasant on EEx, and 3. you *have* for some reason to >> pattern match inside EEx. >> >> I don’t think it is a scenario frequent enough to add exceptions to >> built-in constructs. In fact, the argument that something does not look >> good in EEx is unlikely to be enough reason to change the language, >> especially when you can extend it yourself. :) >> >> >> On Thu, Oct 17, 2019 at 21:31 Kelvin Raffael Stinghen < >> [email protected]> wrote: >> >>> > With does seem like the right thing in this case. >>> >>> His argument is that using a `case` for that is quite noisy, and `with` >>> would be no different, since he would need to do something like: >>> >>> with %{bar: “baz”} <- foo do >>> “hello i match” >>> else >>> _ -> nil >>> end >>> >>> Since when `with` does not match and no `else` clause is given, the >>> return value is the unmatched value, instead of `nil` as I would expect it >>> to be on something like: >>> >>> if %{bar: “baz”} <- foo do >>> “hello i match” >>> end >>> >>> Best, >>> Kelvin Stinghen >>> [email protected] >>> >>> On Oct 17, 2019, at 16:24, Michael St Clair <[email protected]> wrote: >>> >>> With does seem like the right thing in this case. >>> >>> Although to add I don't think I have ever done pattern matching in an if >>> for this reason. Seems like if you are wrapping pattern matching in an if >>> you want to know if the match works. I think supporting `<-` in an `if` >>> would be good if there are issues with just using `=` to make things >>> simpler. Specifically when using with and an else statement when only >>> checking a single match. >>> >>> On Thursday, October 17, 2019 at 1:15:41 PM UTC-6, José Valim wrote: >>>> >>>> Thanks Joel for the proposal. >>>> >>>> I am not a big fan of a macro changing what = means. = typically means >>>> pattern matching and a MatchClause error in case they don't match. Sure, we >>>> can change what it means, but if = starts meaning different things in >>>> different places, developers would constantly start to second guess >>>> themselves. >>>> >>>> Even inside for and with-comprehensions, = means MatchClause error and >>>> they introduce an explicit <- construct for "soft matching". So maybe we >>>> could do: >>>> >>>> <%= if %{bar: bar} <- foo do %> >>>> ... >>>> <% end %> >>>> >>>> But then you might as well use with: >>>> >>>> <%= with %{bar: bar} <- foo do %> >>>> Do that >>>> <% end %> >>>> >>>> Although the best solution here would be to move the logic to helper >>>> functions. I would prefer to avoid pattern matching in templates. >>>> >>>> >>>> *José Valim* >>>> www.plataformatec.com.br >>>> Skype: jv.ptec >>>> Founder and Director of R&D >>>> >>>> >>>> On Thu, Oct 17, 2019 at 9:04 PM Joel Wietelmann <[email protected]> >>>> wrote: >>>> >>>>> Scenario: You have one pattern you want to match. You do not want to >>>>> raise a NoMatchError when the value fails to match this pattern. >>>>> >>>>> Probably the best available thing to do is to use a `case` statement: >>>>> >>>>> case foo do >>>>> %{bar: "baz"} -> "hello i match" >>>>> _ -> nil >>>>> end >>>>> >>>>> However, that default case can get pretty repetitive when it's >>>>> frequently nothing, and it gets even more awkward inside of EEx: >>>>> >>>>> <%= case foo do %> >>>>> <% %{bar: "baz"} -> %> >>>>> hello i match >>>>> <% _ -> %> >>>>> <% end %> >>>>> >>>>> There's also `Kernel.match?/2`, which is awkward to use in an `if` >>>>> statement because it doesn't read like any pattern matching expression >>>>> that >>>>> an Elixir developer has typically ever written: >>>>> >>>>> if match?(%{bar: "baz"}, foo) do >>>>> "yes" >>>>> end >>>>> >>>>> Here is an alternative idea, which I think is significantly easier to >>>>> read than the above options: >>>>> >>>>> if_match %{bar: "baz"} = foo do >>>>> "yes" >>>>> else >>>>> "no" >>>>> end >>>>> >>>>> if_match %{bar: "not baz"} = foo do >>>>> "yes" >>>>> end >>>>> >>>>> <%= if_match %{bar: "baz"} = foo do %> >>>>> hello i match >>>>> <% end %> >>>>> >>>>> Proof of concept code: >>>>> >>>>> defmacro if_match(expression, do: do_clause) do >>>>> quote do >>>>> match(unquote(expression), do: unquote(do_clause), else: nil) >>>>> end >>>>> end >>>>> >>>>> defmacro if_match({:=, _, [pattern, value]}, do: do_clause, else: >>>>> else_clause) do >>>>> quote do >>>>> case unquote(value) do >>>>> unquote(pattern) -> >>>>> unquote(do_clause) >>>>> >>>>> _ -> >>>>> unquote(else_clause) >>>>> end >>>>> end >>>>> end >>>>> >>>>> -- >>>>> 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/4944626e-7cde-4200-ae3a-e573102246a2%40googlegroups.com >>>>> <https://groups.google.com/d/msgid/elixir-lang-core/4944626e-7cde-4200-ae3a-e573102246a2%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 [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/elixir-lang-core/c3e612e7-507e-4ede-9175-7c8809d05eee%40googlegroups.com >>> <https://groups.google.com/d/msgid/elixir-lang-core/c3e612e7-507e-4ede-9175-7c8809d05eee%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 [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/elixir-lang-core/DA1FAB7C-1040-4D08-8E9E-A8E045FD98A9%40gmail.com >>> <https://groups.google.com/d/msgid/elixir-lang-core/DA1FAB7C-1040-4D08-8E9E-A8E045FD98A9%40gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- >> >> >> *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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/elixir-lang-core/bf9ca31f-b6e7-405b-b534-f70a00cfdb9b%40googlegroups.com > <https://groups.google.com/d/msgid/elixir-lang-core/bf9ca31f-b6e7-405b-b534-f70a00cfdb9b%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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4JP1%2B7PvkBVaPY0umsYOeKimSQonkcr16o5Nh-AEm3paA%40mail.gmail.com.
