Hello Simon,
Monday, October 15, 2007, 2:52:10 PM, you wrote:
> Right - GC time doubled, which is what we'd expect to see when the resident
> data size doubles. The decrease in MUT time is probably due to the extra
> registers available, but MUT time would also be affected by the increase in
> d
|
| > Of course none of this is implemented!
|
| But it all sounds very cool. I would like it. :-)
...and you shall have it :-)
Simon
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasg
Am Freitag, 19. Oktober 2007 13:44 schrieben Sie:
> […]
> Of course none of this is implemented!
But it all sounds very cool. I would like it. :-)
> Simon
Best wishes,
Wolfgang
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
| But the problem in the HList example is that two equations apply where the
| most specific one should be taken.
There is no difficulty in principle with this. You just need to state (and
implement) the rule that the most specific equation applies. That is, there's
no reason in principle you
Am Freitag, 19. Oktober 2007 11:32 schrieben Sie:
> […]
> | In fact, after thinking and experimenting I came to the conclusion that
> | it’s probably just not possible to define a type function TypeEqTF t1 t2
> | which for *all* types t1 and t2 yields True or False, depending on
> | whether t1 and
Wolfgang
Yes, that’s interesting.
As you know, you have to turn off overlap checks and allow non-terminating
instances to make this HList stuff work. There's nothing to stop us doing the
same for type functions, although we have not yet done so. (Too busy making the
basic thing work.) For exa
Am Freitag, 19. Oktober 2007 09:25 schrieb Simon Peyton-Jones:
> […]
> Our current plan is to regard FDs as syntactic sugar for indexed type
> families. We think this can be done -- see our IFL workshop paper
> http://research.microsoft.com/%7Esimonpj/papers/assoc-types
I doubt this can be done
Dear Simon,
You mentioned that GHC uses 'checking' when it knows the types. How
this relates to 'unification', I don't know. It might very well be the
same. Hopefully, the following example sheds a bit more light on what
I mean (carefully nicked from Uktaad B'mal's "Beginning Faking It").
Examples
| What does this imply for 6.8 support for FD's, as they now use
| the same type-coercions?
Actually FDs do not use type coercions, in GHC at least. As Mark originally
described them, FDs guide inference; and in particular, they give rise to some
unifications that would not otherwise occur. In
