David Matthews wrote:
Robert Roessler wrote:
David Matthews wrote:
... Personally, I prefer not to curry functions if they require all their arguments to work and there's no obvious requirement for partial application, but that's very much a matter of personal taste. Actually, as I think about it this could usefully be curried if its type was val setFinal: sym -> vol -> unit It's quite likely that the same finalisation function would be used on different vols whereas I can't see why one would apply a different finaliser to the same vol.
Indeed.
On the foreign.cpp side of things, I notice 3 differences vs my version:
- I had it so that "finalisation" was only possible with NON-owned
vols, while your approach potentially allows Poly to use this feature now also.
Well, the vol that has the finaliser actually is an owned vol. That's because the C_pointer field contains the address of a malloc'd area that holds the C value. So when a C function returns a pointer value a new "vol" is allocated to contain the returned value. This extra level of indirection means that a vol can be a char, an int or a struct.
Ahhh... this goes along with the "there are always more levels of indirections than you think" comments in the code. ;)
I did, however, make the assumption that the "ownedness" field referred to whatever the C_pointer field was pointing to, rather than the vol holding that field itself... unless I am still confused (quite possible), this distinction is not very useful, since ALL vols themselves are actually owned by Poly?
Digging my hole deeper, what is the possible reason for vols to "be a char, an int or a struct"? I thought vols are there to manage foreign *memory* - implying pointers to [presumably but not necessarily] dynamically allocated storage... why would one want them to hold a value type?
- My field ordering was different in Volatile - since pointers can be
larger than ints, I slipped this in BEFORE the
Bool Own_C_space;
I prefer to keep structs "packed" for alignment and aesthetic reasons.
Actually, this "Bool" is an int (really an unsigned or size_t) that contains the size in bytes of the area. Calling it Bool looks like a piece of legacy code.
Naturally, I did check to see what the base type of 'Bool' actually is before posting this... as it is an int, my comment stands - the pointers preceding this field could be 64 bits, while this would still be 32 in some 64-bit models (e.g., Windows x64) and preserving the 8-byte alignment in that case certainly wouldn't hurt.
... I think I prefer it curried but as sym->vol->unit. I'll even accept "finalize" since my dictionary says it's acceptable and perhaps even preferred! It looks like there are a few things that need to be cleaned up anyway so I could make these changes.
Sweet (on the curried part)! But I was kidding about the finalize / finalise thing... I know how you types like your "colour", "analyse", etc. :)
Robert