> I can't remember whether this has come up before, but to my surprise
> I've just discovered that FFI foreign import declarations don't
> contain enough infomration to be able to determine the correct
> calling convention for a given C function.
I'd say it has all the information you need - you
> The implementation is just something like
>addIOErrorLocAndPath loc path io
>= catch io (\err -> ioError err{loc=loc,path=path})
This reminds me of _scc_:
1) We're annotating the code with programmer-meaningful annotations
which are then used at runtime to help them und
D Tweed <[EMAIL PROTECTED]> writes:
>>> Other than being inelegant, is there anything to prevent me
>>> trying to hack on a stage in the foreign code interface stuff
>>> that compares the output of `nm' and `nm --demangle' [...]
Alastair wrote:
>> I don't see a fundamental problem - but it does
Marcin:
> | > PtrDiff
SimonPJ:
> I must say that I rather agree with Marcin here. Let's just use Int
> (but not Int32!). On machines with big address spaces, Ints will be
> big. Keep it simple. Oh, and efficient!
For all the reasons I've used in the past of avoiding future problems
(especial
Malcolm writes:
> Now that we have the opportunity to define a sensible overflow
> behaviour for fixed size types, I think we should take it.
I strongly support Malcolm's proposal.
(Which is, of course, to maintain the status quo.)
I can think of 2 situations where we would not want this:
1) W
> NHC's current implementation of "foreign export"
>
>> From the discussion, it seems that NHC simply allows the
> phrase "foreign export" in front of the normal type signature of a
> function (as opposed to in addition to that type signature). I
Sven Panne <[EMAIL PROTECTED]> writes:
> I think it boils down to the following: For every calling convention
> there is a fixed set of primitive types which the Haskell system
> must know about, e.g. CInt, CFloat, Ptr a, ... for ccall/stdcall.
I haven't been following the Storable stuff very c
Marcin 'Qrczak' Kowalczyk <[EMAIL PROTECTED]> writes:
> Would anyone really use explicit "static"?
I would.
Even if rarely used, I think it is easier to teach people to use it if
we say there are two forms of definition (safe and unsafe, static and
dynamic, etc.) and then later teach them th
