From simonpj at microsoft.com Sat Aug 1 07:58:51 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Sat Aug 1 07:39:10 2009 Subject: StricterLabelledFieldSyntax In-Reply-To: <20090726205312.GA26415@matrix.chaos.earth.li> References: <20090726013459.GA18475@matrix.chaos.earth.li> <3c6288ab0907260040p17cf436fnae77f1fc0d7fa52c@mail.gmail.com> <20090726114129.GB22452@matrix.chaos.earth.li> <3c6288ab0907260646u3030a223k41ed25dc084c7f2b@mail.gmail.com> <4A6C97DA.4080506@isaac.cedarswampstudios.org> <5ab17e790907261157x5861de6as9840c09a7fce2915@mail.gmail.com> <4A6CA811.7070509@isaac.cedarswampstudios.org> <5ab17e790907261216p20d0385dn461a5d0b6f934a1b@mail.gmail.com> <20090726205312.GA26415@matrix.chaos.earth.li> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C354107859DB@EA-EXMSG-C334.europe.corp.microsoft.com> Personally I hate the fact that f Z {x=3} parses as f (Z {a=3}) because even though (as Iavor says) there is only one function application involved, it *looks* as if there are two. Equally personally, I think that the presence or absence of white space is a powerful signal to programmers, and it's a shame to deny ourselves use of it. So I'd be quite happy with *requiring* there to be no space, thus Z{ x=3 }. If that's tricky to lex, so be it. (Though a token "BRACE_WITH_NO_PRECEDING_WHITESPACE" might do the job.) But this would be a very non-backward-compatible change. Simon | -----Original Message----- | From: haskell-prime-bounces@haskell.org [mailto:haskell-prime- | bounces@haskell.org] On Behalf Of Ian Lynagh | Sent: 26 July 2009 21:53 | To: haskell-prime@haskell.org | Subject: Re: StricterLabelledFieldSyntax | | On Sun, Jul 26, 2009 at 10:16:28PM +0300, Iavor Diatchki wrote: | > | > On Sun, Jul 26, 2009 at 10:01 PM, Isaac | > Dupree wrote: | > > Iavor Diatchki wrote: | > >> | > >> I am strongly against this change. ?The record notation works just | > >> fine and has been doing so for a long time. ?The notation is really | > >> not that confusing and, given how records work in Haskell, makes | > >> perfect sense (and the notation has nothing to do with the precedence | > >> of application because there are no applications involved). ?In short, | > >> I am not sure what problem is addressed by this change, while a very | > >> real problem (backwards incompatibility) would be introduced. | > >> -Iavor | > > | > > a different approach to things that look funny, has been to implement a | > > warning message in GHC. ?Would that be a good alternative? | > | > Not for me. I use the notation as is, and so my code would start | > generating warnings without any valid reason, I think. What would | > such a warning warn against, anyway? | | For context, I looked at the alsa package. All of the (roughly 10) | would-be-rejected cases looked like one of the two examples below. I | don't really have anything new to say: Some people think these are | clear, others find them confusing. Hopefully we'll find a consensus and | make a decision. | | | throwAlsa :: String -> Errno -> IO a | throwAlsa fun err = do d <- strerror err | throwDyn AlsaException | { exception_location = fun | , exception_description = d | , exception_code = err | } | | peek p = do cl <- #{peek snd_seq_addr_t, client} p | po <- #{peek snd_seq_addr_t, port} p | return Addr { addr_client = cl, addr_port = po } | | | Thanks | Ian | | _______________________________________________ | Haskell-prime mailing list | Haskell-prime@haskell.org | http://www.haskell.org/mailman/listinfo/haskell-prime From iavor.diatchki at gmail.com Sun Aug 2 04:05:53 2009 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Sun Aug 2 03:46:49 2009 Subject: StricterLabelledFieldSyntax In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C354107859DB@EA-EXMSG-C334.europe.corp.microsoft.com> References: <20090726013459.GA18475@matrix.chaos.earth.li> <3c6288ab0907260040p17cf436fnae77f1fc0d7fa52c@mail.gmail.com> <20090726114129.GB22452@matrix.chaos.earth.li> <3c6288ab0907260646u3030a223k41ed25dc084c7f2b@mail.gmail.com> <4A6C97DA.4080506@isaac.cedarswampstudios.org> <5ab17e790907261157x5861de6as9840c09a7fce2915@mail.gmail.com> <4A6CA811.7070509@isaac.cedarswampstudios.org> <5ab17e790907261216p20d0385dn461a5d0b6f934a1b@mail.gmail.com> <20090726205312.GA26415@matrix.chaos.earth.li> <638ABD0A29C8884A91BC5FB5C349B1C354107859DB@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <5ab17e790908020105je56bb2eh579f2e09048824e3@mail.gmail.com> Hello, There are some examples where the current notation is nicer (subjectively so, of course :-) with the white space. Mostly, when the record fields do not fit on a single line. I tend to write things like this: ParseError { errorPosition = .. , errorDescription = .. } alternatively: ParseError { errorPosition = .., errorDescription = .. } I think that it would be very odd if these did not work because the brace had to be next to the constructor without white space. The only alternative I can see would be to have _two_ different notations for creating records one with the space that requires parens, and one without that does not require parens but (at least to me) this looks like a cludge, and is much more complex than the current situation. -Iavor On Sat, Aug 1, 2009 at 2:58 PM, Simon Peyton-Jones wrote: > Personally I hate the fact that > ? ? ? ?f Z {x=3} > parses as > ? ? ? ?f (Z {a=3}) > because even though (as Iavor says) there is only one function application involved, it *looks* as if there are two. > > Equally personally, I think that the presence or absence of white space is a powerful signal to programmers, and it's a shame to deny ourselves use of it. ?So I'd be quite happy with *requiring* there to be no space, thus Z{ x=3 }. ?If that's tricky to lex, so be it. ?(Though a token "BRACE_WITH_NO_PRECEDING_WHITESPACE" might do the job.) ?But this would be a very non-backward-compatible change. > > Simon > > | -----Original Message----- > | From: haskell-prime-bounces@haskell.org [mailto:haskell-prime- > | bounces@haskell.org] On Behalf Of Ian Lynagh > | Sent: 26 July 2009 21:53 > | To: haskell-prime@haskell.org > | Subject: Re: StricterLabelledFieldSyntax > | > | On Sun, Jul 26, 2009 at 10:16:28PM +0300, Iavor Diatchki wrote: > | > > | > On Sun, Jul 26, 2009 at 10:01 PM, Isaac > | > Dupree wrote: > | > > Iavor Diatchki wrote: > | > >> > | > >> I am strongly against this change. ?The record notation works just > | > >> fine and has been doing so for a long time. ?The notation is really > | > >> not that confusing and, given how records work in Haskell, makes > | > >> perfect sense (and the notation has nothing to do with the precedence > | > >> of application because there are no applications involved). ?In short, > | > >> I am not sure what problem is addressed by this change, while a very > | > >> real problem (backwards incompatibility) would be introduced. > | > >> -Iavor > | > > > | > > a different approach to things that look funny, has been to implement a > | > > warning message in GHC. ?Would that be a good alternative? > | > > | > Not for me. I use the notation as is, and so my code would start > | > generating warnings without any valid reason, I think. ?What would > | > such a warning warn against, anyway? > | > | For context, I looked at the alsa package. All of the (roughly 10) > | would-be-rejected cases looked like one of the two examples below. I > | don't really have anything new to say: Some people think these are > | clear, others find them confusing. Hopefully we'll find a consensus and > | make a decision. > | > | > | throwAlsa :: String -> Errno -> IO a > | throwAlsa fun err = do d <- strerror err > | ? ? ? ? ? ? ? ? ? ? ? ?throwDyn AlsaException > | ? ? ? ? ? ? ? ? ? ? ? ? ?{ exception_location = fun > | ? ? ? ? ? ? ? ? ? ? ? ? ?, exception_description = d > | ? ? ? ? ? ? ? ? ? ? ? ? ?, exception_code = err > | ? ? ? ? ? ? ? ? ? ? ? ? ?} > | > | ? peek p ? ? ?= do cl <- #{peek snd_seq_addr_t, client} p > | ? ? ? ? ? ? ? ? ? ?po <- #{peek snd_seq_addr_t, port} p > | ? ? ? ? ? ? ? ? ? ?return Addr { addr_client = cl, addr_port = po } > | > | > | Thanks > | Ian > | > | _______________________________________________ > | Haskell-prime mailing list > | Haskell-prime@haskell.org > | http://www.haskell.org/mailman/listinfo/haskell-prime > > _______________________________________________ > Haskell-prime mailing list > Haskell-prime@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-prime > From ndmitchell at gmail.com Sun Aug 2 16:21:49 2009 From: ndmitchell at gmail.com (Neil Mitchell) Date: Sun Aug 2 16:02:43 2009 Subject: Proposals and owners In-Reply-To: <4A72FD92.1040809@gmail.com> References: <4A5355FE.9010901@gmail.com> <4A5461C9.5020501@gmail.com> <4A72F4E7.8080405@gmail.com> <404396ef0907310651k184b7575u1f00c601526d9356@mail.gmail.com> <4A72FD92.1040809@gmail.com> Message-ID: <404396ef0908021321j92f5339n4d3153c1175cb23c@mail.gmail.com> >>>> ?> ?remove FixityResolution from the context-free grammar >>> >>> http://hackage.haskell.org/trac/haskell-prime/wiki/FixityResolution >>> >>> Please take a look and comment. ?This fixes a nasty bug in the Haskell >>> syntax - albeit one that doesn't cause problems in practice, but still. >>> ?I >>> think the changes make the grammar look nicer, and help compiler >>> implementers by providing a sample implementation of fixity resolution. >>> >>> We better be sure the sample implementation is correct! ?I've tested it >>> fairly well, but I wouldn't rule out corner cases being wrong, especially >>> with prefix negation. >> >> The code in Resolve.hs has been used by HLint for months, and is the >> basis of the resolution used in haskell-src-exts 1.0.0. In that time I >> haven't seen any bugs with the fixity resolution. > > I updated the code on the wiki page: the previous version didn't handle > prefix negation - did you implement that yourself in HLint? No, I didn't implement prefix negation in HLint - it never came up as an issue. Perhaps the underlying HSE library dealt with it for me - Niklas would know. Thanks Neil From niklas.broberg at gmail.com Sun Aug 2 17:38:28 2009 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Sun Aug 2 17:19:22 2009 Subject: Proposals and owners In-Reply-To: <404396ef0908021321j92f5339n4d3153c1175cb23c@mail.gmail.com> References: <4A5355FE.9010901@gmail.com> <4A5461C9.5020501@gmail.com> <4A72F4E7.8080405@gmail.com> <404396ef0907310651k184b7575u1f00c601526d9356@mail.gmail.com> <4A72FD92.1040809@gmail.com> <404396ef0908021321j92f5339n4d3153c1175cb23c@mail.gmail.com> Message-ID: >> I updated the code on the wiki page: the previous version didn't handle >> prefix negation - did you implement that yourself in HLint? > > No, I didn't implement prefix negation in HLint - it never came up as > an issue. Perhaps the underlying HSE library dealt with it for me - > Niklas would know. In haskell-src-exts (and haskell-src, since that's inherited), unary minus binds tighter than any infix operator: > exp0b :: { PExp } > : exp0b qop exp10b { InfixApp $1 $2 $3 } > | dvarexp { $1 } > | exp10b { $1 } > exp10b :: { PExp } > : 'case' exp 'of' altslist { Case $2 $4 } > | '-' fexp { NegApp $2 } > | 'do' stmtlist { Do $2 } > | 'mdo' stmtlist { MDo $2 } > | fexp { $1 } It has never come up as a problem. Guess that's a point in case for getting rid of unary minus as an operator. :-) Cheers, /Niklas From marlowsd at gmail.com Mon Aug 3 05:20:10 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Aug 3 05:01:05 2009 Subject: Proposals and owners In-Reply-To: References: <4A5355FE.9010901@gmail.com> <4A5461C9.5020501@gmail.com> <4A72F4E7.8080405@gmail.com> <404396ef0907310651k184b7575u1f00c601526d9356@mail.gmail.com> <4A72FD92.1040809@gmail.com> <404396ef0908021321j92f5339n4d3153c1175cb23c@mail.gmail.com> Message-ID: <4A76ABCA.9000701@gmail.com> On 02/08/2009 22:38, Niklas Broberg wrote: >>> I updated the code on the wiki page: the previous version didn't handle >>> prefix negation - did you implement that yourself in HLint? >> >> No, I didn't implement prefix negation in HLint - it never came up as >> an issue. Perhaps the underlying HSE library dealt with it for me - >> Niklas would know. > > In haskell-src-exts (and haskell-src, since that's inherited), unary > minus binds tighter than any infix operator: > >> exp0b :: { PExp } >> : exp0b qop exp10b { InfixApp $1 $2 $3 } >> | dvarexp { $1 } >> | exp10b { $1 } > >> exp10b :: { PExp } >> : 'case' exp 'of' altslist { Case $2 $4 } >> | '-' fexp { NegApp $2 } >> | 'do' stmtlist { Do $2 } >> | 'mdo' stmtlist { MDo $2 } >> | fexp { $1 } > > It has never come up as a problem. Guess that's a point in case for > getting rid of unary minus as an operator. :-) I think someone should propose this change for next year's Haskell revision. We have evidence that (a) the current precedence of prefix negation is confusing, and (b) it is rarely relied upon. Changing the syntax as above is better IMO than the suggestion in http://hackage.haskell.org/trac/haskell-prime/wiki/NegativeSyntax to move prefix negation into the lexical syntax of numbers. Cheers, Simon From marlowsd at gmail.com Mon Aug 3 05:20:57 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Aug 3 05:01:54 2009 Subject: Proposals and owners In-Reply-To: <5ab17e790907310853r29222c81t2822579783288919@mail.gmail.com> References: <4A5355FE.9010901@gmail.com> <4A5461C9.5020501@gmail.com> <20090708093328.GA6162@soi.city.ac.uk> <20090711090128.GA5861@soi.city.ac.uk> <5ab17e790907310853r29222c81t2822579783288919@mail.gmail.com> Message-ID: <4A76ABF9.1020306@gmail.com> So is there a volunteer to flesh out the details of a proposal? On 31/07/2009 16:53, Iavor Diatchki wrote: > +1. I completely agree. > > On Fri, Jul 31, 2009 at 6:04 PM, Lennart > Augustsson wrote: >> I think that a natural extension to allowing empty data declarations >> would be to allow empty case expressions. >> >> On Wed, Jul 29, 2009 at 7:34 PM, Stephanie >> Weirich wrote: >>> Ok, I've put together a page on EmptyDataDecls: >>> >>> http://hackage.haskell.org/trac/haskell-prime/wiki/EmptyDataDecls >>> >>> Cheers, >>> Stephanie >>> _______________________________________________ >>> Haskell-prime mailing list >>> Haskell-prime@haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-prime >>> >> _______________________________________________ >> Haskell-prime mailing list >> Haskell-prime@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-prime >> > _______________________________________________ > Haskell-prime mailing list > Haskell-prime@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-prime From marlowsd at gmail.com Mon Aug 3 05:29:22 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Aug 3 05:10:24 2009 Subject: StricterLabelledFieldSyntax In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C354107859DB@EA-EXMSG-C334.europe.corp.microsoft.com> References: <20090726013459.GA18475@matrix.chaos.earth.li> <3c6288ab0907260040p17cf436fnae77f1fc0d7fa52c@mail.gmail.com> <20090726114129.GB22452@matrix.chaos.earth.li> <3c6288ab0907260646u3030a223k41ed25dc084c7f2b@mail.gmail.com> <4A6C97DA.4080506@isaac.cedarswampstudios.org> <5ab17e790907261157x5861de6as9840c09a7fce2915@mail.gmail.com> <4A6CA811.7070509@isaac.cedarswampstudios.org> <5ab17e790907261216p20d0385dn461a5d0b6f934a1b@mail.gmail.com> <20090726205312.GA26415@matrix.chaos.earth.li> <638ABD0A29C8884A91BC5FB5C349B1C354107859DB@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <4A76ADF2.3020207@gmail.com> On 01/08/2009 12:58, Simon Peyton-Jones wrote: > Personally I hate the fact that > f Z {x=3} > parses as > f (Z {a=3}) > because even though (as Iavor says) there is only one function application involved, it *looks* as if there are two. > > Equally personally, I think that the presence or absence of white space is a powerful signal to programmers, and it's a shame to deny ourselves use of it. So I'd be quite happy with *requiring* there to be no space, thus Z{ x=3 }. If that's tricky to lex, so be it. (Though a token "BRACE_WITH_NO_PRECEDING_WHITESPACE" might do the job.) But this would be a very non-backward-compatible change. On this point - I agree that whitespace-sensitive syntax presents no problem to programmers, and is often quite natural. However, I think it presents enough other problems that it should be avoided where possible. I'm thinking of - being friendly to automatic program generation - being friendly to parsers, and tools that grok Haskell - making code robust to modification that changes whitespace - making the grammar (in the report) simpler all of these things are hurt by whitespace-sensitive syntax. IMO, we should think very carefully before introducing any. Cheers, Simon > Simon > > | -----Original Message----- > | From: haskell-prime-bounces@haskell.org [mailto:haskell-prime- > | bounces@haskell.org] On Behalf Of Ian Lynagh > | Sent: 26 July 2009 21:53 > | To: haskell-prime@haskell.org > | Subject: Re: StricterLabelledFieldSyntax > | > | On Sun, Jul 26, 2009 at 10:16:28PM +0300, Iavor Diatchki wrote: > |> > |> On Sun, Jul 26, 2009 at 10:01 PM, Isaac > |> Dupree wrote: > |> > Iavor Diatchki wrote: > |> >> > |> >> I am strongly against this change. The record notation works just > |> >> fine and has been doing so for a long time. The notation is really > |> >> not that confusing and, given how records work in Haskell, makes > |> >> perfect sense (and the notation has nothing to do with the precedence > |> >> of application because there are no applications involved). In short, > |> >> I am not sure what problem is addressed by this change, while a very > |> >> real problem (backwards incompatibility) would be introduced. > |> >> -Iavor > |> > > |> > a different approach to things that look funny, has been to implement a > |> > warning message in GHC. Would that be a good alternative? > |> > |> Not for me. I use the notation as is, and so my code would start > |> generating warnings without any valid reason, I think. What would > |> such a warning warn against, anyway? > | > | For context, I looked at the alsa package. All of the (roughly 10) > | would-be-rejected cases looked like one of the two examples below. I > | don't really have anything new to say: Some people think these are > | clear, others find them confusing. Hopefully we'll find a consensus and > | make a decision. > | > | > | throwAlsa :: String -> Errno -> IO a > | throwAlsa fun err = do d<- strerror err > | throwDyn AlsaException > | { exception_location = fun > | , exception_description = d > | , exception_code = err > | } > | > | peek p = do cl<- #{peek snd_seq_addr_t, client} p > | po<- #{peek snd_seq_addr_t, port} p > | return Addr { addr_client = cl, addr_port = po } > | > | > | Thanks > | Ian > | > | _______________________________________________ > | Haskell-prime mailing list > | Haskell-prime@haskell.org > | http://www.haskell.org/mailman/listinfo/haskell-prime > > _______________________________________________ > Haskell-prime mailing list > Haskell-prime@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-prime From malcolm.wallace at cs.york.ac.uk Mon Aug 3 05:44:30 2009 From: malcolm.wallace at cs.york.ac.uk (Malcolm Wallace) Date: Mon Aug 3 05:25:26 2009 Subject: StricterLabelledFieldSyntax In-Reply-To: <4A76ADF2.3020207@gmail.com> References: <20090726013459.GA18475@matrix.chaos.earth.li> <3c6288ab0907260040p17cf436fnae77f1fc0d7fa52c@mail.gmail.com> <20090726114129.GB22452@matrix.chaos.earth.li> <3c6288ab0907260646u3030a223k41ed25dc084c7f2b@mail.gmail.com> <4A6C97DA.4080506@isaac.cedarswampstudios.org> <5ab17e790907261157x5861de6as9840c09a7fce2915@mail.gmail.com> <4A6CA811.7070509@isaac.cedarswampstudios.org> <5ab17e790907261216p20d0385dn461a5d0b6f934a1b@mail.gmail.com> <20090726205312.GA26415@matrix.chaos.earth.li> <638ABD0A29C8884A91BC5FB5C349B1C354107859DB@EA-EXMSG-C334.europe.corp.microsoft.com> <4A76ADF2.3020207@gmail.com> Message-ID: <5A692BC8-E3B6-464C-B4E8-72139D7BFCFD@cs.york.ac.uk> > all of these things are hurt by whitespace-sensitive syntax. IMO, > we should think very carefully before introducing any. Haskell already has plenty of whitespace sensitivity. The layout rule is a pretty major part of the tradition. Other places: * (Just.foo) differs from (Just . foo) * --| differs from -- | * With NegativeSyntax, (-1) would differ from (- 1) * In TemplateHaskell, $x differs from $ x * In TemplateHaskell, [d| differs from [ d | * With UnboxedTypes, (# differs from ( # * With UnboxedTypes, 3# differs from 3 # Regards, Malcolm From marlowsd at gmail.com Mon Aug 3 06:12:03 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Aug 3 05:52:56 2009 Subject: StricterLabelledFieldSyntax In-Reply-To: <5A692BC8-E3B6-464C-B4E8-72139D7BFCFD@cs.york.ac.uk> References: <20090726013459.GA18475@matrix.chaos.earth.li> <3c6288ab0907260040p17cf436fnae77f1fc0d7fa52c@mail.gmail.com> <20090726114129.GB22452@matrix.chaos.earth.li> <3c6288ab0907260646u3030a223k41ed25dc084c7f2b@mail.gmail.com> <4A6C97DA.4080506@isaac.cedarswampstudios.org> <5ab17e790907261157x5861de6as9840c09a7fce2915@mail.gmail.com> <4A6CA811.7070509@isaac.cedarswampstudios.org> <5ab17e790907261216p20d0385dn461a5d0b6f934a1b@mail.gmail.com> <20090726205312.GA26415@matrix.chaos.earth.li> <638ABD0A29C8884A91BC5FB5C349B1C354107859DB@EA-EXMSG-C334.europe.corp.microsoft.com> <4A76ADF2.3020207@gmail.com> <5A692BC8-E3B6-464C-B4E8-72139D7BFCFD@cs.york.ac.uk> Message-ID: <4A76B7F3.3080503@gmail.com> On 03/08/2009 10:44, Malcolm Wallace wrote: >> all of these things are hurt by whitespace-sensitive syntax. IMO, we >> should think very carefully before introducing any. > > Haskell already has plenty of whitespace sensitivity. The layout rule is > a pretty major part of the tradition. Other places: > > * (Just.foo) differs from (Just . foo) > * --| differs from -- | > * With NegativeSyntax, (-1) would differ from (- 1) > * In TemplateHaskell, $x differs from $ x > * In TemplateHaskell, [d| differs from [ d | > * With UnboxedTypes, (# differs from ( # > * With UnboxedTypes, 3# differs from 3 # Yes, I know. There's also numbers: 1.0, 1e3, 0xFF. And strictly speaking keywords are also in violation: "where by" vs. "whereby", although I wouldn't go so far as to suggest we change that, of course. Only the first two items in your list are actually in Haskell, incedentally, and I argued against the others. The problem is it's hard to find spare syntax, especially for brackets, without either adding whitespace-sensitivity or using non-ASCII characters. The layout rule doesn't count, at least for the kind of whitespace-sensitivity I'm worried about, which is the presence/absence of whitespace rather than the quantity or composition of it. Cheers, Simon From Malcolm.Wallace at cs.york.ac.uk Thu Aug 6 06:08:12 2009 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Thu Aug 6 05:48:57 2009 Subject: bug in language definition (strictness) Message-ID: <0365D78A-38D2-4AB3-A591-E5DD9FD25925@cs.york.ac.uk> It has been brought to my attention (as errata editor of the revised H'98 report) that there is a bug in the language definition, concerning strictness annotations on datatypes. In section 4.2.1, the translation of strict components of a data constructor is defined as > (\ x1 ... xn -> ( ((K op1 x1) op2 x2) ... ) opn xn) > > where opi is the non-strict apply function $ if si is of the form > ti, and opi is the strict apply function $! (see Section 6.2) if si > is of the form ! ti. Pattern matching on K is not affected by > strictness flags. > yet, because of the definition of $!, this applies the constructor to its arguments right-to-left instead of the intuitive left-to-right. All extant compilers in fact evaluate the strict fields left-to-right in violation of the Report. The same non-intuitive behaviour can be seen more clearly in the simple expression: (f $! x) $! y in which you might expect x to be evaluated before y, but in fact it is the other way round. (And here, the compilers do follow the Report.) The fix I propose for H'98 (and equally for Haskell Prime) is to change the definition of $! as follows Replace f $! x = x `seq` f x with f $! x = f `seq` x `seq` f x in section 6.2 Regards, Malcolm From simonpj at microsoft.com Thu Aug 6 07:11:59 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Thu Aug 6 06:52:44 2009 Subject: Proposal: FirstClassFieldUpdates In-Reply-To: References: <20090726013459.GA18475@matrix.chaos.earth.li> <4A6C9652.8050508@isaac.cedarswampstudios.org> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C357F36E7AC7@EA-EXMSG-C334.europe.corp.microsoft.com> | Proposal: FirstClassFieldUpdates | | Summary: | Add some syntax that makes field updates into functions. I'm wary about occupying too much "syntactic space" with Haskell's named-field notation. If you had a keyword, like update { foo = bar } meaning \x. x { foo = bar } that'd get you into a new syntactic space. But braces alone are so precious that I'm not sure that record updates justify consuming them. On a related matter, people want to use record syntax for GADTs and existentials. For record selection and construction these are more or less fine (ie one can make a sensible spec). But record update is another matter. Haskell 98 says that record update can change the type of a record (contrary to some posts in this thread), but the specification becomes really rather tricky for GADTs and existentials. Indeed, I was going to propose that in H Prime we might consider making update *not* change the type, backing away from the current H98 story, but one that makes the spec a lot easier. But various people have been arguing in favour of the H98 story so I may have an uphill struggle! Simon From simonpj at microsoft.com Thu Aug 6 07:18:28 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Thu Aug 6 06:59:12 2009 Subject: NoMonomorphismRestriction In-Reply-To: <4A6D7D95.6000004@gmail.com> References: <20090725152847.GA31765@matrix.chaos.earth.li> <4A6D7D95.6000004@gmail.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C357F36E7AD4@EA-EXMSG-C334.europe.corp.microsoft.com> | > I've made a ticket and proposal page for removing the monomorphism | > restriction: | > http://hackage.haskell.org/trac/haskell-prime/ticket/131 | > http://hackage.haskell.org/trac/haskell-prime/wiki/NoMonomorphismRestriction | | I think if we do this we really have to do | | http://hackage.haskell.org/trac/haskell-prime/wiki/SpecifyPatternBindingSemantics Apropos of the MR, I'd like to invite you to read Let should not be generalised Dimitrios Vytiniotis, Simon Peyton Jones, and Tom Schrijvers Submitted to POPL 2010 http://research.microsoft.com/en-us/um/people/simonpj/papers/constraints/index.htm Abstract: From the dawn of time, all derivatives of the classic Hindley-Milner type system have supported implicit generalisation of local let-bindings. Yet, as we will show, for more sophisticated type systems implicit let-generalisation imposes a disproportionate complexity burden. Moreover, it turns out that the feature is very seldom used, so we propose to eliminate it. The payoff is a substantial simplification, both of the specification of the type system, and of its implementation. The paper makes the (somewhat radical) case for not generalising local bindings at all; which would at a stroke remove most of the issues of the MR. (We'd still need to think about the top level.) We'd love to know what any of you think of the idea. Simon | -----Original Message----- | From: haskell-prime-private-bounces@haskell.org [mailto:haskell-prime-private- | bounces@haskell.org] On Behalf Of Simon Marlow | Sent: 27 July 2009 11:13 | To: haskell-prime@haskell.org; haskell-prime-private@haskell.org | Subject: Re: [Haskell'-private] NoMonomorphismRestriction | | On 25/07/2009 16:28, Ian Lynagh wrote: | | > I've made a ticket and proposal page for removing the monomorphism | > restriction: | > http://hackage.haskell.org/trac/haskell-prime/ticket/131 | > http://hackage.haskell.org/trac/haskell-prime/wiki/NoMonomorphismRestriction | | I think if we do this we really have to do | | http://hackage.haskell.org/trac/haskell-prime/wiki/SpecifyPatternBindingSemantics | | Which is not strictly speaking a change, but is a necessary | clarification if the MR is removed. I believe the conclusion we came to | in March/April 2008 was to do this. | | Cheers, | Simon | _______________________________________________ | Haskell-prime-private mailing list | Haskell-prime-private@haskell.org | http://www.haskell.org/mailman/listinfo/haskell-prime-private From nad at Cs.Nott.AC.UK Thu Aug 6 08:37:38 2009 From: nad at Cs.Nott.AC.UK (Nils Anders Danielsson) Date: Thu Aug 6 08:23:48 2009 Subject: bug in language definition (strictness) In-Reply-To: <0365D78A-38D2-4AB3-A591-E5DD9FD25925@cs.york.ac.uk> References: <0365D78A-38D2-4AB3-A591-E5DD9FD25925@cs.york.ac.uk> Message-ID: <4A7ACE92.4020503@cs.nott.ac.uk> On 2009-08-06 11:08, Malcolm Wallace wrote: > yet, because of the definition of $!, this applies the constructor to > its arguments right-to-left instead of the intuitive left-to-right. I do not think that there is a bug: x `seq` y `seq` e has the same denotation as y `seq` x `seq` e. -- /NAD This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. From tatd2 at kent.ac.uk Thu Aug 6 08:49:10 2009 From: tatd2 at kent.ac.uk (Thomas Davie) Date: Thu Aug 6 08:29:57 2009 Subject: bug in language definition (strictness) In-Reply-To: <4A7ACE92.4020503@cs.nott.ac.uk> References: <0365D78A-38D2-4AB3-A591-E5DD9FD25925@cs.york.ac.uk> <4A7ACE92.4020503@cs.nott.ac.uk> Message-ID: <3F6B656D-6F4A-4F4D-B6DB-57C9E2843302@kent.ac.uk> On 6 Aug 2009, at 14:37, Nils Anders Danielsson wrote: > On 2009-08-06 11:08, Malcolm Wallace wrote: >> yet, because of the definition of $!, this applies the constructor >> to its arguments right-to-left instead of the intuitive left-to- >> right. > > I do not think that there is a bug: x `seq` y `seq` e has the same > denotation as y `seq` x `seq` e. Not if one considers the "kind" of bottom one receives: undefined `seq` error "it exploded" `seq` e will print "Prelude.undefined" while error "it exploded" `seq` undefined `seq` e will print "Error: it exploded" Bob From marlowsd at gmail.com Thu Aug 6 08:59:53 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Thu Aug 6 08:40:37 2009 Subject: bug in language definition (strictness) In-Reply-To: <3F6B656D-6F4A-4F4D-B6DB-57C9E2843302@kent.ac.uk> References: <0365D78A-38D2-4AB3-A591-E5DD9FD25925@cs.york.ac.uk> <4A7ACE92.4020503@cs.nott.ac.uk> <3F6B656D-6F4A-4F4D-B6DB-57C9E2843302@kent.ac.uk> Message-ID: <4A7AD3C9.4090302@gmail.com> On 06/08/2009 13:49, Thomas Davie wrote: > > On 6 Aug 2009, at 14:37, Nils Anders Danielsson wrote: > >> On 2009-08-06 11:08, Malcolm Wallace wrote: >>> yet, because of the definition of $!, this applies the constructor to >>> its arguments right-to-left instead of the intuitive left-to-right. >> >> I do not think that there is a bug: x `seq` y `seq` e has the same >> denotation as y `seq` x `seq` e. > > Not if one considers the "kind" of bottom one receives: > > undefined `seq` error "it exploded" `seq` e will print "Prelude.undefined" > while > error "it exploded" `seq` undefined `seq` e will print "Error: it exploded" There's only one kind of bottom in Haskell 98. And even with the imprecise exceptions extension, both expressions still have the same denotation - they denote the same set of exceptions, one of which is non-deterministically picked when the program is run. Cheers, Simon From peteg42 at gmail.com Thu Aug 6 09:20:15 2009 From: peteg42 at gmail.com (Peter Gammie) Date: Thu Aug 6 09:01:09 2009 Subject: bug in language definition (strictness) In-Reply-To: <4A7AD3C9.4090302@gmail.com> References: <0365D78A-38D2-4AB3-A591-E5DD9FD25925@cs.york.ac.uk> <4A7ACE92.4020503@cs.nott.ac.uk> <3F6B656D-6F4A-4F4D-B6DB-57C9E2843302@kent.ac.uk> <4A7AD3C9.4090302@gmail.com> Message-ID: <8116107F-2190-4D9B-AB3C-C3BBC1BAE29F@gmail.com> On 06/08/2009, at 10:59 PM, Simon Marlow wrote: > On 06/08/2009 13:49, Thomas Davie wrote: >> On 6 Aug 2009, at 14:37, Nils Anders Danielsson wrote: >> >>> On 2009-08-06 11:08, Malcolm Wallace wrote: >>>> yet, because of the definition of $!, this applies the >>>> constructor to >>>> its arguments right-to-left instead of the intuitive left-to-right. >>> >>> I do not think that there is a bug: x `seq` y `seq` e has the same >>> denotation as y `seq` x `seq` e. >> >> Not if one considers the "kind" of bottom one receives: >> >> undefined `seq` error "it exploded" `seq` e will print >> "Prelude.undefined" >> while >> error "it exploded" `seq` undefined `seq` e will print "Error: it >> exploded" > > There's only one kind of bottom in Haskell 98. And even with the > imprecise exceptions extension, both expressions still have the same > denotation - they denote the same set of exceptions, one of which is > non-deterministically picked when the program is run. If the FFI Addendum is considered part of Haskell 98, then we have unsafePerformIO, and so an appeal to denotational equivalence is not sufficient. When grafting a pure interface onto a notionally-pure library (specifically a BDD library), I often used seq to get these effects buried in "pure" values under control. I also think the principle of least surprise is clearly violated here. cheers peter -- http://peteg.org/ From marlowsd at gmail.com Thu Aug 6 10:00:47 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Thu Aug 6 09:41:34 2009 Subject: bug in language definition (strictness) In-Reply-To: <8116107F-2190-4D9B-AB3C-C3BBC1BAE29F@gmail.com> References: <0365D78A-38D2-4AB3-A591-E5DD9FD25925@cs.york.ac.uk> <4A7ACE92.4020503@cs.nott.ac.uk> <3F6B656D-6F4A-4F4D-B6DB-57C9E2843302@kent.ac.uk> <4A7AD3C9.4090302@gmail.com> <8116107F-2190-4D9B-AB3C-C3BBC1BAE29F@gmail.com> Message-ID: <4A7AE20F.308@gmail.com> On 06/08/2009 14:20, Peter Gammie wrote: > On 06/08/2009, at 10:59 PM, Simon Marlow wrote: >> On 06/08/2009 13:49, Thomas Davie wrote: >>> On 6 Aug 2009, at 14:37, Nils Anders Danielsson wrote: >>> >>>> On 2009-08-06 11:08, Malcolm Wallace wrote: >>>>> yet, because of the definition of $!, this applies the constructor to >>>>> its arguments right-to-left instead of the intuitive left-to-right. >>>> >>>> I do not think that there is a bug: x `seq` y `seq` e has the same >>>> denotation as y `seq` x `seq` e. >>> >>> Not if one considers the "kind" of bottom one receives: >>> >>> undefined `seq` error "it exploded" `seq` e will print >>> "Prelude.undefined" >>> while >>> error "it exploded" `seq` undefined `seq` e will print "Error: it >>> exploded" >> >> There's only one kind of bottom in Haskell 98. And even with the >> imprecise exceptions extension, both expressions still have the same >> denotation - they denote the same set of exceptions, one of which is >> non-deterministically picked when the program is run. > > If the FFI Addendum is considered part of Haskell 98, then we have > unsafePerformIO, and so an appeal to denotational equivalence is not > sufficient. When grafting a pure interface onto a notionally-pure > library (specifically a BDD library), I often used seq to get these > effects buried in "pure" values under control. That sounds like a very dangerous use of seq and unsafePerformIO to me! The presence of unsafePerformIO doesn't change the meaning of the rest of Haskell. You can use it to write programs that don't behave according to the denotational semantics if you want, but if you do that it's considered an unsafe use of unsafePerformIO. What semantics would you like Haskell to have, in which (x `seq` y `seq` e) and (y `seq` x `seq` e) are not equal? > I also think the principle of least surprise is clearly violated here. I do have some sympathy with that. The fact that we're having this discussion is evidence that something is wrong - and indeed it took quite a while before we noticed that seq doesn't actually enforce a sequential evaluation order. And seq was originally introduced to fix space leaks, but sometimes it can't be used for this because it doesn't provide enough operational guarantees (I haven't seen such cases myself, but Malcolm W tells me it really happens). I'm against the change originally proposed in this thread, because on its own it doesn't make any difference. But by all means let's think about ways to restore the lack of surprise, but which hopefully don't curtail the compiler's ability to optimise, or run programs in parallel. Cheers, Simon From malcolm.wallace at cs.york.ac.uk Thu Aug 6 10:33:40 2009 From: malcolm.wallace at cs.york.ac.uk (Malcolm Wallace) Date: Thu Aug 6 10:14:27 2009 Subject: bug in language definition (strictness) In-Reply-To: <4A7AE20F.308@gmail.com> References: <0365D78A-38D2-4AB3-A591-E5DD9FD25925@cs.york.ac.uk> <4A7ACE92.4020503@cs.nott.ac.uk> <3F6B656D-6F4A-4F4D-B6DB-57C9E2843302@kent.ac.uk> <4A7AD3C9.4090302@gmail.com> <8116107F-2190-4D9B-AB3C-C3BBC1BAE29F@gmail.com> <4A7AE20F.308@gmail.com> Message-ID: > What semantics would you like Haskell to have, in which (x `seq` y > `seq` e) and (y `seq` x `seq` e) are not equal? I can easily imagine that (x `seq` y `seq` e) might have *two* semantic denotations: bottom (Exception: stack overflow), and e. And I would like to be able to choose which one I get (please). This is the declared purpose of seq, namely "to improve performance by avoiding unneeded laziness". Regards, Malcolm From ross at soi.city.ac.uk Thu Aug 6 10:49:58 2009 From: ross at soi.city.ac.uk (Ross Paterson) Date: Thu Aug 6 10:30:45 2009 Subject: Proposals and owners In-Reply-To: References: <4A5355FE.9010901@gmail.com> <4A5461C9.5020501@gmail.com> <20090708093328.GA6162@soi.city.ac.uk> <20090711090128.GA5861@soi.city.ac.uk> Message-ID: <20090806144958.GA20695@soi.city.ac.uk> On Wed, Jul 29, 2009 at 02:34:26PM -0400, Stephanie Weirich wrote: > Ok, I've put together a page on EmptyDataDecls: > > http://hackage.haskell.org/trac/haskell-prime/wiki/EmptyDataDecls I think this needs a sentence about semantics, to the effect that the type is abstract. (Not that its only element is bottom.) From ross at soi.city.ac.uk Thu Aug 6 11:00:39 2009 From: ross at soi.city.ac.uk (Ross Paterson) Date: Thu Aug 6 10:41:22 2009 Subject: bug in language definition (strictness) In-Reply-To: References: <0365D78A-38D2-4AB3-A591-E5DD9FD25925@cs.york.ac.uk> <4A7ACE92.4020503@cs.nott.ac.uk> <3F6B656D-6F4A-4F4D-B6DB-57C9E2843302@kent.ac.uk> <4A7AD3C9.4090302@gmail.com> <8116107F-2190-4D9B-AB3C-C3BBC1BAE29F@gmail.com> <4A7AE20F.308@gmail.com> Message-ID: <20090806150039.GB20695@soi.city.ac.uk> On Thu, Aug 06, 2009 at 03:33:40PM +0100, Malcolm Wallace wrote: > >What semantics would you like Haskell to have, in which (x `seq` y > >`seq` e) and (y `seq` x `seq` e) are not equal? > > I can easily imagine that (x `seq` y `seq` e) might have *two* > semantic denotations: bottom (Exception: stack overflow), and e. > And I would like to be able to choose which one I get (please). > This is the declared purpose of seq, namely "to improve performance > by avoiding unneeded laziness". There is no stack overflow in the denotational semantics. Either you would get an answer with a bigger stack (and that's the denotation), or you wouldn't (in which case the value is bottom). As Simon said, the denotational semantics of seq is very limited for specifying performance. From redbeard0531 at gmail.com Thu Aug 6 11:34:30 2009 From: redbeard0531 at gmail.com (Mathias Stearn) Date: Thu Aug 6 11:15:32 2009 Subject: bug in language definition (strictness) In-Reply-To: <20090806150039.GB20695@soi.city.ac.uk> References: <0365D78A-38D2-4AB3-A591-E5DD9FD25925@cs.york.ac.uk> <4A7ACE92.4020503@cs.nott.ac.uk> <3F6B656D-6F4A-4F4D-B6DB-57C9E2843302@kent.ac.uk> <4A7AD3C9.4090302@gmail.com> <8116107F-2190-4D9B-AB3C-C3BBC1BAE29F@gmail.com> <4A7AE20F.308@gmail.com> <20090806150039.GB20695@soi.city.ac.uk> Message-ID: <3d03c0530908060834g1ba671cam8f3629864702a901@mail.gmail.com> On Thu, Aug 6, 2009 at 11:00 AM, Ross Paterson wrote: > There is no stack overflow in the denotational semantics. There is currently no denotational semantics simulator with an infinite stack. Until there is, Haskell programs will have to be executed on lowly physical computers with all the limitations that is implied. Can we please make things work well on them? From tatd2 at kent.ac.uk Thu Aug 6 11:36:34 2009 From: tatd2 at kent.ac.uk (Thomas Davie) Date: Thu Aug 6 11:17:19 2009 Subject: bug in language definition (strictness) In-Reply-To: <3d03c0530908060834g1ba671cam8f3629864702a901@mail.gmail.com> References: <0365D78A-38D2-4AB3-A591-E5DD9FD25925@cs.york.ac.uk> <4A7ACE92.4020503@cs.nott.ac.uk> <3F6B656D-6F4A-4F4D-B6DB-57C9E2843302@kent.ac.uk> <4A7AD3C9.4090302@gmail.com> <8116107F-2190-4D9B-AB3C-C3BBC1BAE29F@gmail.com> <4A7AE20F.308@gmail.com> <20090806150039.GB20695@soi.city.ac.uk> <3d03c0530908060834g1ba671cam8f3629864702a901@mail.gmail.com> Message-ID: On 6 Aug 2009, at 17:34, Mathias Stearn wrote: > On Thu, Aug 6, 2009 at 11:00 AM, Ross Paterson > wrote: >> There is no stack overflow in the denotational semantics. > > There is currently no denotational semantics simulator with an > infinite stack. Until there is, Haskell programs will have to be > executed on lowly physical computers with all the limitations that is > implied. Can we please make things work well on them? When writing a document that defines the denotation of values, no. Perhaps when considering operational semantics, but that's an entirely different matter. Bob From marlowsd at gmail.com Thu Aug 6 11:59:43 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Thu Aug 6 11:40:27 2009 Subject: bug in language definition (strictness) In-Reply-To: References: <0365D78A-38D2-4AB3-A591-E5DD9FD25925@cs.york.ac.uk> <4A7ACE92.4020503@cs.nott.ac.uk> <3F6B656D-6F4A-4F4D-B6DB-57C9E2843302@kent.ac.uk> <4A7AD3C9.4090302@gmail.com> <8116107F-2190-4D9B-AB3C-C3BBC1BAE29F@gmail.com> <4A7AE20F.308@gmail.com> Message-ID: <4A7AFDEF.7030800@gmail.com> On 06/08/2009 15:33, Malcolm Wallace wrote: >> What semantics would you like Haskell to have, in which (x `seq` y >> `seq` e) and (y `seq` x `seq` e) are not equal? > > I can easily imagine that (x `seq` y `seq` e) might have *two* semantic > denotations: bottom (Exception: stack overflow), and e. And I would like > to be able to choose which one I get (please). This is the declared > purpose of seq, namely "to improve performance by avoiding unneeded > laziness". I'm afraid I don't really comprehend what you're getting at. What do you mean by an expression having two semantic denotations, and how would you like to choose which one you get? And I'm baffled by the mention of stack overflow, where does that come in? Cheers, Simon From malcolm.wallace at cs.york.ac.uk Thu Aug 6 12:42:22 2009 From: malcolm.wallace at cs.york.ac.uk (Malcolm Wallace) Date: Thu Aug 6 12:23:05 2009 Subject: bug in language definition (strictness) In-Reply-To: <4A7AFDEF.7030800@gmail.com> References: <0365D78A-38D2-4AB3-A591-E5DD9FD25925@cs.york.ac.uk> <4A7ACE92.4020503@cs.nott.ac.uk> <3F6B656D-6F4A-4F4D-B6DB-57C9E2843302@kent.ac.uk> <4A7AD3C9.4090302@gmail.com> <8116107F-2190-4D9B-AB3C-C3BBC1BAE29F@gmail.com> <4A7AE20F.308@gmail.com> <4A7AFDEF.7030800@gmail.com> Message-ID: <97E3999E-AC1E-4CAA-B52C-4A7A23F2A7E7@cs.york.ac.uk> > >>> What semantics would you like Haskell to have, in which (x `seq` y >>> `seq` e) and (y `seq` x `seq` e) are not equal? >> >> I can easily imagine that (x `seq` y `seq` e) might have *two* >> semantic >> denotations: bottom (Exception: stack overflow), and e. And I would >> like >> to be able to choose which one I get (please). This is the declared >> purpose of seq, namely "to improve performance by avoiding unneeded >> laziness". > > I'm afraid I don't really comprehend what you're getting at. What > do you mean by an expression having two semantic denotations, and > how would you like to choose which one you get? And I'm baffled by > the mention of stack overflow, where does that come in? Whether it is a stack overflow, or some other kind of resource-related exception like out-of-memory, or too-many-open-file-handles, does not really matter. As you were saying, semantically they are all just bottom. My real point is that seq looks for all the world like it is intended to affect the operational behaviour of a program, yet some people insist that it is a purely denotational device, and that operational questions are not relevant. The Report hints that using seq can "improve performance" (although the opposite is also true), and changes in performance are certainly an operational notion. Yet I think it would be valid to say that seq can turn a non-terminating (exceptioning) program into a terminating one. Regards, Malcolm From ml at isaac.cedarswampstudios.org Thu Aug 6 18:02:27 2009 From: ml at isaac.cedarswampstudios.org (Isaac Dupree) Date: Thu Aug 6 17:43:19 2009 Subject: bug in language definition (strictness) In-Reply-To: <4A7AE20F.308@gmail.com> References: <0365D78A-38D2-4AB3-A591-E5DD9FD25925@cs.york.ac.uk> <4A7ACE92.4020503@cs.nott.ac.uk> <3F6B656D-6F4A-4F4D-B6DB-57C9E2843302@kent.ac.uk> <4A7AD3C9.4090302@gmail.com> <8116107F-2190-4D9B-AB3C-C3BBC1BAE29F@gmail.com> <4A7AE20F.308@gmail.com> Message-ID: <4A7B52F3.9030509@isaac.cedarswampstudios.org> Simon Marlow wrote: > I'm against the change originally proposed in this thread, because on > its own it doesn't make any difference. I wonder if in practice, if we modified the definition of $! in the GHC libraries, whether GHC would compile things differently enough that we would notice the difference. Probably not often enough to really notice... -Isaac From ml at isaac.cedarswampstudios.org Thu Aug 6 18:42:27 2009 From: ml at isaac.cedarswampstudios.org (Isaac Dupree) Date: Thu Aug 6 18:23:15 2009 Subject: NoMonomorphismRestriction In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C357F36E7AD4@EA-EXMSG-C334.europe.corp.microsoft.com> References: <20090725152847.GA31765@matrix.chaos.earth.li> <4A6D7D95.6000004@gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C357F36E7AD4@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <4A7B5C53.2030307@isaac.cedarswampstudios.org> > The paper makes the (somewhat radical) case for not generalising local bindings at all; which would at a stroke remove most of the issues of the MR. (We'd still need to think about the top level.) > > We'd love to know what any of you think of the idea. I read the paper (except section 5 which is very technical). I like that it makes (let x = ... in ...) behave the same as (\x -> ...) (...) . Understanding how to respond to type inference and error messages is hard enough without having additional differences in innocent-looking code. Do you think my hope is reasonable that not-generalizing could lead to better error messages? I don't quite understand the issues[*], but I suspect that not-generalizing would at least make *me* less confused when fixing error messages because there are fewer different typechecker behaviors to think about. I guess it's still possible to use explicit type-signatures to make let-bindings polymorphic, in a way that is difficult or impossible for lambda or case? (I guess for lambda, it would require making the lambda into a rank-2 function, though I'm not sure how to do that syntactically.) [*] e.g., the gmapT / rank-2 example confuses me; would it work if (...blah...) were passed directly to gmapT without the let? Also, does it happen to solve the 2^n worst-case typechecking? -Isaac From peteg42 at gmail.com Thu Aug 6 18:56:39 2009 From: peteg42 at gmail.com (Peter Gammie) Date: Thu Aug 6 18:37:30 2009 Subject: bug in language definition (strictness) In-Reply-To: <4A7AE20F.308@gmail.com> References: <0365D78A-38D2-4AB3-A591-E5DD9FD25925@cs.york.ac.uk> <4A7ACE92.4020503@cs.nott.ac.uk> <3F6B656D-6F4A-4F4D-B6DB-57C9E2843302@kent.ac.uk> <4A7AD3C9.4090302@gmail.com> <8116107F-2190-4D9B-AB3C-C3BBC1BAE29F@gmail.com> <4A7AE20F.308@gmail.com> Message-ID: <48A5A7F0-0E65-4642-8249-DB78828C373D@gmail.com> On 07/08/2009, at 12:00 AM, Simon Marlow wrote: > On 06/08/2009 14:20, Peter Gammie wrote: >> On 06/08/2009, at 10:59 PM, Simon Marlow wrote: >>> On 06/08/2009 13:49, Thomas Davie wrote: >>>> On 6 Aug 2009, at 14:37, Nils Anders Danielsson wrote: >>>> >>>>> On 2009-08-06 11:08, Malcolm Wallace wrote: >>>>>> yet, because of the definition of $!, this applies the >>>>>> constructor to >>>>>> its arguments right-to-left instead of the intuitive left-to- >>>>>> right. >>>>> >>>>> I do not think that there is a bug: x `seq` y `seq` e has the same >>>>> denotation as y `seq` x `seq` e. >>>> >>>> Not if one considers the "kind" of bottom one receives: >>>> >>>> undefined `seq` error "it exploded" `seq` e will print >>>> "Prelude.undefined" >>>> while >>>> error "it exploded" `seq` undefined `seq` e will print "Error: it >>>> exploded" >>> >>> There's only one kind of bottom in Haskell 98. And even with the >>> imprecise exceptions extension, both expressions still have the same >>> denotation - they denote the same set of exceptions, one of which is >>> non-deterministically picked when the program is run. >> >> If the FFI Addendum is considered part of Haskell 98, then we have >> unsafePerformIO, and so an appeal to denotational equivalence is not >> sufficient. When grafting a pure interface onto a notionally-pure >> library (specifically a BDD library), I often used seq to get these >> effects buried in "pure" values under control. > > That sounds like a very dangerous use of seq and unsafePerformIO to > me! How so? Take this code: newtype BDD = BDD (ForeignPtr Int) exists :: Group BDD -> BDD -> BDD exists group bdd = bdd `seq` unsafePerformIO $ withGroup group $ \ gid -> do bdd_assoc bdd_manager gid withBDD bdd ({#call unsafe bdd_exists#} bdd_manager) >>= addBDDfinalizer Without the seq, a recursive use of a quantifier will screw up the effect of bdd_assoc. How is this unsafe? IMHO I'm using seq in the standard way, to shuffle the data dependencies to get better (correct) operational behaviour. I grant that it is dodgy in a concurrent setting, but the library itself is not thread safe. > What semantics would you like Haskell to have, in which (x `seq` y > `seq` e) and (y `seq` x `seq` e) are not equal? As Malcolm observes, an operational one. seq is difficult to motivate without such considerations anyway. I'm sure you could imagine an example where space use differs between the two. My point was that in the presence of unsafePerformIO, even if the denotational values are the same for the two seq variants, the end- user observable effects are not. I meant this as an example of violating least-surprise in a context a bit larger than pure Haskell semantics. BTW I have no opinion on the change Malcolm proposes, but would like to see the issue resolved. cheers peter From marlowsd at gmail.com Fri Aug 7 03:57:30 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Fri Aug 7 03:38:13 2009 Subject: bug in language definition (strictness) In-Reply-To: <97E3999E-AC1E-4CAA-B52C-4A7A23F2A7E7@cs.york.ac.uk> References: <0365D78A-38D2-4AB3-A591-E5DD9FD25925@cs.york.ac.uk> <4A7ACE92.4020503@cs.nott.ac.uk> <3F6B656D-6F4A-4F4D-B6DB-57C9E2843302@kent.ac.uk> <4A7AD3C9.4090302@gmail.com> <8116107F-2190-4D9B-AB3C-C3BBC1BAE29F@gmail.com> <4A7AE20F.308@gmail.com> <4A7AFDEF.7030800@gmail.com> <97E3999E-AC1E-4CAA-B52C-4A7A23F2A7E7@cs.york.ac.uk> Message-ID: <4A7BDE6A.6090507@gmail.com> On 06/08/2009 17:42, Malcolm Wallace wrote: >> >>>> What semantics would you like Haskell to have, in which (x `seq` y >>>> `seq` e) and (y `seq` x `seq` e) are not equal? >>> >>> I can easily imagine that (x `seq` y `seq` e) might have *two* semantic >>> denotations: bottom (Exception: stack overflow), and e. And I would like >>> to be able to choose which one I get (please). This is the declared >>> purpose of seq, namely "to improve performance by avoiding unneeded >>> laziness". >> >> I'm afraid I don't really comprehend what you're getting at. What do >> you mean by an expression having two semantic denotations, and how >> would you like to choose which one you get? And I'm baffled by the >> mention of stack overflow, where does that come in? > > Whether it is a stack overflow, or some other kind of resource-related > exception like out-of-memory, or too-many-open-file-handles, does not > really matter. As you were saying, semantically they are all just bottom. > > My real point is that seq looks for all the world like it is intended to > affect the operational behaviour of a program, yet some people insist > that it is a purely denotational device, and that operational questions > are not relevant. The fact remains that seq *is* defined denotationally, and any implementation that respects its semantics is legal. If you want to change that, you need to make a Haskell Prime proposal. I think it might be difficult to do that. The Haskell report has no framework for talking about operational semantics at all. The pure subset of Haskell is timeless, there's no specified evaluation order. Before we think about changing that, let's remember why it's that way: one reason is that evaluation order doesn't affect the denotational semantics, so it's unnecessary. Another reason is that it lets Haskell admit many different implementations, including things like automatic speculative parallelism. If you start nailing down evaluation orders, you rule out interesting implementations. (this is why I've complained about lazy I/O in the past - it starts to creep in this direction). There's nothing stopping you from making a compiler in which seq has the behaviour you want. Indeed, Control.Parallel.pseq is the kind of seq you want (I think - we haven't put any thought into precisely specifying what it means). pseq is a valid implementation of seq, it's just not the one we normally want to use, because it restricts the compiler's ability to optimise. And pseq isn't something we want to mandate in the language, because it only makes sense in certain kinds of implementations. I'm completely happy with asking users to use pseq when they really want an evaluation order guarantee. > Yet I think it would be > valid to say that seq can turn a non-terminating (exceptioning) program > into a terminating one. Do you have an example of that? Cheers, Simon From marlowsd at gmail.com Fri Aug 7 04:04:27 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Fri Aug 7 03:45:15 2009 Subject: bug in language definition (strictness) In-Reply-To: <48A5A7F0-0E65-4642-8249-DB78828C373D@gmail.com> References: <0365D78A-38D2-4AB3-A591-E5DD9FD25925@cs.york.ac.uk> <4A7ACE92.4020503@cs.nott.ac.uk> <3F6B656D-6F4A-4F4D-B6DB-57C9E2843302@kent.ac.uk> <4A7AD3C9.4090302@gmail.com> <8116107F-2190-4D9B-AB3C-C3BBC1BAE29F@gmail.com> <4A7AE20F.308@gmail.com> <48A5A7F0-0E65-4642-8249-DB78828C373D@gmail.com> Message-ID: <4A7BE00B.8070008@gmail.com> On 06/08/2009 23:56, Peter Gammie wrote: > On 07/08/2009, at 12:00 AM, Simon Marlow wrote: > >> On 06/08/2009 14:20, Peter Gammie wrote: >>> On 06/08/2009, at 10:59 PM, Simon Marlow wrote: >>>> On 06/08/2009 13:49, Thomas Davie wrote: >>>>> On 6 Aug 2009, at 14:37, Nils Anders Danielsson wrote: >>>>> >>>>>> On 2009-08-06 11:08, Malcolm Wallace wrote: >>>>>>> yet, because of the definition of $!, this applies the >>>>>>> constructor to >>>>>>> its arguments right-to-left instead of the intuitive left-to-right. >>>>>> >>>>>> I do not think that there is a bug: x `seq` y `seq` e has the same >>>>>> denotation as y `seq` x `seq` e. >>>>> >>>>> Not if one considers the "kind" of bottom one receives: >>>>> >>>>> undefined `seq` error "it exploded" `seq` e will print >>>>> "Prelude.undefined" >>>>> while >>>>> error "it exploded" `seq` undefined `seq` e will print "Error: it >>>>> exploded" >>>> >>>> There's only one kind of bottom in Haskell 98. And even with the >>>> imprecise exceptions extension, both expressions still have the same >>>> denotation - they denote the same set of exceptions, one of which is >>>> non-deterministically picked when the program is run. >>> >>> If the FFI Addendum is considered part of Haskell 98, then we have >>> unsafePerformIO, and so an appeal to denotational equivalence is not >>> sufficient. When grafting a pure interface onto a notionally-pure >>> library (specifically a BDD library), I often used seq to get these >>> effects buried in "pure" values under control. >> >> That sounds like a very dangerous use of seq and unsafePerformIO to me! > > How so? Take this code: > > newtype BDD = BDD (ForeignPtr Int) > > exists :: Group BDD -> BDD -> BDD > exists group bdd = bdd `seq` unsafePerformIO $ > withGroup group $ \ gid -> > do bdd_assoc bdd_manager gid > withBDD bdd ({#call unsafe bdd_exists#} bdd_manager) >>= addBDDfinalizer > > Without the seq, a recursive use of a quantifier will screw up the > effect of bdd_assoc. How is this unsafe? > IMHO I'm using seq in the standard way, to shuffle the data dependencies > to get better (correct) operational behaviour. > > I grant that it is dodgy in a concurrent setting, but the library itself > is not thread safe. If, as I understand it, you are relying on the fact that seq's first argument is evaluted before its second, then you really want pseq rather than seq. This is the sense in which I mean it's a dangerous use of seq and unsafePerformIO - because the compiler is within its rights to evaluate the second argument to seq "first". In GHC we provide a way to do what you want (pseq), I'm just not convinced it should be the required behaviour of seq. Cheers, Simon From peteg42 at gmail.com Fri Aug 7 04:37:24 2009 From: peteg42 at gmail.com (Peter Gammie) Date: Fri Aug 7 04:18:11 2009 Subject: bug in language definition (strictness) In-Reply-To: <4A7BE00B.8070008@gmail.com> References: <0365D78A-38D2-4AB3-A591-E5DD9FD25925@cs.york.ac.uk> <4A7ACE92.4020503@cs.nott.ac.uk> <3F6B656D-6F4A-4F4D-B6DB-57C9E2843302@kent.ac.uk> <4A7AD3C9.4090302@gmail.com> <8116107F-2190-4D9B-AB3C-C3BBC1BAE29F@gmail.com> <4A7AE20F.308@gmail.com> <48A5A7F0-0E65-4642-8249-DB78828C373D@gmail.com> <4A7BE00B.8070008@gmail.com> Message-ID: On 07/08/2009, at 6:04 PM, Simon Marlow wrote: > If, as I understand it, you are relying on the fact that seq's first > argument is evaluted before its second, then you really want pseq > rather than seq. > > This is the sense in which I mean it's a dangerous use of seq and > unsafePerformIO - because the compiler is within its rights to > evaluate the second argument to seq "first". > > In GHC we provide a way to do what you want (pseq), I'm just not > convinced it should be the required behaviour of seq. OK, thanks for pointing that out. I would have thought that what I was doing (or trying to do) was a reasonable use of the FFI and unsafePerformIO - from the library user's POV the interface really is pure, at least in a sequential setting. So should there be a mechanism for guaranteeing left-to-right evaluation ala pseq in Haskell Prime? cheers peter From malcolm.wallace at cs.york.ac.uk Fri Aug 7 05:37:21 2009 From: malcolm.wallace at cs.york.ac.uk (Malcolm Wallace) Date: Fri Aug 7 05:18:04 2009 Subject: bug in language definition (strictness) In-Reply-To: <4A7BDE6A.6090507@gmail.com> References: <0365D78A-38D2-4AB3-A591-E5DD9FD25925@cs.york.ac.uk> <4A7ACE92.4020503@cs.nott.ac.uk> <3F6B656D-6F4A-4F4D-B6DB-57C9E2843302@kent.ac.uk> <4A7AD3C9.4090302@gmail.com> <8116107F-2190-4D9B-AB3C-C3BBC1BAE29F@gmail.com> <4A7AE20F.308@gmail.com> <4A7AFDEF.7030800@gmail.com> <97E3999E-AC1E-4CAA-B52C-4A7A23F2A7E7@cs.york.ac.uk> <4A7BDE6A.6090507@gmail.com> Message-ID: <9426E8DA-0FF4-4126-8420-98E27C10983A@cs.york.ac.uk> >> Yet I think it would be >> valid to say that seq can turn a non-terminating (exceptioning) >> program >> into a terminating one. > > Do you have an example of that? Sure. foldl (+) 0 [1..10000000] :: Integer *** Exception: stack overflow foldl' (+) 0 [1..10000000] :: Integer 50000005000000 The only difference between foldl and foldl' is strictness (the use of seq). By "non-terminating (exceptioning)" I of course really meant "terminating with bottom" as opposed to "terminating with a defined value", but since non-termination and exceptions are semantically both bottom, you won't mind that slip. :-) Regards, Malcolm From malcolm.wallace at cs.york.ac.uk Fri Aug 7 06:30:43 2009 From: malcolm.wallace at cs.york.ac.uk (Malcolm Wallace) Date: Fri Aug 7 06:11:25 2009 Subject: bug in language definition (strictness) In-Reply-To: <4A7BE00B.8070008@gmail.com> References: <0365D78A-38D2-4AB3-A591-E5DD9FD25925@cs.york.ac.uk> <4A7ACE92.4020503@cs.nott.ac.uk> <3F6B656D-6F4A-4F4D-B6DB-57C9E2843302@kent.ac.uk> <4A7AD3C9.4090302@gmail.com> <8116107F-2190-4D9B-AB3C-C3BBC1BAE29F@gmail.com> <4A7AE20F.308@gmail.com> <48A5A7F0-0E65-4642-8249-DB78828C373D@gmail.com> <4A7BE00B.8070008@gmail.com> Message-ID: <94B35AB2-E875-4C4F-A644-503B1960EA16@cs.york.ac.uk> > If, as I understand it, you are relying on the fact that seq's first > argument is evaluted before its second, then you really want pseq > rather than seq. > > In GHC we provide a way to do what you want (pseq), I'm just not > convinced it should be the required behaviour of seq. Whilst looking for something else, I have discovered that the official list of changes from Haskell 1.2 to Haskell 1.3 has this explicit statement: "The seq function evaluates its first argument before returning the second one." http://haskell.org/definition/from12to13.html In addition, the 1.3 and 1.4 Reports, in describing how seq should be understood for any particular type, states: "The _case_ is used to force evaluation of the first argument to `seq` before returning the second argument." The Haskell'98 committee decided to remove the Eval class (that had seq as one of its methods), see http://www.cs.chalmers.se/~rjmh/Haskell/Messages/Decision.cgi?id=204 I assume that it was simply inattention whilst editing the Report text, that caused the removal of the official requirement that seq evaluate its first argument before its second, because I can find no discussion by the committee that suggested such an important change. If you can point me to the committee discussion that led to changing this requirement, I would be grateful. Regards, Malcolm From ravi at bluespec.com Fri Aug 7 07:17:42 2009 From: ravi at bluespec.com (Ravi Nanavati) Date: Fri Aug 7 06:58:23 2009 Subject: bug in language definition (strictness) In-Reply-To: <94B35AB2-E875-4C4F-A644-503B1960EA16@cs.york.ac.uk> References: <0365D78A-38D2-4AB3-A591-E5DD9FD25925@cs.york.ac.uk> <4A7ACE92.4020503@cs.nott.ac.uk> <3F6B656D-6F4A-4F4D-B6DB-57C9E2843302@kent.ac.uk> <4A7AD3C9.4090302@gmail.com> <8116107F-2190-4D9B-AB3C-C3BBC1BAE29F@gmail.com> <4A7AE20F.308@gmail.com> <48A5A7F0-0E65-4642-8249-DB78828C373D@gmail.com> <4A7BE00B.8070008@gmail.com> <94B35AB2-E875-4C4F-A644-503B1960EA16@cs.york.ac.uk> Message-ID: <7b977d860908070417q740faab6lb46f7372914fbd1c@mail.gmail.com> I wonder if this discussion has veered too far into legalistic reasoning (of various sorts). From where I'm standing the state-of-play is this: 1. Compiler writers (and some users) want a "liberal" version of seq (that's slippery about evaluation order) for optimizations and better correspondence with the denotational semantics. 2. Other users want a version of seq that guarantees evaluation order for use cases where that matters. Is there any deep reason why we don't just figure out what the best way to give people both versions of seq is and do that? Thanks, - Ravi On Fri, Aug 7, 2009 at 6:30 AM, Malcolm Wallace wrote: >> If, as I understand it, you are relying on the fact that seq's first >> argument is evaluted before its second, then you really want pseq rather >> than seq. >> >> In GHC we provide a way to do what you want (pseq), I'm just not convinced >> it should be the required behaviour of seq. > > Whilst looking for something else, I have discovered that the official list > of changes from Haskell 1.2 to Haskell 1.3 has this explicit statement: > > "The seq function evaluates its first argument before returning the second > one." > ? ? ? ?http://haskell.org/definition/from12to13.html > > In addition, the 1.3 and 1.4 Reports, in describing how seq should be > understood for any particular type, states: > > "The _case_ is used to force evaluation of the first argument to `seq` > before returning the second argument." > > The Haskell'98 committee decided to remove the Eval class (that had seq as > one of its methods), see > http://www.cs.chalmers.se/~rjmh/Haskell/Messages/Decision.cgi?id=204 > > I assume that it was simply inattention whilst editing the Report text, that > caused the removal of the official requirement that seq evaluate its first > argument before its second, because I can find no discussion by the > committee that suggested such an important change. > > If you can point me to the committee discussion that led to changing this > requirement, I would be grateful. > > Regards, > ? ?Malcolm > > _______________________________________________ > Haskell-prime mailing list > Haskell-prime@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-prime > From simonpj at microsoft.com Fri Aug 7 13:04:05 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Fri Aug 7 12:44:50 2009 Subject: NoMonomorphismRestriction In-Reply-To: <4A7B5C53.2030307@isaac.cedarswampstudios.org> References: <20090725152847.GA31765@matrix.chaos.earth.li> <4A6D7D95.6000004@gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C357F36E7AD4@EA-EXMSG-C334.europe.corp.microsoft.com> <4A7B5C53.2030307@isaac.cedarswampstudios.org> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C357F36E81AE@EA-EXMSG-C334.europe.corp.microsoft.com> | . Understanding how to respond to type inference and error messages is | hard enough without having additional differences in innocent-looking | code. Do you think my hope is reasonable that not-generalizing could | lead to better error messages? I don't think it's obvious one way or the other. We'll have to see. | typechecker behaviors to think about. I guess it's still possible to | use explicit type-signatures to make let-bindings polymorphic, Yes, just so | in a way | that is difficult or impossible for lambda or case? (I guess for lambda, | it would require making the lambda into a rank-2 function, though I'm | not sure how to do that syntactically.) Easy: \(x :: forall a. a->a) -> blah Simon From westondan at imageworks.com Fri Aug 7 13:49:21 2009 From: westondan at imageworks.com (Dan Weston) Date: Fri Aug 7 13:30:04 2009 Subject: bug in language definition (strictness) In-Reply-To: <9426E8DA-0FF4-4126-8420-98E27C10983A@cs.york.ac.uk> References: <0365D78A-38D2-4AB3-A591-E5DD9FD25925@cs.york.ac.uk> <4A7ACE92.4020503@cs.nott.ac.uk> <3F6B656D-6F4A-4F4D-B6DB-57C9E2843302@kent.ac.uk> <4A7AD3C9.4090302@gmail.com> <8116107F-2190-4D9B-AB3C-C3BBC1BAE29F@gmail.com> <4A7AE20F.308@gmail.com> <4A7AFDEF.7030800@gmail.com> <97E3999E-AC1E-4CAA-B52C-4A7A23F2A7E7@cs.york.ac.uk> <4A7BDE6A.6090507@gmail.com> <9426E8DA-0FF4-4126-8420-98E27C10983A@cs.york.ac.uk> Message-ID: <4A7C6921.1030604@imageworks.com> > foldl (+) 0 [1..10000000] :: Integer > *** Exception: stack overflow > foldl' (+) 0 [1..10000000] :: Integer > 50000005000000 I thought both of these were perfectly well defined in denotational semantics (and equal to 50000005000000). The first is merely a failure of one person's computer to implement the (perfectly well-defined) denotational semantics of the program. If we are going to document the officially valid deficiencies of each compiler and machine architecture, perhaps that should not be in the *language* definition, but in the Haskell Platform users' guide. And those who are trying to distinguish between terminating and nonterminating bottom are claiming to solve the Halting Problem. There is no general way to reliably distinguish these two, and I believe that valid program transformations exist that can convert one to the other. Bottom has only one value, not two. Otherwise bottom would have been called buttocks. Dan Malcolm Wallace wrote: >>> Yet I think it would be >>> valid to say that seq can turn a non-terminating (exceptioning) >>> program >>> into a terminating one. >> Do you have an example of that? > > Sure. > foldl (+) 0 [1..10000000] :: Integer > *** Exception: stack overflow > foldl' (+) 0 [1..10000000] :: Integer > 50000005000000 > > The only difference between foldl and foldl' is strictness (the use of > seq). By "non-terminating (exceptioning)" I of course really meant > "terminating with bottom" as opposed to "terminating with a defined > value", but since non-termination and exceptions are semantically both > bottom, you won't mind that slip. :-) > > Regards, > Malcolm > > _______________________________________________ > Haskell-prime mailing list > Haskell-prime@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-prime > > From ravi at bluespec.com Fri Aug 7 14:23:26 2009 From: ravi at bluespec.com (Ravi Nanavati) Date: Fri Aug 7 14:04:05 2009 Subject: NoMonomorphismRestriction In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C357F36E81AE@EA-EXMSG-C334.europe.corp.microsoft.com> References: <20090725152847.GA31765@matrix.chaos.earth.li> <4A6D7D95.6000004@gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C357F36E7AD4@EA-EXMSG-C334.europe.corp.microsoft.com> <4A7B5C53.2030307@isaac.cedarswampstudios.org> <638ABD0A29C8884A91BC5FB5C349B1C357F36E81AE@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <7b977d860908071123n40531deev445e82e0c1f40b9a@mail.gmail.com> On Fri, Aug 7, 2009 at 1:04 PM, Simon Peyton-Jones wrote: > | . Understanding how to respond to type inference and error messages is > | hard enough without having additional differences in innocent-looking > | code. ?Do you think my hope is reasonable that not-generalizing could > | lead to better error messages? > > I don't think it's obvious one way or the other. We'll have to see. The Bluespec experience with local bindings (complicated by our "imperative desugaring", but my opinion is that's mostly an irrelevant complication) is that automatically generalized local bindings create all sorts of user-level havoc: poor error messages for one, programs that surprisingly typecheck or have other surprising behaviors and so on. And I wouldn't blame these issues on Bluespec's desire to hide the type system details from our users - when some sort of polymorphism-related problem is discovered it is common for people at Bluespec itself to be confused and have trouble isolating the underlying issue. Based on that experience, I'd expect that removing the automatic generalization of local bindings would lead to many positive user-level side-effects that are independent of any implementation simplifications that result. In fact, when I first heard the suggestion (via Joe Stoy) I started looking for an excuse to end (or at least limit) Bluespec's generalization of local bindings, since I think the backwards compatibility issues that result will be more than worth it in the long run. - Ravi From malcolm.wallace at cs.york.ac.uk Fri Aug 7 17:03:16 2009 From: malcolm.wallace at cs.york.ac.uk (Malcolm Wallace) Date: Fri Aug 7 16:43:56 2009 Subject: NoMonomorphismRestriction In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C357F36E7AD4@EA-EXMSG-C334.europe.corp.microsoft.com> References: <20090725152847.GA31765@matrix.chaos.earth.li> <4A6D7D95.6000004@gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C357F36E7AD4@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <5CAD8602-1B48-4CF1-B35D-0FBEDE95264E@cs.york.ac.uk> On 6 Aug 2009, at 12:18, Simon Peyton-Jones wrote: > The paper makes the (somewhat radical) case for not generalising > local bindings at all; which would at a stroke remove most of the > issues of the MR. (We'd still need to think about the top level.) Only the other day I was writing some code that used a case analysis to build a value I hoped would be polymorphic, and it kept refusing to type-check. Doing the case analysis on a different part of the value, then cutting and pasting the branch code multiple times did however seem to work. Suddenly I remembered about the difference in generalisation between let- and lambda- bindings, and could solve the problem by changing the case to a let! Instantly I could delete the error-prone cut-n-paste copies, and be more assured of the consistency of my code. Regards, Malcolm From marlowsd at gmail.com Fri Aug 7 18:21:17 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Fri Aug 7 18:01:53 2009 Subject: bug in language definition (strictness) In-Reply-To: <4A7C6921.1030604@imageworks.com> References: <0365D78A-38D2-4AB3-A591-E5DD9FD25925@cs.york.ac.uk> <4A7ACE92.4020503@cs.nott.ac.uk> <3F6B656D-6F4A-4F4D-B6DB-57C9E2843302@kent.ac.uk> <4A7AD3C9.4090302@gmail.com> <8116107F-2190-4D9B-AB3C-C3BBC1BAE29F@gmail.com> <4A7AE20F.308@gmail.com> <4A7AFDEF.7030800@gmail.com> <97E3999E-AC1E-4CAA-B52C-4A7A23F2A7E7@cs.york.ac.uk> <4A7BDE6A.6090507@gmail.com> <9426E8DA-0FF4-4126-8420-98E27C10983A@cs.york.ac.uk> <4A7C6921.1030604@imageworks.com> Message-ID: <4A7CA8DD.6090004@gmail.com> Dan Weston wrote: > > > foldl (+) 0 [1..10000000] :: Integer > > *** Exception: stack overflow > > foldl' (+) 0 [1..10000000] :: Integer > > 50000005000000 > > I thought both of these were perfectly well defined in denotational > semantics (and equal to 50000005000000). The first is merely a failure > of one person's computer to implement the (perfectly well-defined) > denotational semantics of the program. Quite. It's slightly confusing that a stack overflow manifests in the same way as an exception that indicates _|_, such as error or divide by zero. It's exactly the same as if you'd pressed Control-C during the first evaluation. That doesn't cause the expression to have value _|_, but it does raise an exception. The type of the exception is some help: StackOverflow is a constructor in the AsyncException datatype, indicating that it was an asynchronous exception. Evaluating the expression again might yield a result. Cheers, Simon From iavor.diatchki at gmail.com Sat Aug 8 05:09:38 2009 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Sat Aug 8 04:50:15 2009 Subject: Proposals and owners In-Reply-To: <20090806144958.GA20695@soi.city.ac.uk> References: <4A5355FE.9010901@gmail.com> <4A5461C9.5020501@gmail.com> <20090708093328.GA6162@soi.city.ac.uk> <20090711090128.GA5861@soi.city.ac.uk> <20090806144958.GA20695@soi.city.ac.uk> Message-ID: <5ab17e790908080209r6a0f5a72s2c4f17d7e2538db7@mail.gmail.com> I thought that the intended semantics was supposed to be that the only element is bottom (hence the proposal to add a related empty case construct)? On Thu, Aug 6, 2009 at 3:49 PM, Ross Paterson wrote: > On Wed, Jul 29, 2009 at 02:34:26PM -0400, Stephanie Weirich wrote: >> Ok, I've put together a page on EmptyDataDecls: >> >> http://hackage.haskell.org/trac/haskell-prime/wiki/EmptyDataDecls > > I think this needs a sentence about semantics, to the effect that the > type is abstract. ?(Not that its only element is bottom.) > _______________________________________________ > Haskell-prime mailing list > Haskell-prime@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-prime > From ross at soi.city.ac.uk Sat Aug 8 05:24:20 2009 From: ross at soi.city.ac.uk (Ross Paterson) Date: Sat Aug 8 05:04:59 2009 Subject: Proposals and owners In-Reply-To: <5ab17e790908080209r6a0f5a72s2c4f17d7e2538db7@mail.gmail.com> References: <4A5355FE.9010901@gmail.com> <4A5461C9.5020501@gmail.com> <20090708093328.GA6162@soi.city.ac.uk> <20090711090128.GA5861@soi.city.ac.uk> <20090806144958.GA20695@soi.city.ac.uk> <5ab17e790908080209r6a0f5a72s2c4f17d7e2538db7@mail.gmail.com> Message-ID: <20090808092420.GA5891@soi.city.ac.uk> On Sat, Aug 08, 2009 at 10:09:38AM +0100, Iavor Diatchki wrote: > I thought that the intended semantics was supposed to be that the only > element is bottom (hence the proposal to add a related empty case > construct)? If that were the case, a compiler could legitimately discard any value of such a type, because it could be easily reconstructed. I don't think that is what is intended. From ml at isaac.cedarswampstudios.org Sat Aug 8 13:16:59 2009 From: ml at isaac.cedarswampstudios.org (Isaac Dupree) Date: Sat Aug 8 12:57:44 2009 Subject: Proposals and owners In-Reply-To: <20090808092420.GA5891@soi.city.ac.uk> References: <4A5355FE.9010901@gmail.com> <4A5461C9.5020501@gmail.com> <20090708093328.GA6162@soi.city.ac.uk> <20090711090128.GA5861@soi.city.ac.uk> <20090806144958.GA20695@soi.city.ac.uk> <5ab17e790908080209r6a0f5a72s2c4f17d7e2538db7@mail.gmail.com> <20090808092420.GA5891@soi.city.ac.uk> Message-ID: <4A7DB30B.8090209@isaac.cedarswampstudios.org> Ross Paterson wrote: > On Sat, Aug 08, 2009 at 10:09:38AM +0100, Iavor Diatchki wrote: >> I thought that the intended semantics was supposed to be that the only >> element is bottom (hence the proposal to add a related empty case >> construct)? > > If that were the case, a compiler could legitimately discard any value > of such a type, because it could be easily reconstructed. I don't > think that is what is intended. Actually, I think it is. I think that's a natural consequence of the way Haskell is specified. GHC tries to pick the kind of bottom that you expected, but it doesn't always work really well, because it's not actually specified in any sort of formal way... Now, with imprecise exceptions, I'm not sure a compiler could legitimately discard the value. (by the way, for a type that you can unsafeCoerce anything to, GHC has a special type named "Any". Which is not the same as a data type with no constructors.) -Isaac From duncan.coutts at worc.ox.ac.uk Mon Aug 10 20:50:01 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Aug 10 20:30:46 2009 Subject: [Haskell'-private] StricterLabelledFieldSyntax In-Reply-To: <20090726013459.GA18475@matrix.chaos.earth.li> References: <20090726013459.GA18475@matrix.chaos.earth.li> Message-ID: <1249951801.20327.10303.camel@localhost> On Sun, 2009-07-26 at 02:34 +0100, Ian Lynagh wrote: > Hi all, > > I've made a ticket and proposal page for making the labelled field > syntax stricter, e.g. making this illegal: > > data A = A {x :: Int} > > y :: Maybe A > y = Just A {x = 5} > > and requiring this instead: > > data A = A {x :: Int} > > y :: Maybe A > y = Just (A {x = 5}) I think I don't like it. It makes the "labelled function argument" trick much less nice syntactically. ... <- createProcess proc { cwd = Just "blah" } This is especially so if the labelled function argument is not the final parameter since then one cannot use $, you'd have to put the whole thing in ()'s. The labelled argument technique is one I think we should be making greater use of (eg look at the proliferation of openFile variants) so I don't think we should be changing the syntax to make it harder / uglier. Duncan From john at repetae.net Thu Aug 13 02:45:04 2009 From: john at repetae.net (John Meacham) Date: Thu Aug 13 02:25:32 2009 Subject: [Haskell'-private] StricterLabelledFieldSyntax In-Reply-To: <20090726013459.GA18475@matrix.chaos.earth.li> References: <20090726013459.GA18475@matrix.chaos.earth.li> Message-ID: <20090813064503.GI26470@sliver.repetae.net> On Sun, Jul 26, 2009 at 02:34:59AM +0100, Ian Lynagh wrote: > I've made a ticket and proposal page for making the labelled field > syntax stricter, e.g. making this illegal: > > data A = A {x :: Int} > > y :: Maybe A > y = Just A {x = 5} > > and requiring this instead: > > data A = A {x :: Int} > > y :: Maybe A > y = Just (A {x = 5}) I don't like this not only because it would make a lot of code more unwieldy, but it muddles the interpretation of how one interprets braces. Right now, we have a very simple rule, braces always bind to the left, no matter where they are used, you can always tell what they mean by the thing immediately preceeding them. Whether it is 'let', 'do', 'where', a constructor, or an expression, you have a simple rule to remember which is nice. Also, what about data declarations? Would we need something like below? It seems odd to apply such a rule sometimes but not others. > data Foo = (Foo { .. }) | ... John -- John Meacham - ?repetae.net?john? - http://notanumber.net/ From john at repetae.net Thu Aug 13 03:01:56 2009 From: john at repetae.net (John Meacham) Date: Thu Aug 13 02:42:20 2009 Subject: bug in language definition (strictness) In-Reply-To: <48A5A7F0-0E65-4642-8249-DB78828C373D@gmail.com> References: <0365D78A-38D2-4AB3-A591-E5DD9FD25925@cs.york.ac.uk> <4A7ACE92.4020503@cs.nott.ac.uk> <3F6B656D-6F4A-4F4D-B6DB-57C9E2843302@kent.ac.uk> <4A7AD3C9.4090302@gmail.com> <8116107F-2190-4D9B-AB3C-C3BBC1BAE29F@gmail.com> <4A7AE20F.308@gmail.com> <48A5A7F0-0E65-4642-8249-DB78828C373D@gmail.com> Message-ID: <20090813070156.GJ26470@sliver.repetae.net> On Fri, Aug 07, 2009 at 08:56:39AM +1000, Peter Gammie wrote: > How so? Take this code: > > newtype BDD = BDD (ForeignPtr Int) > > exists :: Group BDD -> BDD -> BDD > exists group bdd = bdd `seq` unsafePerformIO $ > withGroup group $ \ gid -> > do bdd_assoc bdd_manager gid > withBDD bdd ({#call unsafe bdd_exists#} bdd_manager) >>= > addBDDfinalizer Just a question, why not do > How so? Take this code: > > newtype BDD = BDD (ForeignPtr Int) > > exists :: Group BDD -> BDD -> BDD > exists group bdd = unsafePerformIO $ > bdd <- evaluate bdd > withGroup group $ \ gid -> > do bdd_assoc bdd_manager gid > withBDD bdd ({#call unsafe bdd_exists#} bdd_manager) >>= > addBDDfinalizer It seems that evaluate is exactly the thing to order evaluations in the IO monad. John -- John Meacham - ?repetae.net?john? - http://notanumber.net/ From igloo at earth.li Thu Aug 13 07:14:33 2009 From: igloo at earth.li (Ian Lynagh) Date: Thu Aug 13 06:54:55 2009 Subject: [Haskell'-private] StricterLabelledFieldSyntax In-Reply-To: <20090813064503.GI26470@sliver.repetae.net> References: <20090726013459.GA18475@matrix.chaos.earth.li> <20090813064503.GI26470@sliver.repetae.net> Message-ID: <20090813111433.GA19634@matrix.chaos.earth.li> On Wed, Aug 12, 2009 at 11:45:04PM -0700, John Meacham wrote: > > Also, what about data declarations? Would we need something like below? > It seems odd to apply such a rule sometimes but not others. > > > data Foo = (Foo { .. }) | ... You would not need these parentheses; nor would you need parentheses in foo = Foo { ... } Thanks Ian From jon.fairbairn at cl.cam.ac.uk Sat Aug 15 11:44:40 2009 From: jon.fairbairn at cl.cam.ac.uk (Jon Fairbairn) Date: Sat Aug 15 11:25:14 2009 Subject: Proposal: FirstClassFieldUpdates References: <20090726013459.GA18475@matrix.chaos.earth.li> <4A6C9652.8050508@isaac.cedarswampstudios.org> <638ABD0A29C8884A91BC5FB5C349B1C357F36E7AC7@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: Simon Peyton-Jones writes: > | Proposal: FirstClassFieldUpdates > | > | Summary: Add some syntax that makes field updates into > | functions. > > I'm wary about occupying too much "syntactic space" with > Haskell's named-field notation. If you had a keyword, like > update { foo = bar } meaning \x. x { foo = bar } that'd get > you into a new syntactic space. It'd also make the syntax too noisy to be of any interest. > But braces alone are so precious that I'm not sure that record > updates justify consuming them. I'm not particularly wedded to braces, it's simply that they are the syntax already used for updates, so to make updates first class that is the obvious choice. For first class updates I'd be happy with something like ?foo := bar?, but then I would want the syntax of record construction to be something similar. For some reason, the use of braces in record syntax differs from all others I can think of: all the rest are x {something; something; something} and can replaced by layout. So braces (with commas) for records at all is an irregularity. > > On a related matter, people want to use record syntax for > GADTs and existentials. For record selection and > construction these are more or less fine (ie one can make a > sensible spec). But record update is another matter. Haskell > 98 says that record update can change the type of a record > (contrary to some posts in this thread), but the > specification becomes really rather tricky for GADTs and > existentials. Indeed, I was going to propose that in H Prime > we might consider making update *not* change the type, > backing away from the current H98 story, but one that makes > the spec a lot easier. But various people have been arguing > in favour of the H98 story so I may have an uphill struggle! I'm coming back to this stuff rather late; I can't say I understand the interactions between GADTs, existentials and records. In the absence of those developments what I would have liked to have seen would have been a decomposition of data declarations and the resulting types into orthogonal parts. For one thing, allowing ?Constr a b c? for construction and pattern matching on something that was declared as ?Constr {x::A, y::B, z::C}? looks improper to me, and another is the restricted nature of Haskell?s union types (cf what I started to talk about at AngloHaskell; see for some notes on that) So the outline would be (forgive the poor choice of keywords here): 1. distinguishable types The type ?dtype Constr T1 T2?? would correspond to a single alternative of a data declaration (dtype is just an arbitrary keyword from distinguishable type). The idea is that two dtypes only match if their (fully qualified) constructors match. 2. Symmentric unions of distinguishable types A type (dtype1 | dtype2 | ?) corresponds to the alternatives of a data declaration. Note that ?|? can only be used on distinguishable types (and unions of distinguishable types). So a non-record-syntax data declaration data Widget = Thing1 A | Thing2 B | ? could still be valid but now be a shorthand for type Widget = dtype Thing1 A | dtype Thing2 B | ? One of the benefits of this is that the type of anything can be written down without having to refer to any declarations. 3. Once that is done, we can come up with a design for records: field1:=x . field2:=y . ? $ emptyRecord Now ?field:=x?; is a first class function, polymorphic on all records that have ?field? as a field. We might want to choose some nicer syntax for emptyRecord, (?{}? if you like), but the only other expression syntax needed is the pseudo operator ?:=?, though some syntax for the types would need to be designed. ?record (field1::Type1, ?)? would do, with ?record ()? for the empty record. There is no /need/ to use up precious braces ;-). * * * You?ll complain that this isn?t fully worked out, and as I say, I don?t know how it interacts with GADTs and other things I?m not up to date with. But as far as I remember, I could simulate all of this in Ponder?s type system, so it shouldn?t be too hard for someone au fait with the way things are currently done to specify it properly. -- J?n Fairbairn Jon.Fairbairn@cl.cam.ac.uk From uzytkownik2 at gmail.com Mon Aug 17 02:41:14 2009 From: uzytkownik2 at gmail.com (Maciej Piechotka) Date: Mon Aug 17 02:21:33 2009 Subject: Standarize GHC.Prim.Any Message-ID: <1250491274.27620.71.camel@notebook> I'm so sorry if I've done it wrong - it's my first contact with Haskell standardization and I base on http://hackage.haskell.org/trac/haskell-prime/wiki/Process . I hope it is not too late as well. Any from GHC.Prim makes unsafeCoerce much useful and safe. Can it be included in Unsafe.Coerce module? Pros: - unsafeCoerce is much more useful with Any (it's a safe placeholder for any value and therefore can be passed simply in/out FFI). Cons: - unsafeCoerce is useful, but not very nice, platorm-dependent low-level anyway. Best regards -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part Url : http://www.haskell.org/pipermail/haskell-prime/attachments/20090817/09be9e99/attachment.bin From marlowsd at gmail.com Mon Aug 17 08:02:29 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Aug 17 07:42:41 2009 Subject: bug in language definition (strictness) In-Reply-To: <7b977d860908070417q740faab6lb46f7372914fbd1c@mail.gmail.com> References: <0365D78A-38D2-4AB3-A591-E5DD9FD25925@cs.york.ac.uk> <4A7ACE92.4020503@cs.nott.ac.uk> <3F6B656D-6F4A-4F4D-B6DB-57C9E2843302@kent.ac.uk> <4A7AD3C9.4090302@gmail.com> <8116107F-2190-4D9B-AB3C-C3BBC1BAE29F@gmail.com> <4A7AE20F.308@gmail.com> <48A5A7F0-0E65-4642-8249-DB78828C373D@gmail.com> <4A7BE00B.8070008@gmail.com> <94B35AB2-E875-4C4F-A644-503B1960EA16@cs.york.ac.uk> <7b977d860908070417q740faab6lb46f7372914fbd1c@mail.gmail.com> Message-ID: <4A8946D5.5020807@gmail.com> On 07/08/2009 12:17, Ravi Nanavati wrote: > I wonder if this discussion has veered too far into legalistic > reasoning (of various sorts). From where I'm standing the > state-of-play is this: > > 1. Compiler writers (and some users) want a "liberal" version of seq > (that's slippery about evaluation order) for optimizations and better > correspondence with the denotational semantics. > 2. Other users want a version of seq that guarantees evaluation order > for use cases where that matters. > > Is there any deep reason why we don't just figure out what the best > way to give people both versions of seq is and do that? Compilers can provide seq with an ordering guarantee if they want, just as GHC does with Control.Parallel.pseq. I don't think it would be good to mandate this in the standard, for the reassons I've already described in this thread, in summary: - it constrains evaluation order in a way that Haskell doesn't currently do, and which might prevent interesting implementations (e.g. automatic parallelisation) - it's not clear how to specify what "seq with an ordering guarantee" actually means. If someone were to come up with a precise definition, that would be a much better basis for discussion. Cheers, Simon From ml at isaac.cedarswampstudios.org Mon Aug 17 19:52:26 2009 From: ml at isaac.cedarswampstudios.org (Isaac Dupree) Date: Mon Aug 17 19:32:46 2009 Subject: Standarize GHC.Prim.Any In-Reply-To: <1250491274.27620.71.camel@notebook> References: <1250491274.27620.71.camel@notebook> Message-ID: <4A89ED3A.1010507@isaac.cedarswampstudios.org> Maciej Piechotka wrote: > I'm so sorry if I've done it wrong - it's my first contact with Haskell > standardization and I base on > http://hackage.haskell.org/trac/haskell-prime/wiki/Process . I hope it > is not too late as well. Do not worry about that, we have decided to have a yearly standardization process. > Any from GHC.Prim makes unsafeCoerce much useful and safe. Can it be > included in Unsafe.Coerce module? > > Pros: > - unsafeCoerce is much more useful with Any (it's a safe placeholder for > any value and therefore can be passed simply in/out FFI). Yes it's a safe placeholder, but so is an existential, I believe... data ContainsAny = forall a. ContainsAny a to put in the container: "ContainsAny x" to remove from the container: "case ... of ContainsAny x -> unsafeCoerce x" Albeit, there might be a slight performance penalty for the extra box, which can't be removed in all haskell implementations. Also, what do you mean about "FFI"? I don't think you can pass the "Any" type to foreign functions through the FFI... Also, can/do all compilers that implement unsafeCoerce implement a safe Any? Hugs can do it with just "data Any = Ignored" I believe, not sure about nhc, yhc or jhc... -Isaac From malcolm.wallace at cs.york.ac.uk Tue Aug 18 05:05:13 2009 From: malcolm.wallace at cs.york.ac.uk (Malcolm Wallace) Date: Tue Aug 18 04:45:37 2009 Subject: Standarize GHC.Prim.Any In-Reply-To: <4A89ED3A.1010507@isaac.cedarswampstudios.org> References: <1250491274.27620.71.camel@notebook> <4A89ED3A.1010507@isaac.cedarswampstudios.org> Message-ID: <7A1D3125-0909-48AC-9C01-0A90C668F1A5@cs.york.ac.uk> > Also, can/do all compilers that implement unsafeCoerce implement a > safe Any? > Hugs can do it with just "data Any = Ignored" I believe, not sure > about nhc, yhc or jhc... nhc98 and yhc do not implement the Any type. unsafeCoerce is easily implemented without it. Regards, Malcolm From john at repetae.net Tue Aug 18 20:19:00 2009 From: john at repetae.net (John Meacham) Date: Tue Aug 18 19:59:05 2009 Subject: Standarize GHC.Prim.Any In-Reply-To: <4A89ED3A.1010507@isaac.cedarswampstudios.org> References: <1250491274.27620.71.camel@notebook> <4A89ED3A.1010507@isaac.cedarswampstudios.org> Message-ID: <20090819001900.GT26470@sliver.repetae.net> On Mon, Aug 17, 2009 at 07:52:26PM -0400, Isaac Dupree wrote: > Also, can/do all compilers that implement unsafeCoerce implement a safe Any? > Hugs can do it with just "data Any = Ignored" I believe, not sure about > nhc, yhc or jhc... Jhc has existentials, so that is the best way to handle this. Jhc existentials do require an invisible type parameter to be added to the representation so wouldn't be able to remove the extra box in general. Jhc implements unsafeCoerce, but it is really unsafe as the type information plays a major role in the data layout as jhc has no 'universal' run time representation of data. For instance, you might unsafeCoerce something that was statically determined to not need to be traversed by the garbage collector to something that the garbage collector follows, surely resulting in a segfault or other undefined behavior at run-time. This is the reason existentials always need to carry around their type information, if nothing else, it potentially guides the garbage collector. So, existentials really are the only safe way to do this in jhc. Really the only guarenteed safe use of unsafeCoerce in jhc is between a newtype and its underlying representation. John -- John Meacham - ?repetae.net?john? - http://notanumber.net/ From marlowsd at gmail.com Thu Aug 20 08:45:08 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Thu Aug 20 08:25:11 2009 Subject: Proposals and owners In-Reply-To: <20090808092420.GA5891@soi.city.ac.uk> References: <4A5355FE.9010901@gmail.com> <4A5461C9.5020501@gmail.com> <20090708093328.GA6162@soi.city.ac.uk> <20090711090128.GA5861@soi.city.ac.uk> <20090806144958.GA20695@soi.city.ac.uk> <5ab17e790908080209r6a0f5a72s2c4f17d7e2538db7@mail.gmail.com> <20090808092420.GA5891@soi.city.ac.uk> Message-ID: <4A8D4554.7000608@gmail.com> On 08/08/2009 10:24, Ross Paterson wrote: > On Sat, Aug 08, 2009 at 10:09:38AM +0100, Iavor Diatchki wrote: >> I thought that the intended semantics was supposed to be that the only >> element is bottom (hence the proposal to add a related empty case >> construct)? > > If that were the case, a compiler could legitimately discard any value > of such a type, because it could be easily reconstructed. I don't > think that is what is intended. Just in case this question is still open: an empty data declaration declares a type that has exactly zero constructors, not an abstract type. What would it mean to define an abstract types? Haskell only allows one definition of any given type. Cheers, Simon From ross at soi.city.ac.uk Thu Aug 20 08:54:07 2009 From: ross at soi.city.ac.uk (Ross Paterson) Date: Thu Aug 20 08:34:09 2009 Subject: Proposals and owners In-Reply-To: <4A8D4554.7000608@gmail.com> References: <4A5355FE.9010901@gmail.com> <4A5461C9.5020501@gmail.com> <20090708093328.GA6162@soi.city.ac.uk> <20090711090128.GA5861@soi.city.ac.uk> <20090806144958.GA20695@soi.city.ac.uk> <5ab17e790908080209r6a0f5a72s2c4f17d7e2538db7@mail.gmail.com> <20090808092420.GA5891@soi.city.ac.uk> <4A8D4554.7000608@gmail.com> Message-ID: <20090820125407.GA6202@soi.city.ac.uk> On Thu, Aug 20, 2009 at 01:45:08PM +0100, Simon Marlow wrote: > On 08/08/2009 10:24, Ross Paterson wrote: > >On Sat, Aug 08, 2009 at 10:09:38AM +0100, Iavor Diatchki wrote: > >>I thought that the intended semantics was supposed to be that the only > >>element is bottom (hence the proposal to add a related empty case > >>construct)? > > > >If that were the case, a compiler could legitimately discard any value > >of such a type, because it could be easily reconstructed. I don't > >think that is what is intended. > > Just in case this question is still open: an empty data declaration > declares a type that has exactly zero constructors, not an abstract > type. What would it mean to define an abstract types? Haskell only > allows one definition of any given type. Yes, I take it back. Such types are typically used as phantom type arguments, e.g. the argument of Ptr, so the question I raised doesn't arise. From uzytkownik2 at gmail.com Thu Aug 20 13:59:41 2009 From: uzytkownik2 at gmail.com (Maciej Piechotka) Date: Thu Aug 20 13:39:49 2009 Subject: Standarize GHC.Prim.Any In-Reply-To: <4A89ED3A.1010507@isaac.cedarswampstudios.org> References: <1250491274.27620.71.camel@notebook> <4A89ED3A.1010507@isaac.cedarswampstudios.org> Message-ID: <1250791182.2598.11.camel@notebook> Sorry for delay in responding. > > Any from GHC.Prim makes unsafeCoerce much useful and safe. Can it be > > included in Unsafe.Coerce module? > > > > Pros: > > - unsafeCoerce is much more useful with Any (it's a safe placeholder for > > any value and therefore can be passed simply in/out FFI). > > Yes it's a safe placeholder, but so is an existential, I believe... > data ContainsAny = forall a. ContainsAny a > to put in the container: > "ContainsAny x" > to remove from the container: > "case ... of ContainsAny x -> unsafeCoerce x" > Albeit, there might be a slight performance penalty for the extra box, > which can't be removed in all haskell implementations. > > Also, what do you mean about "FFI"? I don't think you can pass the > "Any" type to foreign functions through the FFI... > > Also, can/do all compilers that implement unsafeCoerce implement a safe Any? > Hugs can do it with just "data Any = Ignored" I believe, not sure about > nhc, yhc or jhc... > > -Isaac Well. May be I have one specific problem which seems to not be possible to be implemented in portable way (I'm not sure if it is possible outside ghc). Sorry for mentioning FFI without further explanation. The problem arise if one would like to implement GClosure from glib. Once it was implemented in gtk2hs in C using RTS API. I also have my own implementation in Haskell which is doing something (removed IO monad for clarity): applyValue :: Any -> Value -> Any applyValue f v = case funsamentalTypeOf v of Type1 -> (unsafeCoerce f :: HaskellType1 -> Any) $ get v ... Such trick is (looks for me?) safe as a -> b -> ... -> d can be represented by Any. However I cannot safely cast to function a -> Any. To/from FFI it is passed in Ptr (StablePtr Any). Regards PS. I assume that it is not possible as it was done in importable was in gtk2hs. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part Url : http://www.haskell.org/pipermail/haskell-prime/attachments/20090820/7e580612/attachment.bin From john at repetae.net Sat Aug 29 20:33:58 2009 From: john at repetae.net (John Meacham) Date: Sat Aug 29 20:13:30 2009 Subject: bug in language definition (strictness) In-Reply-To: <4A8946D5.5020807@gmail.com> References: <4A7ACE92.4020503@cs.nott.ac.uk> <3F6B656D-6F4A-4F4D-B6DB-57C9E2843302@kent.ac.uk> <4A7AD3C9.4090302@gmail.com> <8116107F-2190-4D9B-AB3C-C3BBC1BAE29F@gmail.com> <4A7AE20F.308@gmail.com> <48A5A7F0-0E65-4642-8249-DB78828C373D@gmail.com> <4A7BE00B.8070008@gmail.com> <94B35AB2-E875-4C4F-A644-503B1960EA16@cs.york.ac.uk> <7b977d860908070417q740faab6lb46f7372914fbd1c@mail.gmail.com> <4A8946D5.5020807@gmail.com> Message-ID: <20090830003358.GM8113@sliver.repetae.net> On Mon, Aug 17, 2009 at 01:02:29PM +0100, Simon Marlow wrote: > On 07/08/2009 12:17, Ravi Nanavati wrote: >> I wonder if this discussion has veered too far into legalistic >> reasoning (of various sorts). From where I'm standing the >> state-of-play is this: >> >> 1. Compiler writers (and some users) want a "liberal" version of seq >> (that's slippery about evaluation order) for optimizations and better >> correspondence with the denotational semantics. >> 2. Other users want a version of seq that guarantees evaluation order >> for use cases where that matters. >> >> Is there any deep reason why we don't just figure out what the best >> way to give people both versions of seq is and do that? > > Compilers can provide seq with an ordering guarantee if they want, just > as GHC does with Control.Parallel.pseq. I don't think it would be good > to mandate this in the standard, for the reassons I've already described > in this thread, in summary: > > - it constrains evaluation order in a way that Haskell > doesn't currently do, and which might prevent interesting > implementations (e.g. automatic parallelisation) > > - it's not clear how to specify what "seq with an ordering guarantee" > actually means. If someone were to come up with a precise > definition, that would be a much better basis for discussion. What is interesting is that pseq, or seq with an ordering guarentee, actually would introduce a lazyness, instead of strictness. in order to see this, we can observe what will have with the strictness analyzer. imagine the function f :: Int -> Int -> Int f x y = y `seq` x Now, the strictness analysis will see that f is strict in both its arguments, y because of seq, and x because it is what returned. we can say it derives the following annotated type (where ! means strict) f :: !Int -> !Int -> Int now, anything that calls f is free to evaluate its arguments before passing them to f, more importantly, it enables things like the worker-wrapper transform and unboxing. however if we have f x y = y `pseq` x now, what is the strictness for f? Although f is still 'strict' in both arguments in that it evaluates both, in order to guarentee the ordering that its second argument is evaluated before its first, it must be lazy in its first argument. or: f :: Int -> !Int -> Int otherwise the calling function may evaluate the first argument before the second, since the strictness information doesn't include ordering information. So, adding a 'pseq' actually gets rid of strictness. things get worse with something like j :: Bool -> Int -> Int -> Int j b x y = if b then f x y else f y x even though j is obviously strict in all its arguments in that it evaluates them all, the compiler cannot derive that fact since it doesn't know the _order_ in which they are strict. This suggests a natural implementation (and specification) for pseq, pseq :: a -> b -> b pseq x y = x `seq` lazy y where lazy :: a -> a is a compiler provided function equivalent to 'id' except that it is considered lazy in its argument by the strictness analyzer. So, I think an order preserving 'seq' is possible, but it has the ironic quality of introducing lazyness, rather than strictness. And if anything were proposed as a cross-compiler convention, I think 'lazy' would be a more useful and less confusing function to introduce as a portable primitive. John -- John Meacham - ?repetae.net?john? - http://notanumber.net/