[EMAIL PROTECTED] (Marcin 'Qrczak' Kowalczyk) wrote,
> Thu, 17 Aug 2000 18:53:04 +1000, Manuel M. T. Chakravarty <[EMAIL PROTECTED]>
>pisze:
>
> > > foreignObjToPtr :: (Ptr a -> IO b) -> ForeignObj -> IO b
>
> > * Shouldn't we use
> >
> > foreignObjToPtr :: ForeignObj -> (Ptr a -> IO b) -> IO b
>
> Maybe. I considered this too and generally cannot decide myself in
> such cases, where function can be second because it's usually larger,
> but putting it first creates a "function transformer".
>
> The former type gives IMHO better order in case the peeking functions
> is short - the same order as it would be with pointers:
>
> fileOwner:: FileStatus -> UserID
> fileOwner (FS obj) = unsafePerformIO $
> foreignObjToPtr (#peek struct stat, st_uid) obj
>
> BTW, I use your order in
> ptrTo :: Storable a => a -> (Ptr a -> IO b) -> IO b
> but the reverse in convertArg method (which often = id), and thus
> instance Storable a => ForeignArg (Ptr a) a where
> convertArg f x = ptrTo x f
>
> I'll switch the argument order. IMHO it should be called openForeignObj
> or withForeignObj; aToB suggests the type A -> B.
I like withForeignObj.
fileOwner:: FileStatus -> UserID
fileOwner (FS obj) = unsafePerformIO $
withForeignObj obj (#peek struct stat, st_uid)
also looks good, I think.
> "touch:: ForeignObj -> IO ()" is the primitive needed for that.
> In current ghc NOINLINEd "\_ -> return ()" on ForeignObj# is the best
> implementation known to me, but a primop would be more efficient.
Simon, what do you think about having such a primop?
> > * Does GHC usually do inlining here?
>
> In my experiments yes. fileOwner is compiled to nested STG cases.
>
> ConvertArg class uses a higher order function for each argument
> and GHC nicely optimizes their calls (and overloading) away, except
> big functions.
Ok, fine.
Cheers,
Manuel
