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";)
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 <woj...@wojtekmach.pl> 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" <a...@a-corp.co.uk> 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
>
> Just my two cents though!
>
> Best
>
> Adam
>
> On 7 Feb 2022, at 10:33, SJ <hellobenjamindank...@gmail.com> wrote:
>
> Hi all.
>
> I have set out a proposal of what these things could potentially look like.
>
> 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 elixir-lang-core+unsubscr...@googlegroups.com.
> 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 elixir-lang-core+unsubscr...@googlegroups.com.
> 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 elixir-lang-core+unsubscr...@googlegroups.com.
> 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 elixir-lang-core+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4KOuXD4P3c%2Bkxa0O56qYbM9h_m39aHEKQJar_6Yo3winw%40mail.gmail.com.
