While implementing the full FFI for Hugs, I'm coming across a bunch of
little things that confuse me and some wee typos. Here's a list of
what I've found so far. If no-one objects in the next few days, I'll
go ahead and make minor changes to the report where required.
section 4.1.1:
The definition of impents suggests that there must/can be spaces
around the keywords 'dynamic' and 'wrapper' and that the static form
can have spaces at start and end. I'm going ahead and implementing
this interpretation but want to remark that it seems a bit odd.
No action proposed.
section 4.1.3:
It took me a while to understand the explanation of Dynamic import.
After a while, I realized that I should read the type as:
(FunPtr ft) -> ft
instead of
FunPtr (ft -> ft)
The current text 'FunPtr ft -> ft' does mean the former but it
would be easier to read if written '(FunPtr ft) -> ft'.
Proposed change: write the type as '(FunPtr ft) -> ft'
Incidentally, how am I to interpret the type rules?
Which of the following have the right type:
foreign import ccall "dynamic"
mkFun1 :: FunPtr (Int -> IO ()) -> (Int -> IO ())
type Int2 = Int
foreign import ccall "dynamic"
mkFun2 :: FunPtr (Int2 -> IO ()) -> (Int -> IO ())
newtype Int3 = Int3 Int
foreign import ccall "dynamic"
mkFun3 :: FunPtr (Int3 -> IO ()) -> (Int -> IO ())
data Int4 = Int4 Int
foreign import ccall "dynamic"
mkFun4 :: FunPtr (Int4 -> IO ()) -> (Int -> IO ())
type T5 = FunPtr (Int -> IO ()) -> (Int -> IO ())
foreign import ccall "dynamic" mkFun5 :: T5
Proposed change: none at present
section 5.5:
It's going to be really hard to implement ForeignPtr as specified.
The problem is that invocation of the cleanup function is triggered
by the garbage collector. I don't want the garbage collector to be
recursively invoked so I don't want the garbage collector to
directly invoke Haskell function. The Hugs garbage collector is not
supposed to be a mutator of the heap - so putting a simple wrapper
round the garbage colector won't work. And there's no mechanism
outside the GC to look for cleanup functions to execute.
GHC gets round this by scheduling a (preemptive) thread to execute
the cleanup code. How on earth does NHC get round this? Does
anyone have a suggestion for how it might be implemented in Hugs?
Proposed change: none at present but I'm deeply sceptical of a
design which takes a simple task (invoke a C cleanup function) and,
for no discernable reason, generalizes it to the point that it
requires a much more complex runtime system.
section 5.6:
castStablePtrToPtr and castPtrToStablePtr can break typesafety so
one might want to try to make sure that any program that uses them
will be forced to have the word 'unsafe' in them.
Proposed change: none at present
Table 2 (section 6):
Is there a reason to be so coy about the concrete C types used for
HsChar, HsFloat, HsDouble and HsBool?
Proposed change:
C symbol Haskell Symbol Constraint on concrete C type
HsChar Char unsigned char
HsFloat Float float
HsDouble Double double
HsBool Bool int
I see no reason at all not to specify HsBool.
For HsChar, I'd like to know if it is signed or unsigned.
I can imagine that the vague specification is to allow for wide
characters but it's not clear to me that one could write much portable
code without knowing that so it seems we should pick wide or narrow
characters and stick with it. (Hmmm, wonder how much code it would take
to make Hugs work with wide characters?)
For HsFloat/Double, I imagine we're being vague because Hugs
implements Double with single precision floats and GHC on the Alpha
(used to) implement Float with double precision floats. I think
Hugs can be fixed (in fact, was almost all done ages ago). That
leaves the question of whether we want to force Haskell implementations
to follow C conventions. I'm not sure.
Table 3 (section 6):
Proposed change:
Rename column 1 as 'Preprocessor symbol'.
In the last 2 lines, change column 1 to read HS_BOOL_FALSE
and HS_BOOL_TRUE. (This change merely standardizes the
existing GHC fix for this problem.)
--
Alastair Reid [EMAIL PROTECTED] http://www.cs.utah.edu/~reid/
_______________________________________________
FFI mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/ffi
