Yeah, I'd love to see this feature implemented. One of nice side effects of this is that it would allow for expressing Tuples as syntactic sugar for records, and you could automatically get accessors for the nth element of a tuple, plus they wouldn't be limited to size 9.
On Fri, Mar 10, 2017 at 3:02 PM, Jon Zeppieri <[email protected]> wrote: > > > 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. > -- 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.
