Re: Avoiding CAF's

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

Re: Avoiding CAF's

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

Re: Avoiding CAF's

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

Re: Avoiding CAF's

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

Re: Avoiding CAF's

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 ->

Re: Avoiding CAF's

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

RE: Avoiding CAF's

| 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

Re: Avoiding CAF's

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

Re: Avoiding CAF's

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

Re: Avoiding CAF's

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

RE: Avoiding CAF's

| -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

Avoiding CAF's

Hi, I'm trying to avoid CAF's being created, and I was wondering how is the best way to do it with GHC. For example: f = Can I attach {-# INLINE #-} to f, and expect the CAF to be removed that way? Is there any NOCAF annotation. I can always f _, then change the callers to f () - if I'm do