On 7/21/06, Taral <[EMAIL PROTECTED]> wrote:
On 7/20/06, Evan Martin <[EMAIL PROTECTED]> wrote:
> The tricky part is that to pass in Haskell functions, I need to use
> the FFI "wrapper" import, which means I need to later free them. But
> the only place I can free them is within the "free" callb
On 7/20/06, Evan Martin <[EMAIL PROTECTED]> wrote:
To elaborate, the code setting this up looks something like this:
callback_fcn <- ... -- get a FunPtr using "wrapper" from the ffi
free_fcn <- ... -- as above
-- the callback data is just stuff that needs freeing
callback_data <- newStabl
On 7/20/06, Evan Martin <[EMAIL PROTECTED]> wrote:
The tricky part is that to pass in Haskell functions, I need to use
the FFI "wrapper" import, which means I need to later free them. But
the only place I can free them is within the "free" callback, and I've
just discovered this isn't allowed!
On Thu, Jul 20, 2006 at 10:48:02AM -0600, Rodney D Price wrote:
>
> I've gotten this sort of error several times, which mysteriously
> disappears when I add more functions to the code:
>
> storeError.hs:13:38:
> Couldn't match expected type `a' (a rigid variable)
>against inferr
I've gotten this sort of error several times, which mysteriously
disappears
when I add more functions to the code:
storeError.hs:13:38:
Couldn't match expected type `a' (a rigid variable)
against inferred type `String'
`a' is bound by the type signature for `throwError'
Evan Martin wrote:
Suppose I have a C function like this:
void register_callback(
void (*callback_fcn)(void *data),
void *callback_data,
void (*free_fcn)(void *data));
I think this is pretty common in C libraries. The idea is that you
can register a callback along with a pointer to som
Suppose I have a C function like this:
void register_callback(
void (*callback_fcn)(void *data),
void *callback_data,
void (*free_fcn)(void *data));
I think this is pretty common in C libraries. The idea is that you
can register a callback along with a pointer to some data to pass to
it
--- [EMAIL PROTECTED] wrote:
> Do you have an example of use of seq on
a function type? (Of course I
> don't want to ban it, just change its behaviour.)
I don't have any wisdom to offer on how we would want to ban or change
the behavior of seq on a function type without using type classes. Nor
On Wed, 19 Jul 2006, Duncan Coutts wrote:
Ah ok, I misunderstood. Well that'd be a bit odd too. No other function
behaves differently on different types except by use of type classes.
I agree it is quite odd, but the seq we have is already quite odd.
Furthermore, the fact is that seq on func
On Wed, 2006-07-19 at 08:09 -0400, [EMAIL PROTECTED] wrote:
> On Tue, 18 Jul 2006, Duncan Coutts wrote:
>
> > On Tue, 2006-07-18 at 09:44 -0400, [EMAIL PROTECTED] wrote:
> >> Would the problematic semantics of seq be resolved if seq did nothing on
> >> function types? That is to say
> >>
> >> seq
On Tue, 18 Jul 2006, Duncan Coutts wrote:
On Tue, 2006-07-18 at 09:44 -0400, [EMAIL PROTECTED] wrote:
Would the problematic semantics of seq be resolved if seq did nothing on
function types? That is to say
seq (\x -> undefined `asTypeOf` x) y reduced to y
and
seq (undefined `asTypeOf` id) y
[Apologies if you receive this more than once]
==
Call for Workshop Papers
ICDM'06: The 6th IEEE International Conference on Data Mining
Hong Kong Convention and Exhibition Centre, Hong Kong, China,
18-22 December 2006
Sponsored by
[Apologies if you receive this more than once]
==
Call for Workshop Papers
2006 IEEE/WIC/ACM International Joint
Conference on Web Intelligence and Intelligent Agent Technology
(WI-IAT'06)
Hong Kong Convention and Exhibition Centre, Hon
13 matches
Mail list logo
