Ah I see about sigils that makes sense thank you for explaining! That's a really interesting idea then to kind of surface the parts of the data structure that are public and "pattern matchable" so to speak (if I understand right),
> if we the concern is inspections .... That's true, I asked if we could do that in Decimal for example https://github.com/ericmj/decimal/pull/176 <https://github.com/ericmj/decimal/pull/176> Best Adam > On 7 Feb 2022, at 13:57, José Valim <[email protected]> wrote: > > And for all of those cases, if we the concern is inspections, there is always > the option of printing an expression, such as: > > MapSet.new([1, 2, 3]) > URI.parse("https://foo/bar <https://foo/bar>") > Version.parse!("1.0.0") > > It doesn't address the concerns about pattern matching though. > > On Mon, Feb 7, 2022 at 2:31 PM Wojtek Mach <[email protected] > <mailto:[email protected]>> wrote: > Regarding `%MapSet[1, 2]`, I think it looks really nice. > > Regarding multi-letter sigils, I think we should have those but not for this > particular use case. Sigils are for textual representations so not a good fit > for "containers" like MapSet, Vector, etc, when evaluating `%MapSet[...]` we > want to evaluate the items inside as _code_ not as _text_ (which the sigil > would). There's also the sigil escaping that José mentioned. > > This begs the question do we have `%MapSet[1, 2]` AND `~Version[1.0.0]` and > I'd say YES but I totally can see why they maybe look a bit too similar with > pretty different semantics and thus it's one or the other (or none!) > > Regarding the gist, > > iex> enum = [:foo, :bar, "set"] > ...> %[enum] > %[:foo, :bar, "set"] > > I think this should be `%[[:foo, :bar, "set"]]`. :) Otherwise `%[x]` is > different than `%[x, y]` which feels unpredictable. > > def function_2(%[:foo]) > > what are semantics of this pattern match? Does it match when the given set is: > > 1. a subset of `%[:foo]` > 2. when it is exactly the same? > > # Match and update - like `%{map | key: new_val}` > iex> set = %[%User{id: 1}] > iex> %[set | %User{} => %User{id: 2}] > > note, on maps we cannot do `%{map | %User{} => %User{id: 2}}` today. I mean, > we can, but it doesn't do what you want it to do, it would try to update a > key that `%User{}` evaluates to, something like `%User{id: nil, ...}`. > Changing the semantics would be a breaking change. It's unclear how it should > work when it matches multiple elements, do we update all of them? That's not > obvious! > > On February 7, 2022, "a-corp.co.uk <http://a-corp.co.uk/>" <[email protected] > <mailto:[email protected]>> wrote: > This is tricky for me. While I am sympathetic to the feature, I think this > would be the first time abstraction was added to pattern matching so we'd > need to be careful. > > Up to now the pattern matching syntax uses the same syntax that you use to > create the literal data that is being matched. Eg for a map pattern we write > a map > > %{a: variable} = %{a: 1} > > This brings clarity because the pattern describes the data you are matching > on - when you read the pattern you can see right away what the expected data > is (a map). > > The proposal sketched in the Gist would add indirection to pattern matching > by introducing a new syntax - syntax that is specific to one abstract data > structure (the map set). > > By abstracting away the details of the data structure being matched on we > reduce the clarity we usually get, we introduce more syntax into the > language, and we open the floodgates > to whether we should have pattern matching on more abstract data types - > Ranges, URIs... DateTimes etc. At which point the question really becomes > "should we have abstract patterns > in Elixir" which I think is harder to answer. > > In the meantime looking at ex_pat might be valuable to you because it would > allow you to reach into the details of a MapSet with pattern matching in a > controlled way that meant if the implementation > details of a MapSet changes it wouldn't break you program too much. > > https://github.com/vic/expat <https://github.com/vic/expat> > > Just my two cents though! > > Best > > Adam > > On 7 Feb 2022, at 10:33, SJ <[email protected] > <mailto:[email protected]>> wrote: > > Hi all. > > I have set out a proposal of what these things could potentially look like. > > https://gist.github.com/bdanklin/f4fc015fa90e9b33bb8cb580344e1258 > <https://gist.github.com/bdanklin/f4fc015fa90e9b33bb8cb580344e1258> > > I searched for prior work in this area and couldn't find any. > > If it's a welcome feature I'd be happy to work on it given some direction of > where to start. > > Thanks for any feedback. > > Best > > -- > 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/a73ced4a-5f61-4f40-bbba-8ed2749a3e62n%40googlegroups.com > > <https://groups.google.com/d/msgid/elixir-lang-core/a73ced4a-5f61-4f40-bbba-8ed2749a3e62n%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/8A766BAC-F075-4B54-9C6D-AC53A46FAAEF%40a-corp.co.uk > > <https://groups.google.com/d/msgid/elixir-lang-core/8A766BAC-F075-4B54-9C6D-AC53A46FAAEF%40a-corp.co.uk?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/85fe66455010f9204ffe4cd47bc726e5ecf6b023%40hey.com > > <https://groups.google.com/d/msgid/elixir-lang-core/85fe66455010f9204ffe4cd47bc726e5ecf6b023%40hey.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/CAGnRm4KOuXD4P3c%2Bkxa0O56qYbM9h_m39aHEKQJar_6Yo3winw%40mail.gmail.com > > <https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4KOuXD4P3c%2Bkxa0O56qYbM9h_m39aHEKQJar_6Yo3winw%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/EE108E83-AFA1-4C1B-8D14-25757B1F1487%40a-corp.co.uk.
