Functional Programming: Are Tuples a viable replacement for Types?

Question

A while ago I decided to learn Haskell to help with learning more "pure functional" ideas that I could apply to F#. Right off the bat it seems as if there's no real types in Haskell like the ones that F# has. I'm fine with that so I wanted to find a way to remove myself from the hybrid OO/Functional design I've used in F# and really try to go classless and truly develop a function centric design. The first thing that came to mind when using Haskell was to just pass tuples around as they can hold information in key value pairs much like dynamic languages but don't have the constructor syntax like F# types.

For example in F#:

type DatabaseWorkValueItem(firstItem, secondItem, thirdItem) =
  member public x.FirstItem = firstItem
  member public x.SecondItem = secondItem
  member public x.ThirdItem = thirdItem

And this would be in my new proposed design:

module DatabaseWorkValueItem =

  let firstItem (item, _, _) = item
  let secondItem (_,item, _) = item
  let thirdItem (_,_, item) = item

  --Replace constructor with method
  let CreateValueItem (parameter:String, value:Object, sqlType:SqlDbType) =
    (parameter, value, sqlType)

  --Replace properties with more methods
  let GetDataType (item :(String *Object * SqlDbType)) = 
    thirdItem item

  let GetParameter (item :(String *Object * SqlDbType)) = 
    firstItem item

  let GetValue (item :(String *Object * SqlDbType)) = 
    secondItem item

They both get the same idea. One creates a class like Type with properties set on construction and the other uses all functions to create and read a tuple.

Question is: Am I crazy to bother with this? Although I realize F# has the convenience of jumping between two paradigms, I can't help but feel that it's a comfort blanket to

Answer 1

I don't know what makes you think that Haskell doesn't have real types or that using different types is somehow against the concept of functional programming. Passing around tuples instead of a more meaningful types is a terrible idea in F# as well as in Haskell as it greatly diminishes the type safety that statically typed languages like Haskell and F# offer.

Static type safety is a very important concept in statically typed functional programming languages (even more so than in statically typed OO-languages, I'd say) and code using only tuples would definitely not be idiomatic in any such language.

For example consider an application that represents the structure of a University. This application may have types to represent students and classes (among other things of course). Let's say a student has a name and an age and a class has a name and a number of attendees. Both of these could be represented as (String, Int) tuples. However if you do that any function that accepts a student as its argument will also accept a class instead without causing a compile-error because you represent both using the same type. If you define separate types for students and classes that does not happen.

Answer 2

Generics exist because they make programming life easy. Your question is similar to asking if using a List that takes Integer types in its generics argument is somehow less safe than designing a list called IntList that's hardcoded to accept only Ints.

In Java a C#, there's typically a geometric point object called Point3D that has float parameters x, y, z. But it should be clear that a 3-tuple of types float is functionally equivalent to Point3D.

The continuation-passing style programs allow output to be returned in more than one variable. The direct style programs allow output to be return in one variable only. Tuples are a quick way allowing more than one output to be returned in a function and they prevent junk classes from polluting your library when you don't need to deal with them.