> >I guess 's' is British and 'z' is American.
>
> Chambers (of Cambridge, England) has both.
"z" used to be the British English standard. It is still preferred by the
Oxford English Dictionary, and consequently, the Oxford Universtiy Press.
The rationale is that "z" is the most sensible transcri
At 2001-09-21 09:40, Marcin 'Qrczak' Kowalczyk wrote:
>> (apologies for the different spelling of finalize - apparently both are
>> correct and I randomly settled on the 'z' version some time ago).
>
>I guess 's' is British and 'z' is American.
Chambers (of Cambridge, England) has both.
--
Ash
Thu, 20 Sep 2001 12:56:55 +0100, Simon Marlow <[EMAIL PROTECTED]> pisze:
> (apologies for the different spelling of finalize - apparently both are
> correct and I randomly settled on the 'z' version some time ago).
I guess 's' is British and 'z' is American.
--
__("< Marcin Kowalczyk * [EMAI
> OK, you are saying that the ForeignObj# is a representation
> of a 'Ptr a',
> but in a way such that the compiler can't optimise away the
> box. Is that
> correct?
Yes, that's right.
> Could ForeignPtr be generalised so that its ForeignObj# could
> represent any type, rather than just a
At 2001-09-20 04:56, Simon Marlow wrote:
>ForeignPtrs are defined like this
>
> data ForeignPtr a = ForeignPtr ForeignObj#
>
>where ForeignObj# is a *boxed* address, it corresponds to a real heap
>object. The heap object is primitive from the point of view of the
>compiler - it can't be op
> Unfortunately it isn't possible to add a finalizer to a (Ptr a). We
> already have a generic finalization mechanism: see the Weak module in
> package lang. But the only reliable way to use finalizers(*) is to
> attach one to an atomic heap object - that way the compiler's
> optimiser
> can't
> If ForeignPtrs work the way I think they do, then I'm
> surprised they're
> designed as pointers. I believe the 'pointer' functionality
> is orthogonal
> to the 'finalisable' functionality and should be separated like this:
>
> --
> data Finalisable a-- abstract handle to finalisable ob
If ForeignPtrs work the way I think they do, then I'm surprised they're
designed as pointers. I believe the 'pointer' functionality is orthogonal
to the 'finalisable' functionality and should be separated like this:
--
data Finalisable a -- abstract handle to finalisable object
instance Eq
