Thank you everyone for the feedback, definitely a lot I didn't think of.
@Wojtek
Example 1 I took inspiration from the MapSet.new function. where `new/0`
returns an empty MapSet and `new/1` takes an enum and enumerates those
objects into the new MapSet.
Example 2 is a subset. which follows the current logic from matching map
keys .
%{foo: :foo, bar: :bar}
|> case do
%{foo: foo} -> foo
%{foo: _foo, bar: bar} -> bar
end
|> IO.inspect()
#=> :foo
Example 3 you are correct. I was incorrect with how I thought keys in maps
could be matched and after further review, I agree with Adam that it is too
abstract and differs too greatly, it should be disregarded. I will update
the gist accordingly.
Best
On Tue, Feb 8, 2022 at 12:08 AM Adam Lancaster <a...@a-corp.co.uk> wrote:
> 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
>
> Best
>
> Adam
>
> On 7 Feb 2022, at 13:57, José Valim <jose.va...@dashbit.co> 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";)
> 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
> <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 a topic in the
> Google Groups "elixir-lang-core" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/elixir-lang-core/RA5uXkilYsE/unsubscribe
> .
> To unsubscribe from this group and all its topics, 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/EE108E83-AFA1-4C1B-8D14-25757B1F1487%40a-corp.co.uk
> <https://groups.google.com/d/msgid/elixir-lang-core/EE108E83-AFA1-4C1B-8D14-25757B1F1487%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/CABE3SBjqUjsu1hnEm3VO%2BkqZ_Tyx5psRoDA7HW74PnZSvRx9BA%40mail.gmail.com.
