From westondan at imageworks.com Thu Oct 11 17:32:25 2007 From: westondan at imageworks.com (Dan Weston) Date: Thu Oct 11 17:31:24 2007 Subject: If newtype = data !, then why use does Haskell' need newtype Message-ID: <470E9669.5070302@imageworks.com> I presume that the two statements below are equivalent [1]: newtype A = MkA Int data A = MkA !Int So does Haskell' still need newtype? It seems like a needless keyword. ---------- [1] I ran ghc -c -fglasgow-exts -O -ddump-simpl and renamed identifiers to match, then did a diff, resulting in identical Tidy Core except for an explicit (inlined) reification function unused elsewhere: Main.$WMkA :: GHC.Base.Int -> Main.A [DataConWrapper] [Arity 1 NoCafRefs Str: DmdType Sm] Main.$WMkA = __inline_me (\ (tpl_A1 :: GHC.Base.Int) -> case tpl_A1 of tpl1_A1 { __DEFAULT -> Main.MkA tpl1_A1 }) which I take to mean simply: Main.$WMkA = Main.MkA From catamorphism at gmail.com Thu Oct 11 18:26:57 2007 From: catamorphism at gmail.com (Tim Chevalier) Date: Thu Oct 11 18:25:24 2007 Subject: If newtype = data !, then why use does Haskell' need newtype In-Reply-To: <470E9669.5070302@imageworks.com> References: <470E9669.5070302@imageworks.com> Message-ID: <4683d9370710111526j4ce5424dt5eefb6af20b2eb07@mail.gmail.com> On 10/11/07, Dan Weston wrote: > I presume that the two statements below are equivalent [1]: > > newtype A = MkA Int > data A = MkA !Int > > So does Haskell' still need newtype? It seems like a needless keyword. > newtype and data have different semantics: Haskell guarantees that an A will have the exact same run-time representation as an Int, if A is declared with the newtype as above. It doesn't guarantee that if you use data instead of newtype. It may be that GHC compiles code in the same way with either of your type declarations above, but that's an implementation-dependent choice. Cheers, Tim -- Tim Chevalier * catamorphism.org * Often in error, never in doubt "in a recent future, this is past" -- James Keelaghan From john at repetae.net Thu Oct 11 18:47:11 2007 From: john at repetae.net (John Meacham) Date: Thu Oct 11 18:45:40 2007 Subject: If newtype = data !, then why use does Haskell' need newtype In-Reply-To: <470E9669.5070302@imageworks.com> References: <470E9669.5070302@imageworks.com> Message-ID: <20071011224711.GB19727@momenergy.repetae.net> On Thu, Oct 11, 2007 at 02:32:25PM -0700, Dan Weston wrote: > I presume that the two statements below are equivalent [1]: > > newtype A = MkA Int > data A = MkA !Int > > So does Haskell' still need newtype? It seems like a needless keyword. they are not the same: > newtype A = MkA Int > data B = MkB !Int f (MkA x) = 3 g (MkB x) = 3 f _|_ = 3 g _|_ = _|_ newtype construction/deconstruction is defined to be a nop, data deconstruction always requires evaluation. just because the value inside the data type is guarenteed not to be bottom, it doesn't mean deconstruction/construction is a nop. That said, ghc is quite clever and figured out it can unbox that data type for you in this particular case, but such a transformation is not necessarily valid in general. John -- John Meacham - ?repetae.net?john? From robertw at cs.utoronto.ca Fri Oct 12 00:34:21 2007 From: robertw at cs.utoronto.ca (Robert Will) Date: Fri Oct 12 00:32:47 2007 Subject: Fwd: Status of Haskell Prime Language definition In-Reply-To: References: Message-ID: 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 From john at galois.com Mon Oct 15 17:47:09 2007 From: john at galois.com (John Launchbury) Date: Mon Oct 15 17:45:44 2007 Subject: Status of Haskell Prime Language definition In-Reply-To: References: Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-prime/attachments/20071015/6077fa6b/attachment-0001.htm From apfelmus at quantentunnel.de Tue Oct 16 03:51:23 2007 From: apfelmus at quantentunnel.de (apfelmus) Date: Tue Oct 16 03:51:40 2007 Subject: Status of Haskell Prime Language definition In-Reply-To: References: Message-ID: 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 From iavor.diatchki at gmail.com Tue Oct 16 06:51:27 2007 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Tue Oct 16 06:49:39 2007 Subject: Status of Haskell Prime Language definition In-Reply-To: References: Message-ID: <5ab17e790710160351g3659ff5am579c4029ce73cbde@mail.gmail.com> Hello, On 10/16/07, 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 . 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 From apfelmus at quantentunnel.de Tue Oct 16 09:20:58 2007 From: apfelmus at quantentunnel.de (apfelmus) Date: Tue Oct 16 10:14:27 2007 Subject: Status of Haskell Prime Language definition In-Reply-To: <5ab17e790710160351g3659ff5am579c4029ce73cbde@mail.gmail.com> References: <5ab17e790710160351g3659ff5am579c4029ce73cbde@mail.gmail.com> Message-ID: 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#Lossofconfluence But I should have said "sound, complete and decidable" instead :) Regards, apfelmus From flippa at flippac.org Tue Oct 16 10:24:48 2007 From: flippa at flippac.org (Philippa Cowderoy) Date: Tue Oct 16 10:53:41 2007 Subject: Status of Haskell Prime Language definition In-Reply-To: References: Message-ID: 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. From iavor.diatchki at gmail.com Tue Oct 16 14:21:35 2007 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Tue Oct 16 14:19:49 2007 Subject: Status of Haskell Prime Language definition In-Reply-To: References: <5ab17e790710160351g3659ff5am579c4029ce73cbde@mail.gmail.com> Message-ID: <5ab17e790710161121w1ac23c11jd4643cdb7a7e59e@mail.gmail.com> Hello, On 10/16/07, apfelmus wrote: > 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#Lossofconfluence > > 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 From simonpj at microsoft.com Wed Oct 17 03:35:22 2007 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Wed Oct 17 03:33:33 2007 Subject: [Haskell] Module system question In-Reply-To: <20071017015952.GC4040@momenergy.repetae.net> References: <5ab17e790710151234o4684a8bah39dcccb402222cd0@mail.gmail.com> <20071017015952.GC4040@momenergy.repetae.net> Message-ID: [Moving to haskell-prime] I think there would be real merit in some reworking of the module system, especially to allow programmers to give the complete signature of a module, perhaps by expanding what the export list says. Including instances. Any such thing is very far from being a tried-and-tested feature, though, and it'd be hard to argue it into Haskell' unless someone gets busy very soon. Even then it looks a bit late. Simon | -----Original Message----- | From: haskell-bounces@haskell.org [mailto:haskell-bounces@haskell.org] On Behalf Of John Meacham | Sent: 17 October 2007 03:00 | To: haskell@haskell.org | Subject: Re: [Haskell] Module system question | | On Mon, Oct 15, 2007 at 10:34:37PM +0300, Iavor Diatchki wrote: | > I like the Hugs behavior because it accepts more programs. OTOH, | > GHC's behavior may be a bit simpler to explain and implement(?). Any | > thoughts? | | Currently, the class and datatype namespaces are considered the same by | the standard. There is no particular reason this needs to be the case as | they can always be disambiguated syntactically except in the one case of | export/import lists. Some of the proposed module system changes for | haskell' address this issue, which would allow fully separate namespaces | for the two. | | Although I am not sure exactly what form it will take, I would like some | reworking of the module system to allow this change in haskell'. There | are some concrete proposals on the wiki, I have been meaning to make a | grand unified proposal at some point that incorperates all the proposed | changes (and incidentally, more importantly, proves compatibility | between them) to the module system so that we may consider it. Not that | I think all the proposals should go in or not as a unit, but it will | give us a concrete theoretically implementable superset of all the | proposals to think about and illuminate any interactions between | proposals that might not be obvious when considered separately. | | John | | -- | John Meacham - ?repetae.net?john? | _______________________________________________ | Haskell mailing list | Haskell@haskell.org | http://www.haskell.org/mailman/listinfo/haskell From apfelmus at quantentunnel.de Thu Oct 18 05:54:35 2007 From: apfelmus at quantentunnel.de (apfelmus) Date: Thu Oct 18 05:52:29 2007 Subject: Status of Haskell Prime Language definition In-Reply-To: <5ab17e790710161121w1ac23c11jd4643cdb7a7e59e@mail.gmail.com> References: <5ab17e790710160351g3659ff5am579c4029ce73cbde@mail.gmail.com> <5ab17e790710161121w1ac23c11jd4643cdb7a7e59e@mail.gmail.com> Message-ID: Iavor Diatchki wrote: >> http://hackage.haskell.org/trac/haskell-prime/wiki/FunctionalDependencies#Lossofconfluence > > 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