[EMAIL PROTECTED] (Marcin 'Qrczak' Kowalczyk) wrote,
> Sun, 07 Jan 2001 13:15:21 +1100, Manuel M. T. Chakravarty <[EMAIL PROTECTED]>
>pisze:
>
> > > When someone really wants to use mallocCString and pokeCString now
> > > (knowing that there is a little point of doing that in the case of
> > > c
On 04-Jan-2001, Marcin 'Qrczak' Kowalczyk <[EMAIL PROTECTED]> wrote:
> foreign export dynamic is harder. It must wrap a Haskell function
> (closure) in a C function pointer. It is not possible to do this
> portably in C: function pointers are normally only pointers to elements
> of the finite set
Sun, 07 Jan 2001 12:16:15 +1100, Manuel M. T. Chakravarty <[EMAIL PROTECTED]> pisze:
> I think, we need the alloca and realloc versions, too.
We can't have malloc, alloca, realloc or poke. Only peek, with and new.
We can't have poke because in general the space needed for the
converted string i
Sven Panne <[EMAIL PROTECTED]> wrote,
> Marcin 'Qrczak' Kowalczyk wrote:
> > [...] If language separation is realistic, we would also keep
> > errno handling outside basic Foreign.
>
> Hmmm, indeed. `CErrors' or `CErrno' would be a good name IMHO.
`CError' by our current naming scheme.[1]
> >
[EMAIL PROTECTED] (Marcin 'Qrczak' Kowalczyk) wrote,
> Sat, 06 Jan 2001 00:24:14 +0100, Sven Panne <[EMAIL PROTECTED]>
>pisze:
>
> > For performance there's always #ifdef (well, at least if we
> > consider piping Haskell sources through cpp as "standard"/H98).
>
> hsc2hs used instead of cpp pr
[EMAIL PROTECTED] (Marcin 'Qrczak' Kowalczyk) wrote,
> Sat, 06 Jan 2001 22:37:35 +1100, Manuel M. T. Chakravarty <[EMAIL PROTECTED]>
>pisze:
>
> > If there were a faster alloca, it would still speed up the
> > common case where there is no conversion or the initial size
> > estimate is correct.
[EMAIL PROTECTED] (Marcin 'Qrczak' Kowalczyk) wrote,
> Sat, 06 Jan 2001 21:58:26 +1100, Manuel M. T. Chakravarty <[EMAIL PROTECTED]>
>pisze:
>
> > > type CString= Ptr CChar
> > > type CStringLen = (CString, Int)
> >
> > Hmmm, yes, although pointer/length pairs are not very common
>
Sven Panne <[EMAIL PROTECTED]> wrote,
> > [ MarshalString ]
> > Hmmm, yes, although pointer/length pairs are not very common
> > in C and this module is a language dependent module (and so
> > should be called `MarshalCString').
>
> Granted. And remember we already have a (quite ugly) module CSt
Sven Panne <[EMAIL PROTECTED]> wrote,
> "Manuel M. T. Chakravarty" wrote:
> > [...] I see your point, however, personally, I still prefer to
> > have overloading for the common cases (that what we want
> > most of the time when given a particular type) and use
> > explicit functions only for the
Sun, 07 Jan 2001 13:15:21 +1100, Manuel M. T. Chakravarty <[EMAIL PROTECTED]> pisze:
> > When someone really wants to use mallocCString and pokeCString now
> > (knowing that there is a little point of doing that in the case of
> > conversions), he can use mallocArray0 and pokeArray0, after castin
Sun, 07 Jan 2001 16:16:00 +1100, Manuel M. T. Chakravarty <[EMAIL PROTECTED]> pisze:
> BTW, shall we really seperate CString and CStringLen into
> two different modules? I am all for modularisation, but in
> this case I am not sure whether it is worth it.
I would put them in one module, especia
11 matches
Mail list logo
