Phil,
I think it could be possible to provide CInterface.null as a persistent vol pointing to a value containing (void*)0. I know that seems a contradiction but it should be possible. I'm just not sure it's necessary. Why do you need to have "null" and "isNull"? Have you considered instead building converters between the C data structure and ML and doing everything within ML. There's example of this in mlsource/extra/CInterface/Examples/ForeignTest.sml which converts a simple tree structure:

(* Example of creating a conversion for a datatype. *)
datatype intTree = NullTree | Node of {left: intTree, right: intTree, valu: int};

(* The corresponding C structure is
typedef struct _tree {
    struct _tree *left, *right;
    int nValue;
} *tree;
*)

On the your question about equality for vols: it's possible that there could be an equality test but I'm not sure it would be very useful. All it would do would test whether they were the same vol but that wouldn't tell you whether two vols contained the same C data.

Regards,
David

On 13/11/2011 21:35, Phil Clayton wrote:
On 11/11/11 20:18, Phil Clayton wrote:
I am currently implementing
type t
val null : t
val isNull : t -> bool
where type t = CInterface.vol. There is no problem doing this but I
wondered whether I could improve the CInterface structure to avoid
annoying little C library functions.

I have realized that C functions are not necessary to implement these -
just to toClong and fromClong:

val null = toClong 0
fun isNull v = fromClong v = 0


Would it be at all controversial to include
null : vol
in CInterface?

For a different reason, this could still be useful. I had forgotten that
volatiles do not persist in saved states or executables (it should have
been obvious from the name) so I can't see how to create such a null
value to implement

val null : t

where type t = CInterface.vol. (There is nothing volatile about null
really.)

Perhaps the best approach here is to implement with type t =
CInterface.vol option, with NONE representing null.

Phil


_______________________________________________
polyml mailing list
[email protected]
http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
_______________________________________________
polyml mailing list
[email protected]
http://lists.inf.ed.ac.uk/mailman/listinfo/polyml

Reply via email to