Version française
Home     About     Download     Resources     Contact us    
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: -- (:)
From: Goswin von Brederlow <goswin-v-b@w...>
Subject: Re: [Caml-list] Re: Subtyping structurally-equivalent records, or something like it?
rossberg@mpi-sws.org writes:

> "Sylvain Le Gall" <sylvain@le-gall.net>:
>>
>> 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.

As example

type foo = { x : int; y : int; }
type bar = Bar of foo

Currently a bar is represented as

foo {
  tag = 0
  size = 2
  field[0] = int(x)
  field[1] = int(y)
}
bar {
  tag = 0 (for Bar)
  size = 1
  field[0] = &foo
}

2 Blocks taking up 5 words.


A better representation would be to combine the two:

bar {
  tag = 0 (for Bar)
  size = 2
  field[0] = int(x) 
  field[1] = int(y) 
}    

A single block of 3 words.

This also works for

type bar = Foo of foo | Blub of foo | Blubber of foo

but not for

type baz = Baz of bar


There are lots of cases where the representation could be improved for
special cases. But ocaml I think only does that for float arrays or
records that only contain floats. But that is a design decision and not
something the compiler can just optimize.

MfG
        Goswin