I can't see any issues with this version of the spec.
Thanks. From the silence, we seemed to have lost the innocent
bystanders? Anyway, for those who haven't noticed, there is now
a feature request ticket (for that good feeling of closing it when this
is finally implemented;-) as well as a wik
Simon Peyton-Jones simonpj at microsoft.com :
PS: in the case that no one gets around to creating such a patch,
creating a ticket that documents the problem and points to the needed
specialisations would be a start
Was this created? I could not find something about it in the GHC trac.
Yes: h
Hello,
sorry for breaking the thread, I just got in the list.
Simon Peyton-Jones simonpj at microsoft.com :
> PS: in the case that no one gets around to creating such a patch,
> creating a ticket that documents the problem and points to the needed
> specialisations would be a start
Was this crea
Max Bolingbroke wrote:
> 2009/3/27 Simon Marlow :
> > I have a fix for num012 (the test is broken), but I still don't know
> > what's going on with num009.
>
> num009 has been broken on OS X for as long as I can remember :-).
If it is any help, I can confirm that num009 works correctly on a
Pow
2009/3/27 Simon Marlow :
> I have a fix for num012 (the test is broken), but I still don't know what's
> going on with num009.
num009 has been broken on OS X for as long as I can remember :-). I
opened a ticket about it on Trac way back:
http://hackage.haskell.org/trac/ghc/ticket/2370 (not that th
| Simon: there aren't really any patterns to combine in the test case,
| so I assume the reordering happens when "combining" a single
| pattern? Fill the fix you envisioned also cover the IsString variant?
yes it will.
S
___
Glasgow-haskell-users mailin
Ian Lynagh wrote:
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 sortin
Ticket is http://hackage.haskell.org/trac/ghc/ticket/3126 .
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.
I did, long ago. I learned functional programming by implementing a
small functional language, us
Claus Reinke wrote:
You are right that this doesn't help my performance argument,
as performance issues are outside the language definition (not
observable in the language definition sense). It was merely an answer to
the vehement claims that pattern order is irrelevant.
The order of branches
Lennart Augustsson wrote:
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
sin
| It would be nice if we could first reach a common understanding, so
| that I can actually report the right problem, not just isolated symptoms.
It's quite simple. The Reports specifies the semantics, not the operational
behaviour. Any implementation that behaves as the Report specifies is OK.
2009/3/26 Jason Dusek :
> 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 s
On 27/03/2009, at 18:32, Don Stewart wrote:
I don't think this is still the case.
Roman, do you remember?
Hmm, not really. I recall that there was some sort of problem which I
didn't have time to investigate then but it's been so long...
Roman
__
I would like to know more too. No one told me!
Simon
| -Original Message-
| From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell-users-
| boun...@haskell.org] On Behalf Of Jason Dusek
| Sent: 26 March 2009 23:30
| To: glasgow-haskell-users@haskell.org
| Subject: Really
I don't think this is still the case.
Roman, do you remember?
- Don
jason.dusek:
> 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
>
> [...]
>
15 matches
Mail list logo
