Yes indeed
http://www.haskell.org/ghc/docs/latest/html/users_guide/assertions.html
Simon
| -Original Message-
| From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell-users-
| boun...@haskell.org] On Behalf Of Peter Hercek
| Sent: 18 May 2009 10:46
| To:
2009/5/20 Tyson Whitehead twhiteh...@gmail.com:
1- avoid forming the (iter xs) and (count i+1) closures by passing the
function and the arguments instead of the function bound to the argument
iter [] next i done = done
iter (x:xs) next i done = next i x iter xs
You have already
1- avoid forming the (iter xs) and (count i+1) closures by passing the
function and the arguments instead of the function bound to the argument
iter [] next i done = done
iter (x:xs) next i done = next i x iter xs
count i x step xs = step xs count (i+1) (i+1)
test xs = iter xs count 0
I was looking for something which works in optimized builds too.
I know I could do it with preprocessor or (I think) template haskell too
but these tools seem to heavy for such a simple goal.
The point is the exhaustiveness check saves me from some errors
sometimes, but I often need to switch
2009/5/20 Claus Reinke claus.rei...@talk21.com:
Work is underway to make library-specified optimizations
more expressive (as core2core pass plugins), though I don't know the status
of either that (Max?-)
I submitted a final version of the plugins patch to Simon some time
ago - it's waiting
I was looking for something which works in optimized builds too.
{-# OPTIONS_GHC -fno-ignore-asserts #-}
overrides the -O default setting -fignore-asserts.
I know I could do it with preprocessor or (I think) template haskell too
but these tools seem to heavy for such a simple goal.
Given
2009/05/20 Simon Peyton-Jones simo...@microsoft.com:
| I'm a little puzzled by these seeming duplicate pages in the
| manual:
|
|
http://www.haskell.org/ghc/dist/current/docs/users_guide/type-extensions.html
|
|
Claus Reinke wrote:
Given how long http://hackage.haskell.org/trac/ghc/wiki/ExplicitCallStack
has been under discussion, it is probably time to provide a short-term
workaround in GHC, just a token to be replaced by the current source
location.
This would be the best solution.
Although
Yes, it is fixed (the link is to the history).
--
Jason Dusek
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
The second solution requires QuasiQuotes, so I do not know. If I would
want to compile with a different compiler it would break. If srcloc can be
defined as a simple token (not requiring special extensions at places where
it is used) then I could define it to an empty string in some low level
| GHC's optimizer needs serious work. Personally, I'm rooting for the
| LHC/JHC guys, because I'm increasingly coming to the conclusion that
| you need whole-program compilation with flow analysis and bucketloads
| of specialisation on the back of that to make serious progress at
| optimizing
On May 20, 2009 05:50:54 Claus Reinke wrote:
I'm not at all sure what you're aiming for (the above doesn't compile),
Yeah. The newtype Step a b was required to break the recursive types, and I
dropped it when performing the various transformations, so they don't type
check. Here it is again
Oh, I just realized I had not changed the links, only the
examples. They are all fixed now.
--
Jason Dusek
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Aha. Could you find a moment to fix the wiki page? It's a wiki.
thanks
S
| -Original Message-
| From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell-users-
| boun...@haskell.org] On Behalf Of Jason Dusek
| Sent: 20 May 2009 14:44
| To: Simon Peyton-Jones
| Cc:
Thanks for all the feedback guys,
I already find it pretty amazing how well simple stuff expressed in a higher
level manner compiles down to something decent, and it seems like the future
is only going to get brighter. I can hardly wait... : )
In the meantime, I'll go back to trying to find
... exhaustive pattern checking might well help out a lot of
people coming from untyped backgrounds...
Or even people from typed backgrounds. I worship at the altar of
exhaustiveness checking.
Do you really want exhaustiveness, or is what you actually want safety?
I want
16 matches
Mail list logo
