There's definitely philosophical and practical arguments for this.
Right now, tuples are already just syntactic sugar for the _TupleN tagged
union types. This doesn't make a lot of since, since tuples aren't sums
(unions) with multiple variants. They are, however, perfectly analogous to
records: there's no variants, but multiple values are bundled together.
They represent a product, not a sum. The only difference is whether the
projections are identified by a name or by an order.
There are disadvantages to treating tuples as sums. Right now, the compiler
needs to figure out that there's only ever one variant for tuples. With
them as records, it would just know that there can never be more variants.
Since tuples are already syntactic sugar, it would make more sense to make
them sugar for records. You could do something like this:
*Types:*
(Foo, ..., Bar) sugar for {field1: Foo, ..., fieldK: Bar}
*Expressions:*
(foo, ..., bar) sugar for {field1 = foo, ..., fieldK = Bar}
The translation for patterns is a bit more tricky, but it's certainly
possible.
Then, you'd get accessors for free. You'd get polymorphism over the number
of fields for free. The type system would not have to be altered at all. It
would also solve the "limit of 9" issue for tuples.
On Tue, Dec 27, 2016 at 1:25 PM, Mike MacDonald <[email protected]> wrote:
> Specifically, I am using the ParseErr and ParseOk types from elm-combine (
> http://package.elm-lang.org/packages/Bogdanp/elm-combine/
> 3.1.1/Combine#ParseErr ). I only care about the third value, since the
> first will always be unit, and the second will always be the end of the
> stream.
>
> On Tuesday, December 27, 2016 at 2:14:08 PM UTC-5, Aaron VonderHaar wrote:
>>
>> Sorry for being unclear. Your point that it should be unnecessary to
>> name unimportant things is a valid one. Can you share the specifics of
>> scenarios where you have 3-tuples and larger where it doesn't make sense to
>> give names to each part? Elm's design is based on finding clean solutions
>> to real-world problems, so more examples of that are valuable to inform
>> Elm's future development.
>>
>> You also mentioned that you ran into this when using 3rd-party packages.
>> Can you point out some of the packages where you've needed to use functions
>> that returned 3-tuples and larger where you only cared about one of the
>> values in the tuple?
>>
>>
>>
>> On Tue, Dec 27, 2016 at 10:55 AM, Mike MacDonald <[email protected]>
>> wrote:
>>
>>> I can't think of a use case where defining an intermediary type wouldn't
>>> solve the immediate issue; philosophically I dislike naming things which
>>> are unimportant.
>>>
>>> On Tuesday, December 27, 2016 at 1:08:03 PM UTC-5, Aaron VonderHaar
>>> wrote:
>>>>
>>>> One reason `first` and `second` are only defined for 2-tuples is that
>>>> it's usually a better choice to use records if you have more than a couple
>>>> fields.
>>>>
>>>> If defining a record type alias and giving names to you're fields
>>>> doesn't work for your situation, can you give more details about why?
>>>>
>>>> On Dec 27, 2016 7:09 AM, "Mike MacDonald" <[email protected]> wrote:
>>>>
>>>>> On a somewhat regular basis, I end up needing to extract a single
>>>>> field from a tuple provided from a third-party function. At the moment, I
>>>>> have to write a boilerplate function just to pattern match it out. If I
>>>>> need the second field of tuple of a different size, I need to write more
>>>>> boilerplate.
>>>>>
>>>>> Seeing as record filed names cannot start with digits, and the
>>>>> language only allows up to Tuple9, it would be nice to have `.0` through
>>>>> `.8` as accessors to the tuple. This is symmetric with record field access
>>>>> "methods", and seems like a moderate ergonomic gain.
>>>>>
>>>>> Thoughts?
>>>>>
>>>>> --
>>>>> 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.
>>>
>>
>> --
> 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.
