Fwd: Status of Haskell Prime Language definition
Hi all, When I first discovered Haskell' I was really excited to hear that many of the individual extensions that are already used by many people are going to be put together to one coherent next release. I have read the archive of the Haskell Prime Mailing list for all of 2007 as well as a lot of pages on Haskell.org and in the Haskell Prime Wiki, yet the most recent status report that I found is the one in the wiki from September 2006. (http://hackage.haskell.org/trac/haskell-prime/wiki/Status') Could someone please summarize the current status and planned time line for Haskell'? thanks a lot, Robert -- Skype: robert.will
Hi Robert, At the recent Haskell workshop, I stood up and gave the following summary (approximately): Up to now, the Haskell' effort has been mostly about exploring the possibilities, to find out what could be in Haskell', and to scope out what it might mean. We've now reached the stage where we want to do the opposite, namely trying to pin down what we definitely want to have in the standard, and what it should look like in detail. I've set aside a chunk of my own time this fall to help coordinate the activity, write text etc. I'm hoping that things should be pretty clear by early next year. I have spoken with CUP and JFP about publishing the standard as a special issue of JFP and as a book, and they are interested. The strawman timeline for that is early next summer. Hope this helps, John On Oct 11, 2007, at 9:34 PM, Robert Will wrote:
Hi all,
When I first discovered Haskell' I was really excited to hear that many of the individual extensions that are already used by many people are going to be put together to one coherent next release.
I have read the archive of the Haskell Prime Mailing list for all of 2007 as well as a lot of pages on Haskell.org and in the Haskell Prime Wiki, yet the most recent status report that I found is the one in the wiki from September 2006. (http://hackage.haskell.org/trac/haskell-prime/wiki/Status')
Could someone please summarize the current status and planned time line for Haskell'?
thanks a lot, Robert
-- Skype: robert.will _______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
John Launchbury | galois | (503)626-6616 x104
Robert Will wrote:
Could someone please summarize the current status and planned time line for Haskell'?
John Launchbury wrote:
Up to now, the Haskell' effort has been mostly about exploring the possibilities, to find out what could be in Haskell', and to scope out what it might mean. We've now reached the stage where we want to do the opposite, namely trying to pin down what we definitely want to have in the standard, and what it should look like in detail.
There's still a major technical obstacle, namely functional dependencies vs associated type synonyms . Some functionality for programming in the type system is needed for Haskell' but fundeps are too tricky to get powerful and sound at the same time. The problem with their promising alternative of associated type synonyms is that they're very young with their first official release being the upcoming GHC 6.8 . So, they have to stand some test of time before Haskell' can pick one of the two (probably the latter). Regards, apfelmus
Hello,
On 10/16/07, apfelmus
Robert Will wrote:
Could someone please summarize the current status and planned time line for Haskell'?
John Launchbury wrote:
Up to now, the Haskell' effort has been mostly about exploring the possibilities, to find out what could be in Haskell', and to scope out what it might mean. We've now reached the stage where we want to do the opposite, namely trying to pin down what we definitely want to have in the standard, and what it should look like in detail.
There's still a major technical obstacle, namely functional dependencies vs associated type synonyms . Some functionality for programming in the type system is needed for Haskell' but fundeps are too tricky to get powerful and sound at the same time. The problem with their promising alternative of associated type synonyms is that they're very young with their first official release being the upcoming GHC 6.8 . So, they have to stand some test of time before Haskell' can pick one of the two (probably the latter).
I am not aware of any soundness problems related to functional dependencies---could you give an example? -Iavor
Iavor Diatchki wrote:
apfelmus wrote:
fundeps are too tricky to get powerful and sound at the same time.
I am not aware of any soundness problems related to functional dependencies---could you give an example?
http://hackage.haskell.org/trac/haskell-prime/wiki/FunctionalDependencies#Lo... But I should have said "sound, complete and decidable" instead :) Regards, apfelmus
Hello,
On 10/16/07, apfelmus
Iavor Diatchki wrote:
apfelmus wrote:
fundeps are too tricky to get powerful and sound at the same time.
I am not aware of any soundness problems related to functional dependencies---could you give an example?
http://hackage.haskell.org/trac/haskell-prime/wiki/FunctionalDependencies#Lo...
But I should have said "sound, complete and decidable" instead :)
There is nothing about the system being unsound there. Furthermore, I am unclear about the problem described by the link... The two sets of predicates are logically equivalent (have the same set of ground instances), here is a full derivation: (B a b, C [a] c d) using the instance (B a b, C [a] c d, C [a] b Bool) using the FD rule (B a b, C [a] c d, C [a] b Bool, b = c) using b = c (B a b, C [a] c d, C [a] b Bool, b = c, C [a] b d) omitting unnecessary predicates and rearranging: (b = c, B a b, C [a] b d) The derivation in the other direction is much simpler: (b = c, B a b, C [a] b d) using b = c (b = c, B a b, C [a] b d, C [a] c d) omitting unnecessary predicates (B a b, C [a] c d) -- Iavor
Iavor Diatchki wrote:
http://hackage.haskell.org/trac/haskell-prime/wiki/FunctionalDependencies#Lo...
There is nothing about the system being unsound there. Furthermore, I am unclear about the problem described by the link... The two sets of predicates are logically equivalent (have the same set of ground instances), here is a full derivation:
(B a b, C [a] c d) using the instance (B a b, C [a] c d, C [a] b Bool) using the FD rule (B a b, C [a] c d, C [a] b Bool, b = c) using b = c (B a b, C [a] c d, C [a] b Bool, b = c, C [a] b d) omitting unnecessary predicates and rearranging: (b = c, B a b, C [a] b d)
The derivation in the other direction is much simpler: (b = c, B a b, C [a] b d) using b = c (b = c, B a b, C [a] b d, C [a] c d) omitting unnecessary predicates (B a b, C [a] c d)
You're right, I think I'm mixing up soundness with completeness and termination. My thought was that not explicitly mentioning the b=c constraint could lead to the type inference silently dropping this fact and letting an inconsistent set of instance declarations "go through" without noticing. But that would only be important in a setting where inconsistent instances are not reported early via the consistency condition but late when actually constructing terms. The consistency condition should be enough for soundness (no inconsistent axioms accepted), but I didn't dwell enough into FD to know such things for sure. Regards, apfelmus
On Tue, 16 Oct 2007, apfelmus wrote:
Robert Will wrote:
Could someone please summarize the current status and planned time line for Haskell'?
John Launchbury wrote:
Up to now, the Haskell' effort has been mostly about exploring the possibilities, to find out what could be in Haskell', and to scope out what it might mean. We've now reached the stage where we want to do the opposite, namely trying to pin down what we definitely want to have in the standard, and what it should look like in detail.
There's still a major technical obstacle, namely functional dependencies vs associated type synonyms .
The right thing is probably to admit that it's going to take a few years to resolve adequately, get a standard now and get a new standard or an addendum when those few years are up. This has the problem that it leaves us with crippled interfaces for standard libraries, but we already have that problem! -- flippa@flippac.org Sometimes you gotta fight fire with fire. Most of the time you just get burnt worse though.
participants (5)
-
apfelmus -
Iavor Diatchki -
John Launchbury -
Philippa Cowderoy -
Robert Will