Back to Questions
2.7k
views4
comments
Tuple in discriminated union is not really a tuple
f#compiler

When I have this:

type Newman =

| Red of float * float * float

| Yellow of int * int * int

| Blue of byte * byte * byte

and I look at the IL generated, I get a concrete specialization (Red, Yellow, Blue) of an abstract base (Newman). Which makes sense.

But, I'd expect the content of those alternatives to be a Tuple'3 whereas the compiler generates the parts of the tuple as direct members. Meaning, I get a class Red with members item1, item2 and item3 of type double.

This seems to replicate functionality (compare etc) that is already on Tuple to the generated class.

Anyone know why ?

Thanks,

-- Henkk

.

You may want to look at the difference in the two examples below. (I presume you're just looking at the generated code out of curiosity/interest.)

type Newman =

| Red of float * float * float

| Yellow of int * int * int

| Blue of byte * byte * byte

type Newman2 =

| Red of (float * float * float)

| Yellow of (int * int * int)

| Blue of (byte * byte * byte)

By on 4/7/2010 11:20 AM ()

Yeah, I guess you could rephrase the question as why does the above make a difference, whereas

type Test =

int * int

let t:Test = 1,2

compiles into a Tuple'2.

Background: I'm using stuff I'm writing in F# from C# and I'd like to get a feel of what is generated when ...

Thanks,

-- Henkk

By on 4/7/2010 12:04 PM ()

The spec actually contains a good description of the compiled form of discriminated unions in section 8.5.3. It doesn't go into any detail on why this particular representation was chosen, however. The spec also mentions that parenthesis affect the compiled form a few paragraphs earlier.

By on 4/7/2010 12:19 PM ()

I am also confused about why there are two different representations. For what it's worth they seem to behave in the same way with respect to pattern matching, e.g.

1
2
3
4
5
6
7
8
9
10
11

type Foo = Red of float * float * float

let f = Red(1., 2., 3.)
let (Red(r, g, b)) = f
printfn "%f" (r + g + b)

type Bar = Blue of (float * float * float)

let bl = Blue(4., 5., 6.)
let (Blue(r2, g2, b2)) = bl
printfn "%f" (r2 + b2 + g2)

I bumped into this is when trying to define function signatures in an .fsi file and was thoroughly confused why 

1

(string * string)

would be different from 

1

string * string

Any ideas? Seems like the n-ary DUs are a slightly more efficient representation, you do not need the extra pointer de-ref to get to the values...

By on 8/26/2014 10:17 AM ()

    Topic tags

    IntelliFactory Offices Copyright (c) 2011-2012 IntelliFactory. All rights reserved.
    Home | Products | Consulting | Trainings | Blogs | Jobs | Contact Us | Terms of Use | Privacy Policy | Cookie Policy     		Built with WebSharper