marlowsd:
> Claus Reinke wrote:
Here is a trivial example with drastic difference between
T = Int and T = Word (~2.5x here):
main = print $ foldl' (+) 0 [1..1::T]
>> ..
>
>> A quick grep shows almost no specialization at all for Word, or for
>> IntXX/WordXX (see below
claus.reinke:
>>> Here is a trivial example with drastic difference between
>>> T = Int and T = Word (~2.5x here):
>>>
>>>main = print $ foldl' (+) 0 [1..1::T]
> ..
>>>GHC.Prim.word2Int#
>>>(GHC.Prim.and#
>>>(GHC.Prim.int2Word# wild13_XbE)
>>>(GHC.Pri
claus.reinke:
>>> Here is a trivial example with drastic difference between
>>> T = Int and T = Word (~2.5x here):
>>>
>>>main = print $ foldl' (+) 0 [1..1::T]
> ..
>>>GHC.Prim.word2Int#
>>>(GHC.Prim.and#
>>>(GHC.Prim.int2Word# wild13_XbE)
>>>(GHC.Pri
Claus Reinke wrote:
PS. perhaps on newer 64 bit machines, explicitly selecting
32 bits can offer savings? I'd certainly expect selecting
64 bits on a 32 bit machine to lead to slowdowns.
Unlikely, I'd have thought. We implement all the explicitly sized integral
types by zero-extending o
| | A quick grep shows almost no specialization at all for Word, or for
| | IntXX/WordXX (see below). Still, none of that seems to explain the
| | example repeated at the top of this message.
|
| We'd be delighted to apply suitable library patches.
PS: in the case that no one gets around to creati
| Until I stumbled over CORE annotations, I found it near impossible even
| to find the pieces of interest for non-trivial programs, things like
| -dsuppress-uniques help a little with diffs, some things look big but
| are noops, etc. - that kind of helpful pragmatic knowledge (why does
| it look a
Claus Reinke wrote:
Here is a trivial example with drastic difference between
T = Int and T = Word (~2.5x here):
main = print $ foldl' (+) 0 [1..1::T]
..
A quick grep shows almost no specialization at all for Word, or for
IntXX/WordXX (see below). Still, none of that seems to expl
This is the code:
{-# OPTIONS -fglasgow-exts #-}
import Foreign
type X u = Ptr ()
foreign import ccall bla :: (forall u. X u) -> IO ()
I know of course that I must not use fancy types in foreign imports. I
forgot for a moment and instead of an error message got:
b...@sarun> ghci Bug3
GHCi, versi
A while ago, I needed lots of fairly small positive numbers,
together with a small number of flags for each, so I thought
I'd switch from Int to Word, and map the flags to bits.
Since there are few guarantees about the size of a Word (or Int), surely
it would be better to choose a definitely siz
Here is a trivial example with drastic difference between
T = Int and T = Word (~2.5x here):
main = print $ foldl' (+) 0 [1..1::T]
..
GHC.Prim.word2Int#
(GHC.Prim.and#
(GHC.Prim.int2Word# wild13_XbE)
(GHC.Prim.int2Word# y#_a4EZ))
Is that likely to cos
Simon Peyton-Jones wrote:
> |
> | The let-binding can be recursive. However, it is much more common for
> | the let-binding to be non-recursive, in which case the following law
> | holds: (let !p = rhs in body) is equivalent to (case rhs of !p -> body)
> |
> |
> | Shouldn't the bang be removed i
"Claus Reinke" wrote:
> A while ago, I needed lots of fairly small positive numbers,
> together with a small number of flags for each, so I thought
> I'd switch from Int to Word, and map the flags to bits.
Since there are few guarantees about the size of a Word (or Int), surely
it would be bette
|
| The let-binding can be recursive. However, it is much more common for
| the let-binding to be non-recursive, in which case the following law
| holds: (let !p = rhs in body) is equivalent to (case rhs of !p -> body)
|
|
| Shouldn't the bang be removed in the final case pattern?
No. If p was
Brian Bloniarz wrote:
> I got confused by the GHC documentation recently, I was wondering how
> it could be improved. From:
> http://www.haskell.org/ghc/docs/latest/html/users_guide/bang-patterns.html
The let-binding can be recursive. However, it is much more common for
the let-binding to be non-
Brian Bloniarz wrote:
> I got confused by the GHC documentation recently, I was wondering how
> it could be improved. From:
> http://www.haskell.org/ghc/docs/latest/html/users_guide/bang-patterns.html
Seeing the rule
pat ::= !pat
you'll probably want to avoid patterns like: "!!pat", "! ! pat", o
good idea. done
| -Original Message-
| From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell-users-
| boun...@haskell.org] On Behalf Of Brian Bloniarz
| Sent: 27 February 2009 03:56
| To: glasgow-haskell-users@haskell.org
| Subject: Suggestion for bang patterns documentat
On Friday 27 February 2009 09:39:14 Neil Mitchell wrote:
> It looks like you are running in GHCi, which I think works. It's only
> when the program is compiled and run from the command line (Cygwin or
> DOS) that I get the above problem.
Dear Neil,
You were right. When I do compile it, though, I
Hi Philip,
> Just to let you know; I tried it on the release version of 6.10.1 and it
> worked as expected (first run, I waited; second I pressed Ctrl-C):
>
> *Test> main
> goodbye
> ExitSuccess
> *Test> main
> goodbye
> ExitFailure 2
> *Test>
It looks like you are running in GHCi, which I think
> I've got the following code:
>
> import Control.Exception
> import System.Cmd
> main = system "sleep 1m" `finally` putStrLn "goodbye"
>
> When compiled with GHC 6.10.1.20090225, if I hit Ctrl-C during the
> sleep, I get the goodbye printed twice. If I leave evaluation to
> finish normally I get g
19 matches
Mail list logo
