Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
Re: [Caml-list] Subtyping structurally-equivalent records, or something like it?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2010-05-05 (12:12)
From: rossberg@m...
Subject: Re: [Caml-list] Re: Subtyping structurally-equivalent records, or something like it?
"Goswin von Brederlow" <>:
>>> This is not about optimized compiler in this case but about data
>>> representation. Even if you use an optimized compiler (which is not
>>> really the case with ocamlopt), you won't change datastructure
>>> representation to optimize.
>> What do you mean? There is no reason in general why a compiler cannot
>> optimize data representations, and some do in cases like this.
> How could it? At least for any type that is public in a module.
> The data representation is part of the ABI. As such it is fixed and can
> in no way be optimized by the compiler. Only thing you can do is change
> the ABI and define a more optimized representation in the first place.

Yes, and I didn't say that OCaml easily could, given external constraints
like the one you mention. I only was objecting to the statement that this is
not an optimization.

> A better representation would be to combine the two:
> bar {
>   tag = 0 (for Bar)
>   size = 2
>   field[0] = int(x)
>   field[1] = int(y)
> }

That is called flattening or unboxing, and in degenerate use cases it can
actually be costly because you have to copy the record if you extract it
first-class. However, for the original case there would be a much simpler
optimization: if a data type has only one constructor (more precisely, one
except for nullary ones), you don't need to represent its tag at all, so the
whole indirection is unnecessary.