Mon, 04 Dec 2000 17:17:09 +1100, Manuel M. T. Chakravarty <[EMAIL PROTECTED]> pisze:
> So far, we have handled similar cases by using the inefficient
> variant as the "default" and adding a RULES pragma to get the
> efficient version. See, for example, the various IntXX to Int casts.
> We can us
[EMAIL PROTECTED] (Marcin 'Qrczak' Kowalczyk) wrote,
> Fri, 01 Dec 2000 12:53:19 +1100, Manuel M. T. Chakravarty <[EMAIL PROTECTED]>
>pisze:
>
> > To me it seems as if we should seperate conversion from
> > [Char] to [CChar] from the actual marshalling of CChar.
> > Why is it an advantage to lu
"Marcin 'Qrczak' Kowalczyk" <[EMAIL PROTECTED]> wrote,
> On Fri, 1 Dec 2000, Simon Peyton-Jones wrote:
>
> > if it's really so, we woudn't need the objectionable
> >
> > >withForeignObj :: ForeignObj -> (Ptr a -> IO b) -> IO b
> >
> > because all ForeignObj-manipulating things would be fo
On Fri, 1 Dec 2000, Simon Peyton-Jones wrote:
> if it's really so, we woudn't need the objectionable
>
> >withForeignObj :: ForeignObj -> (Ptr a -> IO b) -> IO b
>
> because all ForeignObj-manipulating things would be foreign
> imported
>
> foreign import f :: Window -> IO ()
It's
| So, how about the following? Instead of the
|
| newtype Window = Window ForeignObj
|
| way of wrapping foreign ADTs that we used so far, should we
| use
|
| newtype WindowTag = WindowTag ()
| typeWindow= ForeignObj WindowTag
A fine idea. I accept what you say about ADTs, but
[EMAIL PROTECTED] (Marcin 'Qrczak' Kowalczyk) wrote,
> Fri, 01 Dec 2000 13:10:43 +1100, Manuel M. T. Chakravarty <[EMAIL PROTECTED]>
>pisze:
>
> > Instead of the
> >
> > newtype Window = Window ForeignObj
> >
> > way of wrapping foreign ADTs that we used so far, should we
> > use
> >
> >
Fri, 01 Dec 2000 12:53:26 +1100, Manuel M. T. Chakravarty <[EMAIL PROTECTED]> pisze:
> > The second way is paranoid: do the same but export the type abstractly.
> > This is as safe as your solution, but uses the same style of interface
> > as non-paranoid solutions, and allows exporting the repre
Fri, 01 Dec 2000 12:53:19 +1100, Manuel M. T. Chakravarty <[EMAIL PROTECTED]> pisze:
> To me it seems as if we should seperate conversion from
> [Char] to [CChar] from the actual marshalling of CChar.
> Why is it an advantage to lump it all together?
Efficiency, and the fact that combined conver
Fri, 01 Dec 2000 13:10:43 +1100, Manuel M. T. Chakravarty <[EMAIL PROTECTED]> pisze:
> Instead of the
>
> newtype Window = Window ForeignObj
>
> way of wrapping foreign ADTs that we used so far, should we
> use
>
> newtype WindowTag = WindowTag ()
> typeWindow= ForeignObj Window
"Marcin 'Qrczak' Kowalczyk" <[EMAIL PROTECTED]> wrote,
> On Tue, 28 Nov 2000, Simon Peyton-Jones wrote:
>
> > Simon and I noticed this morning that ForeignObj should
> > really be parameterised.
>
> I was considering it too and IMHO it does not need to be parametrized.
>
> Values implemented a
"Marcin 'Qrczak' Kowalczyk" <[EMAIL PROTECTED]> wrote,
> On Thu, 23 Nov 2000, Manuel M. T. Chakravarty wrote:
>
> > I believe that this stuff belongs into the higher-level
> > marshalling library. In fact, it should be instances of
> > more general routines dealing with lists of Storable
> > el
"Marcin 'Qrczak' Kowalczyk" <[EMAIL PROTECTED]> wrote,
> On Tue, 28 Nov 2000 [EMAIL PROTECTED] wrote:
>
> > I think we should use symbolic error codes in Haskell, like the
> > `ENOENT' style in C. This is for portability, because as you may
> > know, on different operating systems, symbolic nam
> I'm with Manuel. Module FFI/Foreign is already stable, and I object
> to adding things to it arbitrarily. By all means make a new module
> with these functions, which I can see could be useful. But please
> don't just allow "feature creep" over already-agreed specifications.
Perhaps those fu
On Tue, 28 Nov 2000, Simon Peyton-Jones wrote:
> Simon and I noticed this morning that ForeignObj should
> really be parameterised.
I was considering it too and IMHO it does not need to be parametrized.
Values implemented as foreign objects are often exposed to the user of the
module. For this
On Tue, 28 Nov 2000 [EMAIL PROTECTED] wrote:
> I'm with Manuel. Module FFI/Foreign is already stable, and I object
> to adding things to it arbitrarily. By all means make a new module
> with these functions, which I can see could be useful. But please
> don't just allow "feature creep" over al
Dear foreigners
Simon and I noticed this morning that ForeignObj should
really be parameterised. The current type of newForeignObj is
newForeignObj :: Ptr a -> IO () -> IO ForeignObj
This immediately loses the type information on the Ptr!
Shouldn't it be
newForeignObj :: Ptr a -> IO () ->
On 28-Nov-2000, Simon Marlow <[EMAIL PROTECTED]> wrote:
> > [EMAIL PROTECTED] (Marcin 'Qrczak' Kowalczyk) wrote,
> > > -- Wrappers that convert the result to a possible exception.
> > > -- *_EINTR variants repeat the action if there was an error
> > > -- and errno == EINTR.
> > > t
Marcin proposes adding the following functions to the module Foreign:
> > peekCString:: Ptr CChar -> IO String
> > peekCStringLen :: Ptr CChar -> Int -> IO String
> >
> > withCString:: String -> (Ptr CChar -> IO a) -> IO a
> > withCStringLen :: String -> (Ptr CChar -> Int
On Tue, 28 Nov 2000, Simon Marlow wrote:
> arguably, withObject and newObject should be named with and new
> ("Object" is awfully vague and seems redundant anyway).
Indeed, but "with" is a keyword in -fglasgow-exts and Hugs :-(
I'm not happy with the fact that some with* functions look inside
t
> [EMAIL PROTECTED] (Marcin 'Qrczak' Kowalczyk) wrote,
>
> > qforeign got smaller because of changes in ghc, but what is ghc is
> > still a bit incomplete.
> >
> > Most important incompleteness is in string handling. Since ghc's
> > Unicode support is half-baked and it is not yet clear how
> th
On Thu, 23 Nov 2000, Manuel M. T. Chakravarty wrote:
> I believe that this stuff belongs into the higher-level
> marshalling library. In fact, it should be instances of
> more general routines dealing with lists of Storable
> elements.
Strings require more sophistication because their encoding
[EMAIL PROTECTED] (Marcin 'Qrczak' Kowalczyk) wrote,
> qforeign got smaller because of changes in ghc, but what is ghc is
> still a bit incomplete.
>
> Most important incompleteness is in string handling. Since ghc's
> Unicode support is half-baked and it is not yet clear how the library
> inter
22 matches
Mail list logo
