-users-
| [EMAIL PROTECTED] On Behalf Of Brian Hulley
| Sent: 30 March 2006 03:50
| To: glasgow-haskell-users@haskell.org
| Subject: Re: Possible runtime overhead of wrapping the IO monad?
|
| Brian Hulley wrote:
| With -O2 enabled, __ccall_GC duma_vertex3f is indeed called directly
| instead
Simon Peyton-Jones wrote:
Brian
I've committed a fix for this. By which I mean that you don't need to
write dropRenderM. You can just use RenderM as if it were IO.
The change won't be in 6.4.2, but it's in the HEAD and will be in 6.6
Thanks!
Cheers, Brian.
On Thursday 30 March 2006 14:13, Brian Hulley wrote:
John Meacham wrote:
On Thu, Mar 30, 2006 at 03:50:06AM +0100, Brian Hulley wrote:
where the intention is that the callback will take the width and
height of the window and return a RenderM action, the problem is
that because the FFI
Benjamin Franksen wrote:
[snip]
Thus, GHC does nothing wrong, according to the addendum. That doesn't
mean allowing IO-equivalent newtypes wouldn't be a good idea. It is
just not written in the addendum.
Apologies for not reading the addendum properly and slighting the good
character of
John Meacham wrote:
On Thu, Mar 30, 2006 at 03:50:06AM +0100, Brian Hulley wrote:
where the intention is that the callback will take the width and
height of the window and return a RenderM action, the problem is
that because the FFI does not allow RenderM to appear in a foreign
type.
it
| -Original Message-
| From: [EMAIL PROTECTED]
[mailto:glasgow-haskell-users-
| [EMAIL PROTECTED] On Behalf Of Brian Hulley
| Sent: 30 March 2006 13:14
| To: John Meacham; glasgow-haskell-users@haskell.org
| Subject: Re: Possible runtime overhead of wrapping the IO monad?
|
| John
Simon Peyton-Jones wrote:
GHC does unwrap newtype result types, as in
foreign import foo :: Int - IO Boogle
newtype Boogle = B Int
which is what the manual meant. I'd never thought of newtyping the IO
monad itself. Why are you doing that, incidentally?
I'm designing a simple API for
Brian Hulley wrote:
With -O2 enabled, __ccall_GC duma_vertex3f is indeed called directly
instead of vertex3f, from a different module, so that proves that
different monads can indeed be used to wrap IO operations without any
performance penalty at all.
However I've just discovered there *is* a
On Thu, Mar 30, 2006 at 03:50:06AM +0100, Brian Hulley wrote:
where the intention is that the callback will take the width and height of
the window and return a RenderM action, the problem is that because the FFI
does not allow RenderM to appear in a foreign type.
it should, the types in
Duncan Coutts wrote:
Because ghc does compile via C and does use the C header files to get
the C function prototype. Well it can compile via C and it's
recommended when compiling FFI code since it allows the Haskell type
you've declared to be checked against the C prototype.
[snip]
There are
Brian Hulley wrote:
I've found a thread at
http://www.haskell.org//pipermail/ffi/2002-July/000554.html where
someone else asked the same question, but apart from the problem of
'const' , and the desire to verify the actual type of the C function, I
can't find any convincing case for
Hi,
I'm designing an API for a simple graphics window, and am trying to make the
correct usage of the API functions explicit and visible to the type system
by using different monads which ultimately just wrap the IO monad. For
example, in a callback for rendering stuff to the screen, only
Brian Hulley wrote:
Hi,
I'm designing an API for a simple graphics window, and am trying to make
the correct usage of the API functions explicit and visible to the type
system by using different monads which ultimately just wrap the IO
monad. For example, in a callback for rendering stuff to
Chris Kuklewicz wrote:
Brian Hulley wrote:
Hi,
I'm designing an API for a simple graphics window, and am trying to
[snip]
There should be no overhead for a newtype. The above can be
shortened to one line:
newtype VertexM a = VertexM (IO a) deriving (Functor,Monad,MonadIO)
Thanks - that
On Mon, Mar 27, 2006 at 08:14:40PM +0100, Brian Hulley wrote:
However I'm wondering if I can rely on all this monad stuff being optimized
out at compile time. A sample monad is below:
newtype VertexM a = VertexM (IO a)
in GHC you can actually guarentee there is no overhead with the
On Tue, 2006-03-28 at 01:37 +0100, Brian Hulley wrote:
Hi Duncan -
I just declared duma_vertex3f (in another module) by:
foreign import ccall duma_vertex3f :: Float - Float - Float - IO ()
I thought this means that the C function prototype must be:
void duma_vertex3f(HsFloat,
16 matches
Mail list logo
