> As usual the FFI "looks through" newtypes. But now that we have
> FunPtr, the following typing makes much more sense:
>
>'foreign' 'export' [callconv] 'dynamic' varid :: prim_type
> -> IO (FunPtr prim_type)
>
> where both prim_types have to be the *same*. We should probably allow
> the
> Yes, Addr is dead. So, allowing Addr in f.e.d., or anywhere
> else for that matter, can only be for reasons of temporary
> backward compatibility.
Please note that this temporary backward compatability happens to be an
important part of most ffi code currently in existence (at least, all the c
> This has the advantage that when the library name is #ifdefed, the
> conditional needs not to be repeated for each function. Similarly
> for #included header names.
Note that this can be done without separating the library name from the ffi
decl:
#ifdef UNIX
# define LIBNAME "foo.so"
#else
# d
Manuel writes:
> Summary of Open Points
> ~~
>
> - Language specifiers: Other names for "ccall" (possibly, "c")
> and "stdcall".
I'm not totally convinced that a change from "ccall" to "c"
is justified. In fact, the foreign language could be anything at
all - mercury, per
> > Is it reasonable to require that only foreign declarations of
> > a *single* foreign language are allowed per Haskell module?
>
> We can have some declaration
> specifying the context of *following* foreign declarations. Another
> such declaration can change the context later in the module.
Mon, 12 Feb 2001 09:50:07 -0700, Alastair Reid <[EMAIL PROTECTED]> pisze:
> Note that this can be done without separating the library name from
> the ffi decl:
>
> #ifdef UNIX
> # define LIBNAME "foo.so"
> #else
> # define LIBNAME "foo.dll"
> #endif
>
> foreign import ... LIBNAME ...
> foreign
> > What does all this complexity buy us?
>
> The ability to specify #include files in a portable way,
Can this not be done with one small extension instead of a much larger general
purpose extension?
> If a Haskell implementation needs to know from which library to take
> which function, e.g. a
Mon, 12 Feb 2001 17:27:36 +, [EMAIL PROTECTED] <[EMAIL PROTECTED]>
pisze:
> > We can have some declaration specifying the context of *following*
> > foreign declarations. Another such declaration can change the
> > context later in the module.
>
> Please no!
OK, my current favourite is to
Mon, 12 Feb 2001 11:39:12 -0700, Alastair Reid <[EMAIL PROTECTED]> pisze:
> > The ability to specify #include files in a portable way,
>
> Can this not be done with one small extension instead of a much
> larger general purpose extension?
I prefer a not too large but generic feature - to one sm
Alastair Reid wrote:
> [...] ps I have a feeling of feeping creaturism as I watch this list -
> a nice simple design seems to be getting more complex.
Could you elaborate on this? The basic FFI *is* still nice and simple
IMHO. Mentioning plain Addr in it was a design mistake because:
* Pointe
> Alastair Reid wrote:
> > [...] ps I have a feeling of feeping creaturism as I watch this list -
> > a nice simple design seems to be getting more complex.
>
> Could you elaborate on this? The basic FFI *is* still nice and simple
> IMHO.
I'm thinking of:
1) Trying to support a complex language
Mon, 12 Feb 2001 15:49:45 -0700, Alastair Reid <[EMAIL PROTECTED]> pisze:
> 1) Trying to support a complex language like Java in the same design
> (or in any design, really)
Java support has no impact on C support: you can ignore it if you like.
The design as is is quite language-independent (an
On 13-Feb-2001, Marcin 'Qrczak' Kowalczyk <[EMAIL PROTECTED]> wrote:
> Mon, 12 Feb 2001 15:49:45 -0700, Alastair Reid <[EMAIL PROTECTED]> pisze:
> > >* Pointers to code and data need not have the same size.
> >
> > I understand this argument though I'm not sure which architectures
> > this ap
13 matches
Mail list logo
