Newb question: Why tuples?

[Hauptmech]

I'm trying to understand why or in what situations I would ever use a
tuple instead of a list. Is there anything a tuple can do that a list
can't (or shouldn't)? Why do tuples exist?

After a read through the prelude it seems like tuples are exactly like
lists, except for the (,) constructor (vs (:)) and the inability to
nest.

Also, why associate curry and uncurry with tuples instead of lists?

-hauptmech

[Hauptmech]

I notice that tuples can visually separate leaf nodes in nested lists.
I can see the value in that.

[Jeremy Voorhis]

On Wed, Dec 23, 2009 at 2:59 PM, Hauptmech <haup...@gmail.com> wrote:

I'm trying to understand why or in what situations I would ever use a
tuple instead of a list. Is there anything a tuple can do that a list
can't (or shouldn't)?  Why do tuples exist?

Lists have a variable number of elements and typically contain objects of a single type. Tuples contain a fixed number of elements and can assign an object of a different type to each position. In typed languages, tuples of different sizes are usually considered different types (e.g. pairs and triples). If it helps, you can think of tuples as anonymous structs.

 

After a read through the prelude it seems like tuples are exactly like
lists, except for the (,) constructor (vs (:)) and the inability to
nest.

There are also different operations defined on each sort of term.

In both Haskell and Python, tuples are allowed to nest. Albert has referred to Pure's tuples as "poor man's tuples", so I assume this decision was made to keep the implementation simple.

 

Also, why associate curry and uncurry with tuples instead of lists?

Fixed-length tuples that can contain multiple types naturally represent function parameter lists.

Best,

Jeremy

 

-hauptmech

--

You received this message because you are subscribed to the Google Groups "pure-lang" group.
To post to this group, send email to pure...@googlegroups.com.
To unsubscribe from this group, send email to pure-lang+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/pure-lang?hl=en.

[Jeremy Voorhis]

In typed languages, tuples of different sizes are usually considered different types (e.g. pairs and triples).

And to be clear, I mean statically typed :) 

[Albert Graef]

Hauptmech wrote:
> I'm trying to understand why or in what situations I would ever use a
> tuple instead of a list. Is there anything a tuple can do that a list
> can't (or shouldn't)? Why do tuples exist?

Well, you might call it a tradition, like the christmas tree. ;-)

In an FPL with curried function applications, you want to be able to
represent uncurried applications, so you need some kind of aggregate to
denote structured arguments (or structured function return values). It's
customary to use tuples (i.e., Cartesian products) for that purpose.

As Jeremy already mentioned, in H/M-typed languages you really need a
separate data type for that, as lists can only represent homogeneous
sequences in those languages. Pure doesn't have that restriction, so
strictly speaking tuples are not needed in Pure, but I still thought it
would be nice to have a separate representation that resembles
mathematical notation more closely than lists. In math, it's customary
to identify X^1 with just X and X^n x X^m with X^(n+m), which gives you
a simple kind of sequence without a nesting substructure, and this is
exactly what Pure provides. (This isn't quite the "official" definition
of tuples, which lacks associativity, but all mathematicians I know
outside of mathematical logic, i.e., in analysis, algebra etc., employ
this associative kind of Cartesian product because it's just convenient.)

> After a read through the prelude it seems like tuples are exactly like
> lists, except for the (,) constructor (vs (:)) and the inability to
> nest.

Yes, but the latter is the key difference here. Pure's tuples are in
fact just lists with the constructor equations (x,y),z = x,(y,z)
(associativity) and (),x = x,() = x (left- and right-neutral) added. So
() and (,) provide you with a simple predefined monoid structure which
makes Pure's term algebra closed under Kleene closure. From a practical
POV, the pairing operator (,), besides serving as the tuple constructor,
lets you do *all* basic operations on tuples, prepending and appending
elements as well as concatenation. Also, there's no distinction between
singletion tuples and the elements they contain. So it's really a
different kind of data type, more convenient than ordinary lists for
some uses, less for others.

Cheers,
Albert

--
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email: Dr.G...@t-online.de, a...@muwiinfa.geschichte.uni-mainz.de
WWW: http://www.musikinformatik.uni-mainz.de/ag

[Albert Graef]

Jeremy Voorhis wrote:
> In both Haskell and Python, tuples are allowed to nest.

In Pure, we already have lists for that, so there's no point in having a
second kind of tuple data structure which provides that functionality.

> Albert has referred to Pure's tuples as "poor man's tuples", so I assume this
> decision was made to keep the implementation simple.

I call them that way because they lack nestability (which is ok or even
nice for some uses, but a pita for others). Actually, the tuple
*implementation* is more complicated than lists because it involves
constructor equations.

[John Cowan]

Albert Graef scripsit:

> Jeremy Voorhis wrote:
> > In both Haskell and Python, tuples are allowed to nest.
>
> In Pure, we already have lists for that, so there's no point in having a
> second kind of tuple data structure which provides that functionality.

Here's a little table:

Language Lists Tuples
======== ===== ======
Haskell Immutable Immutable
Elements have single type Elements have different types
Can be improper Always proper
Linked list performance Vector performance
Python Mutable Immutable
Types unconstrained Types unconstrained
Always proper Always proper
Vector performance Vector performance
Pure Immutable Immutable
Types unconstrained Types unconstrained
Can be improper Always proper
Linked list performance ????

I don't know what to put in for Pure tuple performance. Are they linked
lists or vectors, under the covers?

--
John Cowan http://www.ccil.org/~cowan co...@ccil.org
"After all, would you consider a man without honor wealthy, even if his
Dinar laid end to end would reach from here to the Temple of Toplat?"
"No, I wouldn't", the beggar replied. "Why is that?" the Master asked.
"A Dinar doesn't go very far these days, Master. --Kehlog Albran
Besides, the Temple of Toplat is across the street." The Profit

[Albert Graef]

John Cowan wrote:
> I don't know what to put in for Pure tuple performance. Are they linked
> lists or vectors, under the covers?

Linked lists.

Why do you say that Haskell allows improper lists? Because the tail of a
list may be 'bottom'?

[John Cowan]

Albert Graef scripsit:

> Why do you say that Haskell allows improper lists? Because the tail of a
> list may be 'bottom'?

No, that was simply a mistake on my part. Improper lists would be
ill-typed, because the RHS of ":" has to have type [t]. (Bottom of
course belongs to every type.)

--
No saves, Antonio, loke es morirse en su lingua. Es komo John Cowan
kedarse soliko en el silensyo kada dya ke Dyo da, komo co...@ccil.org
ser sikileoso sin saver porke. http://www.ccil.org/~cowan
--Marcel Cohen, 1985