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
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
> 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
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
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:
> ===
36 matches
Mail list logo
