Go here: http://hackage.haskell.org/trac/ghc/roadmap and click on the active tickets for 6.6.2 Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users-bounces@haskell.org] On | Behalf Of David Roundy | Sent: 16 April 2007 18:01 | To: glasgow-haskell-users@haskell.org | Subject: Re: Release plans | | On Mon, Apr 16, 2007 at 03:54:56PM +0100, Simon Marlow wrote: | > We'd like to solicit comments from the community on our plans for future | > GHC releases. The current situation is this: | > | > - 6.6.1 is nearly ready to go (perhaps this week, please test the RC!) | > - 6.6.2 has ~35 outstanding tickets | > - 6.8 has ~150 outstanding tickets | > | > the default option would be to work on 6.6.2 and release it in a couple of | > months, while continuing to work on 6.8 for a release in ~6 months or so. | ... | > Here's a quick summary of the major developments that we already have in | > the 6.8 codebase: | | Could you summarize the major tickets for 6.6.2? I'd tentatively vote for | an accelerated 6.8. I'm quite excited about the associated types and the | GADT-typeclass interactions. | -- | David Roundy | Department of Physics | Oregon State University | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Stefan O'Rear wrote:

...

What do you think of this plan? Are there features/bug-fixes that you really want to see in 6.8?

Good code generation for loops. I understand they are rare in practice, but it's kinda disheartening to write memset() and see in the asm loop 11 memory references, 9 to the stack (numbers from unreliable memory).

Right. It's a major undertaking to do it properly: the current plan is to convert to SSA in the native code generator and do standard loop optimisations, together with replacing the register allocator with a better one. It's possible we could construct some interrim hack that might help some of the common cases, but I'm mildly dubious. So if we have something ready in time then it'll go into 6.8, otherwise 6.10. Cheers, Simon

Just to show what kind of problems we are currently facing. The following type checks in our EHC compiler and in Hugs, but not in the GHC: module Test where data T s = forall x. T (s -> (x -> s) -> (x, s, Int)) run :: (forall s . T s) -> Int run ts = case ts of T g -> let (x,_, b) = g x id in b Doaitse Swierstra On Apr 17, 2007, at 12:41 AM, Stefan O'Rear wrote:

On Mon, Apr 16, 2007 at 03:54:56PM +0100, Simon Marlow wrote:

...

- left-to-right impredicative instantiation: runST $ foo

This concerns me. With each ad-hoc extension of the type system, I worry that soon the GHC type system will become so byzantine and ill-specified that the type checker can only be cloned, not substantially improved on. I personally have a type checker idea I am working on, but I doubt I will ever be able to implement features such as this, because the type checking abstraction is now leaking badly. Once the Hindley-Damas-Milner algorithm is exposed, I fear programmers will rely on it and progress in Haskell typechecker implementation will be effectively halted. (Yes, I know I'm a bit late in complaining...)

...

- list fusion

Nitpick - you did mean stream fusion, right?

...

We think the above feature set makes for a pretty strong 6.8 release.

What do you think of this plan? Are there features/bug-fixes that you really want to see in 6.8?

Good code generation for loops. I understand they are rare in practice, but it's kinda disheartening to write memset() and see in the asm loop 11 memory references, 9 to the stack (numbers from unreliable memory).

I don't mind the plan, either.

Stefan _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

On Apr 17, 2007, at 2:57 PM, Simon Peyton-Jones wrote:

| Just to show what kind of problems we are currently facing. The | following type checks in our EHC compiler and in Hugs, but not in the | GHC: | | module Test where | | data T s = forall x. T (s -> (x -> s) -> (x, s, Int)) | | run :: (forall s . T s) -> Int | run ts = case ts of | T g -> let (x,_, b) = g x id | in b

And indeed it should be rejected!

If you think it should be rejected, can you give me the translation into System F + data types? I don't think there is one, and that's why GHC rejects it.

Yes, but where is it written that what cannot be expressed in system- F is type incorrect? We think it is still type safe, and it is an extrcat of a larger program that is quite useful (if we managed to compile it), Doaitse

Simon

Doaitse Swierstra wrote:

Just to show what kind of problems we are currently facing. The following type checks in our EHC compiler and in Hugs, but not in the GHC:

module Test where

data T s = forall x. T (s -> (x -> s) -> (x, s, Int))

run :: (forall s . T s) -> Int run ts = case ts of T g -> let (x,_, b) = g x id in b

Doaitse Swierstra

f :: Double -> (Char -> Double) -> (Char, Double, Int) f double charToDouble = (undefined, double, 0) t :: T Double t = T f -- And what will happen here: run t = ... The "id" in "T g = g _ id" tries to require that f :: Double -> (Double -> Double) -> (Double, Double, Int) but that is not correct.

Hi

...

...

Release plans: - get external core working again

Can't this happen entirely separate from any GHC releases?

It will work in the HEAD as soon as it's done, but it won't be in a released compiler until the release after that.

AFAIWA the library in the past was entirely stand alone, and as soon as it works, it will work with the Core that GHC 6.6 produces as well? * AFAIWA = As far as I was aware :-) Thanks Neil

It is still coming along! :) I'm frustrated with how slowly I've been progressing with it (even though I do have good reasons), but I'm not stopping, and I believe it will be ready for 6.8. Knowing that you're waiting for it definitely gives me some motivation to push harder on it. I'm glad someone cares. :) Aaron On Apr 17, 2007, at 10:15 AM, Neil Mitchell wrote:

Hi

...

Release plans: - get external core working again

Can't this happen entirely separate from any GHC releases? From what I've heard people were thinking of wrapping this up in the next few months. I personally need this to make my PhD work on more than just Yhc :-)

Thanks

Neil _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Actually, GHC HEAD should spit out External Core already. Ian just applied my earlier patch that fixed the parser and pretty-printer. The bit I'm still working on is fitting the output of the parser into the typechecker. I don't plan on changing the concrete syntax unless I find that it's broken in some way. Aaron On Apr 17, 2007, at 11:51 PM, Simon Peyton-Jones wrote:

Ext-core is not a library; spitting it out and sucking it in is an integral part of GHC.

That said, I think there may be a library for processing the ext- core code itself (parsing, typechecking etc). I don't think Aaron is working on that.

Also, what you need for your PhD is the spitting-out part, right? You want GHC to generate ext-core for your verifier to read in? That's the relatively easier part, and Aaron might have that working sooner, especially if you ask him to prioritise it.

Simon

| -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow- haskell-users-bounces@haskell.org] On | Behalf Of Neil Mitchell | Sent: 17 April 2007 18:16 | To: Simon Marlow | Cc: GHC Users Mailing List | Subject: Re: Release plans | | Hi | | > Release plans: | > - get external core working again | | Can't this happen entirely separate from any GHC releases? From what | I've heard people were thinking of wrapping this up in the next few | months. I personally need this to make my PhD work on more than just | Yhc :-) | | Thanks | | Neil | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

| What are the plans for the esc branch? | | Are the changing going to be merged? (For others, Rene is referring to "extended static checking" for Haskell; see http://www.cl.cam.ac.uk/~nx200/) Dana is working hard on it right now. Yes, I very much hope that it'll be merged back into the HEAD in due course; but the priority is (a) get it working right, (b) write her thesis; and only then (c) merge the branch back into the HEAD. Simon