Comment author: administrator

Hi Markus,

there is somewhat inconsistent behaviour here between native code and
byte code, e.g.:

That's what the doc means when it says "implementation-dependent". Byte-code
and native-code are two different implementations of the language.

let _ = let u = () in Gc.finalise finaliser [u]; loop ()

This will trigger the finaliser in both cases so constants are obviously
not substituted at compile time, which could be surprising to people in
such simple cases.

Things like finalisation and weak pointers do expose some details of the
implementation that would otherwise be impossible to see from user programs.
That's one reason why they are largely under-specified: the rest of the
O'Caml docs don't even define the concepts that would be needed to explain
what is going on.

The other reason is that we don't want to paint ourselves in a corner by
ruling out some optimisations that we might want to implement later.

I'm adding a sentence in gc.mli to say that the results of String.make,
String.create, and Array.make are guaranteed to be finalisable (on the
condition that the length argument is not zero). Maybe we'll add a few
others later.

-- Damien

Comment author: administrator

On Fri, 05 Oct 2001, Damien Doligez wrote:

That's what the doc means when it says "implementation-dependent". Byte-code
and native-code are two different implementations of the language.

Ok, I see. I thought behaviour was merely "unspecified" like evaluation
order, but still the same for both byte and native code of the current
implementation. It's probably not a terribly big problem to have such
minor differences.

The other reason is that we don't want to paint ourselves in a corner by
ruling out some optimisations that we might want to implement later.

Understandable. It might be interesting to know what kind of optimisations
you are intending, a topic which surely many people on the mailing list
would be eager to learn about!

Regards,
Markus

--
Markus Mottl markus@oefai.at
Austrian Research Institute
for Artificial Intelligence http://www.oefai.at/~markus