Claus Reinke wrote:
Strange. I don't think it is my idea (older implementations
used to work that way, and iirc, it also matches what Prolog
systems used to do), and I didn't think it was anything but
straightforward to avoid case transformations unless there
is a clear benefit, so I doubt
Hi Devon,
On Thu, Mar 26, 2009 at 08:14:40AM -0230, Devon Tucker wrote:
I recently compiled and installed GHC 6.10.1 on Ubuntu 8.10 64-bit,
after having installed 6.8 from the repositories. However when I
launched ghci I discovered that the arrow keys and backspace did not
work! After some
I find this reordering discussion somewhat nonsensical.
Haskell specifies top-to-botton, left-to-right matching.
This specifies exactly which tests that have to be made and in what order,
and ghc does exactly those and in the correct order.
One can have a perception that when there are multiple
Hi Pedro,
On Wed, Mar 25, 2009 at 03:43:42PM +0100, José Pedro Magalhães wrote:
2009/3/25 Ian Lynagh ig...@earth.li
ghc-options: -package-name syb
Yes, that works, thanks. I thought this problem was caused by having the syb
package unversioned in the GHC repo, and I also thought
Lennart Augustsson wrote:
I find this reordering discussion somewhat nonsensical.
Haskell specifies top-to-botton, left-to-right matching.
This specifies exactly which tests that have to be made and in what order,
and ghc does exactly those and in the correct order.
One can have a perception
Sorry to be the odd man out - perhaps an example will help to
clarify my reading of the language definition.
I find this reordering discussion somewhat nonsensical.
Haskell specifies top-to-botton, left-to-right matching.
This specifies exactly which tests that have to be made and in what
On Wed, Mar 18, 2009 at 06:51:31AM -0400, Gregory Wright wrote:
Unexpected failures:
2469(ghci)
This is
http://hackage.haskell.org/trac/ghc/ticket/2789
(which is fixed in the new build system).
apirecomp001(normal)
This is failing because of
ld: atom sorting error for ... on
I was reading the stream fusion code today and came across a comment stating
that single element dictionaries interacted poorly with GHC's optimizer:
class Unlifted a where
[...]
expose [...]
-- | This makes GHC's optimiser happier; it sometimes produces really bad
Hi Jason,
While experimenting with Uniplate I found that 1-member dictionaries
were faster than N element dictionaries - which seems to run against
what you see in the comment. 1-member dictionaries being cheaper does
make sense as then instead of passing a tuple containing functions,
you can
So a first comment on this. I spoke too soon, ghc clearly has a bug here.
It shouldn't reorder those matches against literals like that.
I suggest you report that bug, because, as you say, it violates the H98 report.
It would be nice if we could first reach a common understanding, so
that I
Sorting by constructor tag is perfectly safe when done right.
You can read about how to do it in my 1985 FPCA paper or in Simon's book.
When pattern matching against against things that that are not
constructors (like literals etc) it's much trickier to reorder them
since you have to prove harder
11 matches
Mail list logo
