David Matthews wrote:
... A vol is a VALUE in C-space. It can be any of the possible C values. To
Would it be accurate / better to say "a vol represents a VALUE in C-space"?
... I'm not exactly sure how this interacts with finalisation but I think it will work as expected. If a foreign function returns a value that needs finalisation it will be necessary to retain the vol it came in or create a new one and then attach the finalisation function to it. The important thing is that the ML data structure needs to keep a reference to the vol rather than, as in most cases, turning it into an ML value.
I agree that it seems like finalisation will work as expected.
I do think that the FFI is extremely complex (both on the data representation / marshaling and on the actual execution linkage) compared to, say, OCaml's.
http://caml.inria.fr/pub/docs/manual-ocaml/manual032.html
And yes, I know you didn't write it. ;)
OK, it *is* true that they "cheated" and added a keyword or two... but its "low level" implementation really *is* - and you can always add the typing-and-conversion layers like Poly's on top. In fact, the "LablGTK" package has something very similar for dealing with GTK.
... That's a good point. I had forgotten about 64-bit systems. I still think, though, that the field should be a size_t value since it could be the size of an array.
For all the reasons the somewhat ugly (depending on how you look at it) size_t exists, yes... and it doesn't even look like there will be many new warnings from C++ compilers by changing from "Bool" (i.e., "int").
... Well, I thought I'd avoid the issue and call it setFinal (perhaps to be changed to set_final for consistency)!
Don't give up - insist on
val set_finalise: sym -> vol -> unit
Accept no substitute! :)
Robert