Ignore my last email. I was accidentally using
> The Glorious Glasgow Haskell Compilation System, version 6.9.20080616
Mind you I am still having problems just not the same ones. I'll report
back later.
Dominic.
___
Glasgow-haskell-users mailing list
| > I also feel that the type errors given when working with existential
| > types, especially GADTs with existentials, are confusing. I think
|
| I am using existential types to test GADT code. See
| http://www.haskell.org/haskellwiki/QuickCheck_/_GADT which no longer
| works with 6.10.1.
Really
Simon Peyton-Jones wrote:
> | > I also feel that the type errors given when working with existential
> | > types, especially GADTs with existentials, are confusing. I think
> |
> | I am using existential types to test GADT code. See
> | http://www.haskell.org/haskellwiki/QuickCheck_/_GADT which no
| > arbitrarySeq :: Sequence a -> Gen RepSeqVal
| > arbitrarySeq Nil =
| >return (RepSeqVal Nil Empty)
| > arbitrarySeq (Cons (CTMandatory (NamedType n i t)) ts) =
| >do u <- arbitraryType t
| > us <- arbitrarySeq ts
| > case u of
| > RepTypeVal a v ->
| > c
Simon Peyton-Jones wrote:
> | > arbitrarySeq :: Sequence a -> Gen RepSeqVal
> | > arbitrarySeq Nil =
> | >return (RepSeqVal Nil Empty)
> | > arbitrarySeq (Cons (CTMandatory (NamedType n i t)) ts) =
> | >do u <- arbitraryType t
> | > us <- arbitrarySeq ts
> | > case u of
> | >
Markus Barenhoff wrote:
On Thu 27.11 09:49, Simon Marlow wrote:
Brandon S. Allbery KF8NH wrote:
On 2008 Nov 26, at 9:30, Markus Barenhoff wrote:
Because the ports seem not to get updated, I tried to compile ghc 6.10.1
under freebsd 7 on amd64 myself. For compiling I first used the ports ghc
Th
Peter Hercek wrote:
Simon Marlow wrote:
A similar argument applies to keeping the dynamic stack. The problem
with the dynamic stack is that it doesn't look much like you expect,
due to tail-calls.
Do you think people expect the tail-calls to add a stack frame to the
dynamic stack or is ther
Hi
I've talked to John a bit, and discussed test cases etc. I've tracked
this down a little way.
Given the attached file, compiling witih SHORT_EXPORT_LIST makes the
code go _slower_. By exporting the "print_lines" function the code
doubles in speed. This runs against everything I was expecting,
The specialisations are indeed caused (indirectly) by the presence of
print_lines. If print_lines is dead code (as it is when print_lines is not
exported), then there are no calls to the overloaded functions at these
specialised types, and so you don't get the specialised versions. You can get
Simon Marlow wrote:
Peter Hercek wrote:
Simon Marlow wrote:
A similar argument applies to keeping the dynamic stack. The problem
with the dynamic stack is that it doesn't look much like you expect,
due to tail-calls.
Do you think people expect the tail-calls to add a stack frame to the
dyn
Neil, thank you very much for taking the time to look at this; I
greatly appreciate it.
One thing I don't understand is why the specializations are caused by
print_lines. I suppose the optimizer can infer something which it
couldn't otherwise.
If I read this properly, the functions being special
The $f2 comes from the instance Monad (IterateeGM ...).
print_lines uses a specialised version of that instance, namely
Monad (IterateeGM el IO)
The fact that print_lines uses it makes GHC generate a specialised version of
the instance decl.
Even in the absence of print_lines you can gene
On 28/11/2008, at 15:46, Simon Peyton-Jones wrote:
The $f2 comes from the instance Monad (IterateeGM ...).
print_lines uses a specialised version of that instance, namely
Monad (IterateeGM el IO)
The fact that print_lines uses it makes GHC generate a specialised
version of the instance
Yes, this does help, thank you. I didn't know you could generate
specialized instances. In fact, I was so sure that this was some
arcane feature I immediately went to the GHC User Guide because I
didn't believe it was documented.
I immediately stumbled upon Section 8.13.9.
Thanks to everyone wh
Hi
>> instance Monad m => Monad (IterateeGM el m) where
>> {-# SPECIALISE instance Monad (IterateeGM el IO) #-}
>>
>> does that help?
Yes. With that specialise line in, we get identical performance
between the two results.
So, in summary:
The print_lines function uses the IterateeGM with IO a
Simon Marlow wrote:
Claus Reinke wrote:
Then how about my suggestion for selectively adding lexical scope to
breakpoints? I'd like to be able to say
:break {names}
and have GHCi make the necessary changes to keep {names} available
for inspection when it hits that breakpoint.
The only ea
16 matches
Mail list logo
