Nobody answered, so perhaps everybody agrees :-)
Sat, 03 Feb 2001 00:14:56 +1100, Manuel M. T. Chakravarty <[EMAIL PROTECTED]> pisze:
> Re (2): In Java, we obviously want to use qualified names
> (like "java.lang.foo"), but in the case of dynamic
> libraries and C calls it is less clear what
> 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
[Better a late answer than none :-/ ]
"Alastair Reid" <[EMAIL PROTECTED]> wrote,
> > 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 se
> "Alastair Reid" <[EMAIL PROTECTED]> wrote,
>
> > Marcin wrote:
> > > 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
Wed, 21 Feb 2001 11:41:07 -0700, Alastair Reid <[EMAIL PROTECTED]> pisze:
> The point of me mail was that instead of using half the features
> of cpp (Marcin gave an example which used #ifdef) and extending the
> ffi spec to do the other half, he could use all the features of cpp
> (#ifdef and #d
> Perhaps it should be integrated with proposed Malcolm's scheme of
> structured module hierarchy. It's not obvious how ghc's packages fit
> into this idea.
I'm not sure either, but we haven't seen the proposal yet :)
Simon
___
FFI mailing list
[EMAI
> If we want to rule cpp as out of bounds (a very worthwhile
> but difficult goal),
> then we need to think about how to avoid conditional compilation too.
I think the goal is not to avoid the use of cpp, but rather to avoid
mentioning it in the spec. In practice, many people will be using cpp
13 matches
Mail list logo
