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
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 can
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 pass
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
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 ...
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.
But I don't think that bug at all affects the function you had in your
original
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 orde
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 t
Hi Pedro,
On Wed, Mar 25, 2009 at 03:43:42PM +0100, José Pedro Magalhães wrote:
>
> 2009/3/25 Ian Lynagh
>
> >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 that that
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 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
Hello,
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 quick googling I came to the conclusion that editline
support was not en
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 the
Lennart Augustsson wrote:
When you tried switching Nil and Cons, did you try it on many examples?
For a single example a 2-3% could be easily attributed to random
effects like different instruction cache hit patterns. If you get it
consistently over several programs then it seems likely to mean
14 matches
Mail list logo
