On Friday, March 10, 2017 at 5:15:07 PM UTC-5, Rupert Smith wrote:
>
> On Friday, March 10, 2017 at 8:05:47 PM UTC, Jon Zeppieri wrote:
>>
>> This topic must have come up in the past, but I promise that I did look
>> before posting and only found limited information.
>>
>> Pattern-matching on records is limited to punning on the field name. That
>> is, you can have a pattern like `{a, b}`, which will bind `a` to the value
>> corresponding to the record's `a` label and `b` to the value... &c, &c. But
>> you can't write a more general pattern like `{a = <pat1>, b = <pat2>}`.
>>
>> Is there some aspect of the language that makes it impossible (or
>> difficult) to support these patterns? Or are they just not implemented, for
>> whatever reason?
>>
>
> They would not be impossible for the compile to implement.
>
> func { a = SomeType field } = ...
>
> Can expand to
>
> func { a } =
> let
> (SomeType field) = a
> in
> ...
>
> demonstrating that is just syntax sugar.
>
Yeah, I was wondering if it had to do with the static semantics, like if
the case expression requires disjoint LHSes, so that, for example, in the
expression:
case r of
{a = (_, 1)} -> ...
{b = (_, 0)} -> ...
both LHSes would be satisfied for r = {a = (True, 1), b = (False, 0)}, but
not for all values of r. So if you allow that expression, then presumably
the order of the case-arms becomes significant. Well, okay, order is
already significant, or else you couldn't use a wildcard at the end of a
multi-armed `case`. But I mean: it looks like `case` currently checks if a
LHS pattern is redundant with any that come before it in order, which I
guess is less useful for row-polymorphic records, since the analysis needs
to be so conservative.
Anyhow, that's the sort of thing I had in mind. Thanks!
--
You received this message because you are subscribed to the Google Groups "Elm
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
