I may be missing something obvious here, but from the current FFI spec
it appears that it is impossible to create libraries in haskell which
are meant to be called from c code without running into undefined
behavior. The problem is in the definition of
hs_init() and hs_exit()
.
now, it is accepta
Koen Claessen writes:
> * Stream processors (from Fudgets) are nice arrows:
>
> data SP a b = Get (a -> SP a b) | Put a (SP a b) | Nil
>
> But the first operator assumes that the product type
> associated with this arrow must be Haskell's product
> (,), but in fact a s
At 2002-05-25 01:32, Koen Claessen wrote:
>Might I remind you that an arrow (as defined in category
>theory) only requires identy and composition to be defined
>and satisfying some laws?
>
>In particular, an arrow does not have to have the operations
>"arr" and "first".
Well either "arrow" is be
I strongly suspect that arrows without arr could be quite useful... not
sure about ones without first.
--
Night. An owl flies o'er rooftops. The moon sheds its soft light upon
the trees.
David Feuer
___
Haskell mailing list
[EMAIL PROTECTED]
http://
On Sat, 25 May 2002, Koen Claessen wrote:
>
> There are many types which would fit nicely in an arrow
> framework, but do not because of the demand of these
> operators, here are two examples:
>
> * Isomorphisms, are nice arrows:
>
> type Iso a b = (a -> b, b -> a)
>
> but of course n
Wolfgang Jeltsch wrote:
| Now, I have a type which would fit wonderfully into
| the Arrow concept if arrows wouldn't be expected to
| have a first operator.
Ashley Yakeley replied:
| ...then it's not an Arrow.
Might I remind you that an arrow (as defined in category
theory) only requires i
