Re: [Caml-list] Re: Subtyping structurally-equivalent records, or something like it?

[Goswin von Brederlow <goswin-v-b@web.de>]

rossberg@mpi-sws.org writes:

> "Goswin von Brederlow" <goswin-v-b@web.de>:
>>
>>>> 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.
>
> /Andreas

Actualy in this case you don't. In foo the "tag" part of the block is
unused and in bar it is the constructor id. (foo) and (Bar foo) just
happen to have the same representation. Extracting a foo from a bar
means you just ignore the tag part, which is already ignored anyway.

The case of only having one constructor can be seen as special case for
this in the case of records. But type gnarf = Gnarf of int could be
represented as plain int as you say. The idea is the same.


The reason ocaml does not do this is that defining lots of exception for
the representation of data makes the compiler much more complicated and
ocamls compiler aims at being simple. At least that's what has been said
in the past.

MfG
        Goswin