Neil Mitchell wrote:
Hi Simon,
Ok, but suppose you get some good results - what's the point? None of
this is
guaranteed to work tomorrow. Why not aim for a robust translation
into Core
that preserves the semantics? It can't be that hard to pass around a
State#
RealWorld, can it?
Is ther
Hi Simon,
Ok, but suppose you get some good results - what's the point? None of this is
guaranteed to work tomorrow. Why not aim for a robust translation into Core
that preserves the semantics? It can't be that hard to pass around a State#
RealWorld, can it?
Is there a paper/document that g
Hi
>case Main.$wccall GHC.Prim.realWorld# of wild_X28 { (# ds_d2ad,
> ds1_d2ac #) ->
>
> i.e. it has had an artificial box put around the answer. It may be
> impossible to eliminate this, but if it is, I'd like to try.
There's no actual box here. The ccall returns an unboxed tuple with two
Neil Mitchell wrote:
Hi Ian and Simon,
Ian said:
Does the boxing not get optimised out?
Is the FFI imported function exported from the module?
http://hpaste.org/1882 (replicated at the end of this message in case
the hpaste is not around forever, but clearly layout and syntax
colouring)
That
Hi
http://hpaste.org/1882 (replicated at the end of this message in case
the hpaste is not around forever, but clearly layout and syntax
colouring)
For completeness, the code in question is:
Main.$wccall [NEVER Nothing] :: GHC.Prim.State# GHC.Prim.RealWorld
->
Hi Ian and Simon,
Ian said:
Does the boxing not get optimised out?
Is the FFI imported function exported from the module?
http://hpaste.org/1882 (replicated at the end of this message in case
the hpaste is not around forever, but clearly layout and syntax
colouring)
Thats the main branch, whi
| I remember the reason that was unsatisfactory now. The RULES only fire
| at high optimisation levels, whereas for this particular program the
| CAF/unCAF-ness of a function effects whether the program gives the
| correct answer.
That is indeed scary. Would you like to give a small example of su
On Wed, May 16, 2007 at 02:22:22PM +0100, Neil Mitchell wrote:
>
> The FFI call must create a IO monad box to put the thing in, then the
> main loop strips the IO box away. If I could avoid the overhead of
> creating the box in the meantime, that would be preferable.
Does the boxing not get optim
Hi
> See this thread:
>
> http://www.nabble.com/%7B---INLINE-me_harder---%7D-tf3599366.html
I'll try and see if I can do this with RULES.
I remember the reason that was unsatisfactory now. The RULES only fire
at high optimisation levels, whereas for this particular program the
CAF/unCAF-ness
Hi
See this thread:
http://www.nabble.com/%7B---INLINE-me_harder---%7D-tf3599366.html
I'll try and see if I can do this with RULES.
| foreign import ccall safe "stdio.h getchar" getchar2 :: CInt
|
| Can I stop this being CAF'd in any way?
What is the problem you are trying to solve?
I h
| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
| Behalf Of Neil Mitchell
| Sent: 16 May 2007 10:16
| To: glasgow-haskell-users@haskell.org
| Subject: Avoiding CAF's
|
| Hi,
|
| I'm trying to avoid CAF's being created, and I was wondering how is
| the best way
11 matches
Mail list logo