Wed, 29 Mar 2000 00:52:32 -0800, Simon Marlow <[EMAIL PROTECTED]> pisze:
> > data CLDouble = CLD# Double# -- ugh, plain newtype won't work
> > if we transparently pass newtypes' contents through FFI :-o
>
> could you elaborate?
If we say that "newtype A = A B" is passed to and from foreign
func
On 29-Mar-2000, Manuel M. T. Chakravarty <[EMAIL PROTECTED]> wrote:
> The code
>
> void *p;
> struct foo *x;
> struct bar *y;
>
> p = x; /* (1) */
> y = x; /* (2) */
>
> compiles at (1) without problems, but gives a warning at
> (2).
Actually whether it is an error or a warning is
Fergus Henderson wrote:
> Well, I certainly understand that not everyone is interested in
> reading all of the details in this FFI thread. But on the other
> hand, I don't think we should create a new mailing list for every
> new thread that generates a lot of discussion. [...]
It's already too
On 29-Mar-2000, Marcin 'Qrczak' Kowalczyk <[EMAIL PROTECTED]> wrote:
> Wed, 29 Mar 2000 15:00:46 +1000, Manuel M. T. Chakravarty <[EMAIL PROTECTED]>
>pisze:
>
> > > 6) Add HsBool with a mapping to an arbitrary integral C type, see Fergus'
> > >point about a Haskell API. (Should we guarantee
On 28-Mar-2000, Andy Gill <[EMAIL PROTECTED]> wrote:
>
> Don't mean to be rude chaps, but is there any way you can
> have this conversation without flooding haskell.org?
>
> How about a mailing list, on haskell.org, for FFI issues?
Well, I certainly understand that not everyone is interested in
> GHC folks, would it be a problem to allow transparent
> unwrapping of newtypes in foreign calls?
Shouldn't be a problem, I'll be happy to do it if that's what the conclusion
is.
I don't understand Qrczak's comment:
> data CLDouble = CLD# Double# -- ugh, plain newtype won't work
> if we transp
Andy Gill <[EMAIL PROTECTED]> wrote,
> Don't mean to be rude chaps, but is there any way you can
> have this conversation without flooding haskell.org?
>
> How about a mailing list, on haskell.org, for FFI issues?
I am sorry if you find that topic boring, but we already had
tons of email in a s
Wed, 29 Mar 2000 15:00:46 +1000, Manuel M. T. Chakravarty <[EMAIL PROTECTED]> pisze:
> > 6) Add HsBool with a mapping to an arbitrary integral C type, see Fergus'
> >point about a Haskell API. (Should we guarantee that False maps to 0 and
> >True to something <>0?)
>
> We don't make any
Fergus Henderson wrote:
>
> On 28-Mar-2000, Marcin 'Qrczak' Kowalczyk <[EMAIL PROTECTED]> wrote:
> > Tue, 28 Mar 2000 20:37:24 +1000, Fergus Henderson <[EMAIL PROTECTED]>:
Don't mean to be rude chaps, but is there any way you can
have this conversation without flooding haskell.org?
How about a
On 28-Mar-2000, Marcin 'Qrczak' Kowalczyk <[EMAIL PROTECTED]> wrote:
> Tue, 28 Mar 2000 20:37:24 +1000, Fergus Henderson <[EMAIL PROTECTED]> pisze:
>
> > The ANSI/ISO C standard does not guarantee that `wchar_t' will be
> > Unicode, or even that it will be large enough to hold Unicode.
> > I beli
Sven Panne <[EMAIL PROTECTED]> wrote,
> Regarding 1. Mapping Haskell types to C types:
> ===
>
> 2) It should be *guaranteed* that HsStablePtr and HsAddr are mapped to
>void* for the reason mentioned by Manuel. Neverthel
Fergus Henderson <[EMAIL PROTECTED]> wrote,
> On 28-Mar-2000, Manuel M. T. Chakravarty <[EMAIL PROTECTED]> wrote:
> > [EMAIL PROTECTED] (Marcin 'Qrczak' Kowalczyk) wrote,
> > > What woyld GtkText* map to? GtkText is a typedef to an opaque struct.
> >
> > One idea that we discussed is that `GtkTe
Fergus Henderson <[EMAIL PROTECTED]> wrote,
> On 28-Mar-2000, Manuel M. T. Chakravarty <[EMAIL PROTECTED]> wrote:
> > Sven Panne <[EMAIL PROTECTED]> wrote,
> > > 1) Although the Haskell 98 report states that Char should be a Unicode
> > >character, a plain char is used here. No implementation
[EMAIL PROTECTED] (Marcin 'Qrczak' Kowalczyk) wrote,
> Tue, 28 Mar 2000 18:25:27 +1000, Manuel M. T. Chakravarty <[EMAIL PROTECTED]>
>pisze:
>
> > One idea that we discussed is that `GtkText*' would map to
> > `Ptr GtkText', where `GtkText' is opaque und would indeed be
> > implemented as
> >
Tue, 28 Mar 2000 14:52:56 +0200, Sven Panne <[EMAIL PROTECTED]>
pisze:
> 1) To be honest, I don't know enough about char/wchar_t/Unicode/ISO-10646
>to make suggestions here. Could somebody more knowledgeable make a
>proposal how these should be handled in the FFI? Keep in mind that this
Tue, 28 Mar 2000 14:52:56 +0200, Sven Panne <[EMAIL PROTECTED]>
pisze:
[...]
Strange: I agree in every point!
> 3) If ISO C has long long (don't know, my copy of Harbison/Steele doesn't
>mention it), Int64/Word64 should be made mandatory.
C99, the recently approved ISO C standard, does ha
Fergus Henderson wrote:
> [...] For prior art, see the `Interfaces.C' package in normative
> Annex E of the Ada 95 standard (available via www.ada.org).
My Ada is a little bit rusty, but what I've understood from
http://lglwww.epfl.ch/Ada/rm95/rm9x-B-03.html is the following:
* Interfaces.C c
Julian Assange wrote:
> Have you looked at the nice (un-)marshaling features of Ocaml? The
> implementation is such that fist class functions can be marshaled,
> un-marshaled and subsequently executed, even for natively compiled
> code. [...]
I can't find documentation for the things you mention.
*sigh* I never thought that the "last words" on this topic would be easy,
but on the other hand I never imagined that ISO/ANSI C, POSIX, Unicode,
ISO-10646, Ada95, OCaml, persistent functions, etc. will pop up... It's
surely worth having a look at things other people have done, but here are
some i
On Tue, 28 Mar 2000, Fergus Henderson wrote:
> `struct HsStablePtrSomeUserDefinedTypeConstructor *'.
>
> Actually on second thoughts I think that should perhaps be just
>
> `struct HsSomeUserDefinedTypeConstructor *'
>
> and likewise for all the other mappings from `StablePtr' type
Tue, 28 Mar 2000 20:37:24 +1000, Fergus Henderson <[EMAIL PROTECTED]> pisze:
> The ANSI/ISO C standard does not guarantee that `wchar_t' will be
> Unicode, or even that it will be large enough to hold Unicode.
> I believe that the Unicode consortium recommends against using
> `wchar_t' for Unicod
On 28-Mar-2000, Marcin 'Qrczak' Kowalczyk <[EMAIL PROTECTED]> wrote:
> Tue, 28 Mar 2000 20:14:26 +1000, Fergus Henderson <[EMAIL PROTECTED]> pisze:
>
> > For type constructors like `->', `[]', and `Maybe', which (unlike
> > StablePtr) don't have any C equivalent, I think you probably need
> > to
On 28-Mar-2000, Manuel M. T. Chakravarty <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] (Marcin 'Qrczak' Kowalczyk) wrote,
> > What woyld GtkText* map to? GtkText is a typedef to an opaque struct.
>
> One idea that we discussed is that `GtkText*' would map to
> `Ptr GtkText', where `GtkText' is o
Tue, 28 Mar 2000 20:14:26 +1000, Fergus Henderson <[EMAIL PROTECTED]> pisze:
> For type constructors like `->', `[]', and `Maybe', which (unlike
> StablePtr) don't have any C equivalent, I think you probably need
> to drop the structure, and just keep the top-level type constructor,
> thus mappin
On 28-Mar-2000, Manuel M. T. Chakravarty <[EMAIL PROTECTED]> wrote:
> Sven Panne <[EMAIL PROTECTED]> wrote,
> > 1) Although the Haskell 98 report states that Char should be a Unicode
> >character, a plain char is used here. No implementation uses Unicode so
> >far, and char is what one wan
On 28-Mar-2000, Marcin 'Qrczak' Kowalczyk <[EMAIL PROTECTED]> wrote:
> Tue, 28 Mar 2000 12:26:34 +1000, Fergus Henderson <[EMAIL PROTECTED]> pisze:
>
> > It would be fine to have a `typedef void *HsStablePtr'. But it is important
> > that you do not lose static type information when exporting Ha
Tue, 28 Mar 2000 18:25:27 +1000, Manuel M. T. Chakravarty <[EMAIL PROTECTED]> pisze:
> One idea that we discussed is that `GtkText*' would map to
> `Ptr GtkText', where `GtkText' is opaque und would indeed be
> implemented as
>
> newtype GtkText = GtkText ()
And Ptr is what?
"type Ptr a = A
[EMAIL PROTECTED] (Marcin 'Qrczak' Kowalczyk) wrote,
> Tue, 28 Mar 2000 12:26:34 +1000, Fergus Henderson <[EMAIL PROTECTED]> pisze:
>
> > It would be fine to have a `typedef void *HsStablePtr'.
> > But it is important that you do not lose static type
> > information when exporting Haskell functi
Sven Panne <[EMAIL PROTECTED]> wrote,
> 1. Mapping Haskell types to C types
> ===
> Writing C code which gets called via Haskell's FFI is complicated by the
> fact that one needs to know the C types corresponding to Haskell's
Tue, 28 Mar 2000 12:26:34 +1000, Fergus Henderson <[EMAIL PROTECTED]> pisze:
> It would be fine to have a `typedef void *HsStablePtr'. But it is important
> that you do not lose static type information when exporting Haskell functions
> to C. So a parameter of type `StablePtr Int' on the Haskel
On 27-Mar-2000, Sven Panne <[EMAIL PROTECTED]> wrote:
> Yes, C programmers are not that lazy. :-)
>
> > What if you want to pass an unevaluated closure (e.g. so that you
> > can later pass it back to Haskell and then evaluate it)?
>
> This is what stable pointers are for and they are covered by
Sven Panne <[EMAIL PROTECTED]> writes:
> itself and that compound values are a case for a (un-)marshaling
> library. We already have some ideas what this lib should look like
> and some slightly differing modules for this exist, see e.g. C->HS,
> the MPI binding or HOpenGL. Before a design for th
Sven Panne <[EMAIL PROTECTED]> writes:
> 1) Although the Haskell 98 report states that Char should be a Unicode
>character, a plain char is used here. No implementation uses Unicode so
>far, and char is what one wants most of the time, anyway.
HBC uses unicode for source. I'm not sure if
Fergus Henderson wrote:
> On 28-Mar-2000, Fergus Henderson <[EMAIL PROTECTED]> wrote:
> > For prior art, see the `Interfaces.C' package in normative
> > Annex E of the Ada 95 standard (available via www.ada.org).
>
> Sorry, that URL is not correct. In fact that is the American
> Dentists Associa
Fergus Henderson wrote:
> > [...] 1. Mapping Haskell types to C types [...]
> This mapping assumes that you want the unboxed types in C.
Yes, C programmers are not that lazy. :-)
> What if you want to pass an unevaluated closure (e.g. so that you
> can later pass it back to Haskell and then eval
Tue, 28 Mar 2000 02:22:46 +1000, Fergus Henderson <[EMAIL PROTECTED]> pisze:
> This mapping assumes that you want the unboxed types in C. What if
> you want to pass an unevaluated closure (e.g. so that you can later
> pass it back to Haskell and then evaluate it)?
StablePtr is already there.
>
Mon, 27 Mar 2000 16:15:45 +0200, Sven Panne <[EMAIL PROTECTED]>
pisze:
> The time has come for another "final" :-} word on the low-level API for
> Haskell's foreign function interface.
What about the high-level API (apart from C2HS)?
> To solve this problem, every Haskell implementation should
On 28-Mar-2000, Fergus Henderson <[EMAIL PROTECTED]> wrote:
> For prior art, see the `Interfaces.C' package in normative Annex E of
> the Ada 95 standard (available via www.ada.org).
Sorry, that URL is not correct. In fact that is the American Dentists Association
(ADA) home page, not the Ada pr
On 27-Mar-2000, Sven Panne <[EMAIL PROTECTED]> wrote:
>1) Mapping Haskell types to C types
>2) Mapping C types to Haskell types
These two are a good idea.
For prior art, see the `Interfaces.C' package in normative Annex E of
the Ada 95 standard (available via www.ada.org).
>3) Byte o
On Mon, 27 Mar 2000, Sven Panne wrote:
[snip]
> Haskell type |C type| ... is probably | Range
> -+--+-+---
> Char | HsChar | char (1)| HsCharMin .. HsCharMax
[snip]
> Remarks:
> ===
The time has come for another "final" :-} word on the low-level API for
Haskell's foreign function interface. It is nothing very deep and most of
it already exists in one form or the other, but I'd like to have some
feedback before I start hacking this into GHC. Additions are proposed in 3
areas:
41 matches
Mail list logo
