Cary Cherng | 14 Jan 04:58 2014
Picon

Records vs Tuples

What exactly is the purpose in having both records and tuples? They
seem to behave rather similarly although records do have the extra
naming of the fields that tuples don't.
Ivan Lazar Miljenovic | 14 Jan 06:27 2014
Picon

Re: Records vs Tuples

On 14 January 2014 14:58, Cary Cherng <ccherng <at> gmail.com> wrote:
> What exactly is the purpose in having both records and tuples? They
> seem to behave rather similarly although records do have the extra
> naming of the fields that tuples don't.

Tuples: let you quickly group values together for one-off cases.

Custom data types: named grouping of values so you can give them a
specific type; optionally not exposing constructor so that you can
hide internals.  Record syntax is a a way of naming specific fields
within these data types.

Note that what you actually seem to be asking is "why have any data
type whose constructor can take more than one value", as this is what
a tuple is a specific instance of:

data Pair a b = Pair a b

data Triple a b c = Triple a b c

etc.

You can consider tuples to be pre-defined types with convenient
syntax.  But if you want to properly type your code you should define
your own types as appropriate.

> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe <at> haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
(Continue reading)

Kim-Ee Yeoh | 14 Jan 08:07 2014

Re: Records vs Tuples


On Tue, Jan 14, 2014 at 10:58 AM, Cary Cherng <ccherng <at> gmail.com> wrote:
What exactly is the purpose in having both records and tuples? They
seem to behave rather similarly

What's the purpose of distinguishing between US dollars, OZ dollars, Can dollars, etc? At the end of the day, aren't they just _numbers_?

-- Kim-Ee
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Alexander Solla | 14 Jan 08:12 2014
Picon

Re: Records vs Tuples




On Mon, Jan 13, 2014 at 11:07 PM, Kim-Ee Yeoh <ky3 <at> atamo.com> wrote:

On Tue, Jan 14, 2014 at 10:58 AM, Cary Cherng <ccherng <at> gmail.com> wrote:
What exactly is the purpose in having both records and tuples? They
seem to behave rather similarly

What's the purpose of distinguishing between US dollars, OZ dollars, Can dollars, etc? At the end of the day, aren't they just _numbers_?

-- Kim-Ee


Maybe I'm tired, but I thought you were serious there for a moment. :)
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Kim-Ee Yeoh | 14 Jan 09:14 2014

Re: Records vs Tuples


On Tue, Jan 14, 2014 at 2:12 PM, Alexander Solla <alex.solla <at> gmail.com> wrote:
Maybe I'm tired, but I thought you were serious there for a moment. :)

Channeling Socrates, who tends to be under-rated. ;)

p.s. not that I consider myself anywhere that good

-- Kim-Ee
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Mateusz Kowalczyk | 14 Jan 08:26 2014
Picon

Re: Records vs Tuples

On 14/01/14 03:58, Cary Cherng wrote:
> What exactly is the purpose in having both records and tuples? They
> seem to behave rather similarly although records do have the extra
> naming of the fields that tuples don't.
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe <at> haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
> 

Didn't we just have this thread the other day but the case being ‘Maybe
a’ vs ‘Either () a’? I'm sure all the arguments that come up in this
thread have already been answered there.

--

-- 
Mateusz K.
oleg | 14 Jan 09:34 2014

Re: Records vs Tuples


Cary Cherng wrote:
> What exactly is the purpose in having both records and tuples? They
> seem to behave rather similarly although records do have the extra
> naming of the fields that tuples don't.

In SML there is really no difference:

    In fact, in Standard ML, tuples are simply a special case of records; for
    example, the type int * string * bool is the same as the type { 1 : int, 2 :
    string, 3 : bool }.
http://en.wikibooks.org/wiki/Standard_ML_Programming/Types

In some programming languages (C, OCaml, Haskell), records, or
structures, have to be declared and are not extensible. OCaml also has
extensible records, which don't have to be declared and whose field
names may be reused. Tuples may be thought of as `extensible' records
that don't have to be declared (and HList takes this thought quite
seriously).

> data Rec1 = Rec1 { a :: Int, b :: Bool}
> data Rec2 = Rec2 { a :: Int, b :: Bool}
> foo :: Rec1 -> Bool
>
> Rec1 and Rec2 could be in totally different code libraries. I've read
> that preventing Rec2 being used in foo is good for the type safety in
> that Rec1 and Rec2 are likely intended to have semantically different
> meanings and allowing interchangeability breaks this.

The reason is not type safety but type inference, or the ease of it. Given

> data Rec1 = Rec1 { rec1a :: Int, rec1b :: Bool}
> data Rec2 = Rec2 { rec2a :: Int, rec2b :: Bool}

and the term
        \x -> rec2a x + 1
the type checker quickly determines that x must be of a type Rec2, and
the inferred type is Rec2 -> Int. With extensible records, using OCaml:

        # fun x -> x#rec2a + 1;;
        - : < rec2a : int; .. > -> int = <fun>
we infer a polymorphic type. That's all nice, until we look at the
OCaml type checker and see the complexity of inference. Open records
bring up lots of interesting problems (e.g., variance), which interact
in interesting and not yet worked out ways with other features (e.g.,
GADTs). 

Also, open records can often mask problems. For example, in Haskell

        \x -> rec1a x + rec2a x
won't type check but the corresponding code in OCaml will -- although
the programmer may have never intended a record with both fields rec1a
and rec2a. OCaml community has had a lot of experience with extensible and
non-extensible records (and their dual -- extensible and
non-extensible variants). The conclusion seems to be that both are
needed. Often a programmer does mean closed records/variants; and
non-extensible forms match the programmer's intent closely and give
better, and earlier, error messages.

Gmane