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

  • 8
    The premise of your question seems flawed, given the fact that Haskell has extremely strong type concepts. Suggest reading more about Haskell - in particular the data keyword and record syntax.
    – sdg
    Jan 9, 2012 at 17:18
  • 3
    The question makes no sense as it stands - tuples are types. Hence I read: Are certain types a viable replacement for types? Consider reformulation.
    – Ingo
    Jan 9, 2012 at 17:34
  • The point I was trying to make is that I don't see any correlation between what F# considers a Type and what Haskell does. The Type keyword in F# is almost a quasi class as it has constructors, methods, and properties. This is why it seems contrary to functional design, but obviously I'm no expert on pure functional programming so I definitely could be mistake. Jan 9, 2012 at 17:47
  • 2
    @Programmin Tool - from your long comment - you are right, the word Type is used differently between the two languages, and while there is overlap, they are not the same.
    – sdg
    Jan 9, 2012 at 18:28
  • 2
    @ProgramminTool The type keyword in F# has many uses. It can define classes, records, algebraic data types and type aliases. Of those four Haskell does not have classes (not in the F#/.net sense anyway), but it does have the other three.
    – sepp2k
    Jan 9, 2012 at 18:29

2 Answers 2


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.

  • 1
    I was under the impression that tuples were type safe and therefore in the example I had, only a tuple that is (string, object, sqlData type) is the only type of tuple it can handle. Now I agree that it's possible to send in anything that fits that signature, but I was thinking this would afford more flexibility without being completely dynamically types Jan 9, 2012 at 17:50
  • Also want to make it clear that I am in no way doubting your opinion since I have very little experience with functional languages, but in the end that's why I asked this question. Jan 9, 2012 at 17:52
  • 3
    @ProgramminTool Tuples are type-safe in the sense that you can't pass an (Int, String) tuple to a function expecting an (Int, Int) tuple for example. But they're less type safe than using different types to represent different things in the sense that passing a (String, Int) tuple representing a student to a function that expects a (String, Int) tuple representing a class will not cause an error, while the same code using Student and Class data types would.
    – sepp2k
    Jan 9, 2012 at 18:20
  • It's true that using tuples is not completely dynamically typed, but the goal is to not at all be dynamically typed - not just "not completely". Basically the goal of most statically typed FP languages is that any programmer error that can be caught at compile time should be caught at compile time. So you should design your programs in a way that reflects that goal.
    – sepp2k
    Jan 9, 2012 at 18:21
  • 1
    @ProgramminTool As I said in my comment to the question, the type keyword servers multiple functions in F#. If you use it to define classes, you'll indeed end up with object oriented code (though that doesn't mean it won't also be functional - functional and object oriented are in no way mutually exclusive), but if you use it to define algebraic data types, records and type aliases only, you'll end up with code that won't be very different from Haskell or ML code.
    – sepp2k
    Jan 9, 2012 at 18:44

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.

  • 2
    -1 because this answer currently reads as if you are discouraging people from using Haskell's (or whatever functional language's) type system. Make use of the tools available to you, especially when they are this good. Oct 23, 2015 at 14:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.