> Then someone may ask: does it mean <- is supported everywhere? Well, someone might already ask that by looking at `for` and `with` and wondering if it works for `case`, `if` and `cond`.
> Or maybe does "if" now supports multiple <- clauses, like "when" and "for" > (the only constructs to accept <-) do? This one is a good point, and maybe it would be a nice thing to make the answer to that question a “yes” and just merge all the clauses using `and`s. > Does we know need to support <- in a cond too? Would anyone think this is > actually readable at first glance? Indeed, the pattern `<- … ->` is a bit strange to look at, but would still be a nice feature to have spread over all the conditional constructs. To be honest, I can’t really tell the overall complexity of the change, and neither what would the cost to compilation be (I suppose it’s big), but my point is that maybe it is worth the try at least. I will create a lib with some macros for that, and try to benchmark the compilation, just out of curiosity. I let you know of the results. Best, Kelvin Stinghen [email protected] > On Oct 17, 2019, at 16:55, José Valim <[email protected]> wrote: > > > 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 <http://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] > <mailto:[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 <http://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 <http://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] > <mailto:[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] > <mailto:[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 > > <https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4JP1%2B7PvkBVaPY0umsYOeKimSQonkcr16o5Nh-AEm3paA%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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/6698EA78-E15C-43DA-8A72-2CDBF03D1EC8%40gmail.com.
