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
_______________________________________________
polyml mailing list
[email protected]
http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
