I'll leave the second question for next time. Today, we'll see how the values of a tuple can be extracted.
Here is the tuple that we began with last time:
Extracting the values from this tuple is a simple matter of using the fst and snd functions (which F# held over from its ML heritage). These functions retrieve the first and second values, respectively, from a two-value tuple.
The results of these functions also can be assigned to variables.
That's great, but what if we need to extract the values from a tuple whose length is greater than two?
Is there a thrd function we can use to get the last element out of the tuple above? Nope. In fact, the fst and snd functions that we used on pair won't even work with this tuple. The problem is that those functions are intended to be used only with tuples of two values. This becomes clear when their definitions are considered:
If we try to use either fst or snd with our triple tuple, a type mismatch error occurs.
Fortunately, F# provides a very natural syntax to extract the values from any tuple. The idea is to use a simple let statement. However, instead of binding to a single name, we bind to a pattern made up of several names. For example, we can extract the values from our triple tuple like so:
The obvious follow-up question is, what if we only want to retrieve one or two values from triple? Put another way, is it really necessary to bind each value of a tuple to a name even when we aren't interested in all of the values? The answer is, no, it isn't necessary to bind each value of a tuple of a name. F# provides an ultra-handy wildcard pattern that trivializes this problem. Wildcards allow us to bind only the information that we're interested in by adding "holes" to a pattern. In code, they are represented by an underscore (_) character.
Very cool. We'll see more uses of wildcards as this series progresses.
That should answer the first question above. Next time, we'll explore some important uses of tuples that make them very compelling—especially for .NET developers.
Page rendered at Tuesday, January 06, 2009 8:47:24 AM (Eastern Standard Time, UTC-05:00)