From duncan.coutts at worc.ox.ac.uk Tue May 1 06:54:36 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue May 1 07:04:41 2007 Subject: Polymorphic strict fields In-Reply-To: <5ab17e790704301947od2d0038ydd7121f6a6bb0243@mail.gmail.com> References: <5ab17e790704301947od2d0038ydd7121f6a6bb0243@mail.gmail.com> Message-ID: <1178016876.6211.109.camel@localhost> On Mon, 2007-04-30 at 19:47 -0700, Iavor Diatchki wrote: > All of this leads me to think that perhaps we should not allow > strictness annotations on polymorphic fields. Would people find this > too restrictive? Yes. Our current implementation of stream fusion relies on this: data Stream a = forall s. Unlifted s => Stream !(s -> Step a s) -- ^ a stepper function !s -- ^ an initial state We use strictness on polymorphic (class constrained) fields to simulate unlifted types. We pretend that the stream state types are all unlifted and have various strict/unlifted type constructors: data (Unlifted a, Unlifted b) => a :!: b = !a :!: !b instance (Unlifted a, Unlifted b) => Unlifted (a :!: b) where ... Duncan From iavor.diatchki at gmail.com Tue May 1 12:50:06 2007 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Tue May 1 12:47:26 2007 Subject: Polymorphic strict fields In-Reply-To: <1178016876.6211.109.camel@localhost> References: <5ab17e790704301947od2d0038ydd7121f6a6bb0243@mail.gmail.com> <1178016876.6211.109.camel@localhost> Message-ID: <5ab17e790705010950pc353d68i312bc43620c16697@mail.gmail.com> Hello, On 5/1/07, Duncan Coutts wrote: > On Mon, 2007-04-30 at 19:47 -0700, Iavor Diatchki wrote: > > > All of this leads me to think that perhaps we should not allow > > strictness annotations on polymorphic fields. Would people find this > > too restrictive? > > Yes. > > Our current implementation of stream fusion relies on this: > > data Stream a = forall s. Unlifted s => > Stream !(s -> Step a s) -- ^ a stepper function > !s -- ^ an initial state > > We use strictness on polymorphic (class constrained) fields to simulate > unlifted types. We pretend that the stream state types are all unlifted > and have various strict/unlifted type constructors: This declaration uses existential and not universal quantification. More concretely, there exists some type that classifies the state of the stream but the users of the stream do not know what it is (by the way I saw Don talk about this stream stuff and I think that it is quite cool!). A polymorphic field is one where the ``forall`` is associated with the field (it comes after the constructor), it allows you to store polymorphic values in a datatype. Here is an example: data T = T (forall a. a -> a) make = T id use (T f) = (f True, f 'a') Hope this helps -Iavor From duncan.coutts at worc.ox.ac.uk Tue May 1 15:00:08 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue May 1 15:10:11 2007 Subject: Polymorphic strict fields In-Reply-To: <5ab17e790705010950pc353d68i312bc43620c16697@mail.gmail.com> References: <5ab17e790704301947od2d0038ydd7121f6a6bb0243@mail.gmail.com> <1178016876.6211.109.camel@localhost> <5ab17e790705010950pc353d68i312bc43620c16697@mail.gmail.com> Message-ID: <1178046008.9770.3.camel@localhost> On Tue, 2007-05-01 at 09:50 -0700, Iavor Diatchki wrote: > Hello, > > On 5/1/07, Duncan Coutts wrote: > > On Mon, 2007-04-30 at 19:47 -0700, Iavor Diatchki wrote: > > > > > All of this leads me to think that perhaps we should not allow > > > strictness annotations on polymorphic fields. Would people find this > > > too restrictive? > > > > Yes. > > > > Our current implementation of stream fusion relies on this: > > > > data Stream a = forall s. Unlifted s => > > Stream !(s -> Step a s) -- ^ a stepper function > > !s -- ^ an initial state > > > > We use strictness on polymorphic (class constrained) fields to simulate > > unlifted types. We pretend that the stream state types are all unlifted > > and have various strict/unlifted type constructors: > > This declaration uses existential and not universal quantification. > More concretely, there exists some type that classifies the state of > the stream but the users of the stream do not know what it is (by the > way I saw Don talk about this stream stuff and I think that it is > quite cool!). A polymorphic field is one where the ``forall`` is > associated with the field (it comes after the constructor), it allows > you to store polymorphic values in a datatype. Ah ok. When you said "strictness annotations on polymorphic fields" I assumed you meant just ordinary things like: data A a = A !a rather than local universal quantification. Duncan From ashley at semantic.org Thu May 3 01:47:51 2007 From: ashley at semantic.org (Ashley Yakeley) Date: Thu May 3 01:45:23 2007 Subject: Polymorphic strict fields In-Reply-To: <5ab17e790704301947od2d0038ydd7121f6a6bb0243@mail.gmail.com> References: <5ab17e790704301947od2d0038ydd7121f6a6bb0243@mail.gmail.com> Message-ID: Iavor Diatchki wrote: > Notice, furthermore, that the behavior of such constructors may be a > bit unexpected when combined with overloading. Consider, for example, > the following declarations: > >> data T = T !(forall a. Eq a => a) >> test = seq (T undefined) True > > In GHC 6.6 ``test`` evaluets to ``True`` because ``undefined`` is > converted to a function that expects its implict evidence argument. It's the same with functions: myseq :: (forall a. Eq a => a) -> b -> b myseq = seq myseq undefined True ==> True -- Ashley Yakeley From simonmarhaskell at gmail.com Mon May 14 05:19:07 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Mon May 14 05:15:57 2007 Subject: Wanted: warning option for usages of unary minus In-Reply-To: <20070508032640.GE13654@momenergy.repetae.net> References: <46181A52.8070108@charter.net> <4618E17D.4060706@charter.net> <461C96C1.40408@gmail.com> <20070508032640.GE13654@momenergy.repetae.net> Message-ID: <4648298B.9090300@gmail.com> John Meacham wrote: > On Wed, Apr 11, 2007 at 09:05:21AM +0100, Simon Marlow wrote: >> I definitely think that -1# should be parsed as a single lexeme. >> Presumably it was easier at the time to do it the way it is, I don't >> remember exactly. >> >> I'd support a warning for use of prefix negation, or alternatively you >> could implement the Haskell' proposal to remove prefix negation completely >> - treat the unary minus as part of a numeric literal in the lexer only. >> This would have to be optional for now, so that we can continue to support >> Haskell 98 of course. > > yes please! odd that I look forward to such a minor change in the big > scheme of things, but the current treatment of negation has annoyed me > more than any other misfeature I think. Really? I'm beginning to have second thoughts about the proposed change to negation for Haskell'. The main reason, and this isn't pointed out as well as it should be on the wiki, is that "x-1" will cease to be an infix application of (-), it will parse as x applied to the literal (-1). And this is different from "x - 1" (syntax in which whitespace matters should be avoided like the plague, IMO). I think this would be worse than the current situation. Cheers, Simon From iavor.diatchki at gmail.com Mon May 14 13:48:35 2007 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Mon May 14 13:45:14 2007 Subject: Wanted: warning option for usages of unary minus In-Reply-To: <4648298B.9090300@gmail.com> References: <46181A52.8070108@charter.net> <4618E17D.4060706@charter.net> <461C96C1.40408@gmail.com> <20070508032640.GE13654@momenergy.repetae.net> <4648298B.9090300@gmail.com> Message-ID: <5ab17e790705141048y1ac7770g1ec56b856773ff39@mail.gmail.com> Hello, I agree with Simon on this one: "x-1" should parse as expected (i.e., the infix operator "-" applied to two arguments "x" and "1"). Having this result in a type error would be confusing to both beginners and working Haskell programmers. I think that if we want to change anything at all, we should simply eliminate the unary negation operator without changing the lexer (i.e., we would have only positive literals). Then we would have to be explicit about what is currently happening implicitly in Haskell98---we would write "negate 1" instead of "-1". However, I don't thinks that this change is justified---as far as I can see, the only benefit is that it simplifies the parser. However, the change is not backward compatible and may break some programs. -Iavor On 5/14/07, Simon Marlow wrote: > John Meacham wrote: > > On Wed, Apr 11, 2007 at 09:05:21AM +0100, Simon Marlow wrote: > >> I definitely think that -1# should be parsed as a single lexeme. > >> Presumably it was easier at the time to do it the way it is, I don't > >> remember exactly. > >> > >> I'd support a warning for use of prefix negation, or alternatively you > >> could implement the Haskell' proposal to remove prefix negation completely > >> - treat the unary minus as part of a numeric literal in the lexer only. > >> This would have to be optional for now, so that we can continue to support > >> Haskell 98 of course. > > > > yes please! odd that I look forward to such a minor change in the big > > scheme of things, but the current treatment of negation has annoyed me > > more than any other misfeature I think. > > Really? I'm beginning to have second thoughts about the proposed change to > negation for Haskell'. The main reason, and this isn't pointed out as well as > it should be on the wiki, is that "x-1" will cease to be an infix application of > (-), it will parse as x applied to the literal (-1). And this is different from > "x - 1" (syntax in which whitespace matters should be avoided like the plague, > IMO). I think this would be worse than the current situation. > > Cheers, > Simon > > > _______________________________________________ > Haskell-prime mailing list > Haskell-prime@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-prime > From isaacdupree at charter.net Thu May 17 06:37:04 2007 From: isaacdupree at charter.net (Isaac Dupree) Date: Thu May 17 06:32:19 2007 Subject: Wanted: warning option for usages of unary minus In-Reply-To: <5ab17e790705141048y1ac7770g1ec56b856773ff39@mail.gmail.com> References: <46181A52.8070108@charter.net> <4618E17D.4060706@charter.net> <461C96C1.40408@gmail.com> <20070508032640.GE13654@momenergy.repetae.net> <4648298B.9090300@gmail.com> <5ab17e790705141048y1ac7770g1ec56b856773ff39@mail.gmail.com> Message-ID: <464C3050.9060203@charter.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Iavor Diatchki wrote: > Hello, > > I agree with Simon on this one: "x-1" should parse as expected (i.e., > the infix operator "-" applied to two arguments "x" and "1"). Having > this result in a type error would be confusing to both beginners and > working Haskell programmers. > > I think that if we want to change anything at all, we should simply > eliminate the unary negation operator without changing the lexer > (i.e., we would have only positive literals). Then we would have to > be explicit about what is currently happening implicitly in > Haskell98---we would write "negate 1" instead of "-1". > > However, I don't thinks that this change is justified---as far as I > can see, the only benefit is that it simplifies the parser. However, > the change is not backward compatible and may break some programs. Simplifies the _mental_ parser, much more important than the compilers' parsers which are already implemented. Here is what I am thinking to do: In my own code, since there seems to be so much difficulty with the matter, don't use (-X) to mean negative for any kind of X whatsoever. For this I want a warning for ALL usages of the unary minus operator. I'll define a function for my negative literals that calls fromInteger and negate in the order I would prefer to my sensibilities, which is actually different from the order that the Report specifies for (-x) : > {-# INLINE negative #-} > negative :: Num a => Integer -> a > negative a = fromInteger (negate a) I might feel like having a parallel > {-# INLINE positive #-} > positive :: Num a => Integer -> a > positive a = fromInteger a (e.g. C has a unary + operator... and "positive" even has the same number-of-characters length as "negative"!). For GHC's unboxed negative literals I think I will still change the lexer/parser since the current way it's done is rather confusing anyway (as previously described) I don't know what else is worth implementing... NOT an option to turn off parsing of unary minus, since warnings are good and it would just create more incompatibility. John Meacham, since you seem to be interested, what are your thoughts now? Advice on flag names - or any other discussion! is anyone interested in having something, say so? - would be appreciated. Isaac -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGTDBQHgcxvIWYTTURAt14AJ9+Avd3FJ54+f0eNzUBFM7tOPy5TgCfRys8 usEFDx9uNH2UjUHBbG9kyGs= =M3CU -----END PGP SIGNATURE----- From jhf at lanl.gov Thu May 17 11:52:02 2007 From: jhf at lanl.gov (Joseph H. Fasel) Date: Thu May 17 11:48:32 2007 Subject: Wanted: warning option for usages of unary minus In-Reply-To: <464C3050.9060203@charter.net> References: <46181A52.8070108@charter.net> <4618E17D.4060706@charter.net> <461C96C1.40408@gmail.com> <20070508032640.GE13654@momenergy.repetae.net> <4648298B.9090300@gmail.com> <5ab17e790705141048y1ac7770g1ec56b856773ff39@mail.gmail.com> <464C3050.9060203@charter.net> Message-ID: <1179417122.32514.19.camel@escoria.lanl.gov> *Sigh* The problems with unary minus were discussed in the dim mists of time before we published the first Haskell report. We considered then using a separate symbol for unary negation (as does APL, for example), but (IIRC) this was regarded as unfriendly to Fortran programmers. Cheers, --Joe On Thu, 2007-05-17 at 04:37, Isaac Dupree wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Iavor Diatchki wrote: > > Hello, > > > > I agree with Simon on this one: "x-1" should parse as expected (i.e., > > the infix operator "-" applied to two arguments "x" and "1"). Having > > this result in a type error would be confusing to both beginners and > > working Haskell programmers. > > > > I think that if we want to change anything at all, we should simply > > eliminate the unary negation operator without changing the lexer > > (i.e., we would have only positive literals). Then we would have to > > be explicit about what is currently happening implicitly in > > Haskell98---we would write "negate 1" instead of "-1". > > > > However, I don't thinks that this change is justified---as far as I > > can see, the only benefit is that it simplifies the parser. However, > > the change is not backward compatible and may break some programs. > > Simplifies the _mental_ parser, much more important than the compilers' > parsers which are already implemented. > > Here is what I am thinking to do: > > In my own code, since there seems to be so much difficulty with the > matter, don't use (-X) to mean negative for any kind of X whatsoever. > For this I want a warning for ALL usages of the unary minus operator. > I'll define a function for my negative literals that calls fromInteger > and negate in the order I would prefer to my sensibilities, which is > actually different from the order that the Report specifies for (-x) : > > > {-# INLINE negative #-} > > negative :: Num a => Integer -> a > > negative a = fromInteger (negate a) > > I might feel like having a parallel > > > {-# INLINE positive #-} > > positive :: Num a => Integer -> a > > positive a = fromInteger a > > (e.g. C has a unary + operator... and "positive" even has the same > number-of-characters length as "negative"!). > > > For GHC's unboxed negative literals I think I will still change the > lexer/parser since the current way it's done is rather confusing anyway > (as previously described) > > > I don't know what else is worth implementing... NOT an option to turn > off parsing of unary minus, since warnings are good and it would just > create more incompatibility. John Meacham, since you seem to be > interested, what are your thoughts now? Advice on flag names - or any > other discussion! is anyone interested in having something, say so? - > would be appreciated. > > > Isaac > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFGTDBQHgcxvIWYTTURAt14AJ9+Avd3FJ54+f0eNzUBFM7tOPy5TgCfRys8 > usEFDx9uNH2UjUHBbG9kyGs= > =M3CU > -----END PGP SIGNATURE----- > _______________________________________________ > Haskell-prime mailing list > Haskell-prime@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-prime -- Joseph H. Fasel, Ph.D. Process Modeling and Analysis AET-2, MS F609 Los Alamos National Laboratory Los Alamos, NM 87545 From twanvl at gmail.com Thu May 17 12:40:04 2007 From: twanvl at gmail.com (Twan van Laarhoven) Date: Thu May 17 12:36:33 2007 Subject: Wanted: warning option for usages of unary minus In-Reply-To: <4648298B.9090300@gmail.com> References: <46181A52.8070108@charter.net> <4618E17D.4060706@charter.net> <461C96C1.40408@gmail.com> <20070508032640.GE13654@momenergy.repetae.net> <4648298B.9090300@gmail.com> Message-ID: <464C8564.3020006@gmail.com> Simon Marlow wrote: > ... > > Really? I'm beginning to have second thoughts about the proposed change > to negation for Haskell'. The main reason, and this isn't pointed out > as well as it should be on the wiki, is that "x-1" will cease to be an > infix application of (-), it will parse as x applied to the literal > (-1). And this is different from "x - 1" There is one other alternative for parsing: "-" is a unary minus if and only if it is a) preceded by whitespace or one of "[({;,", and b) not followed by whitespace. So: x - 1 == (-) x 1 x-1 == (-) x 1 x -1 == x (negate 1) x -(1) == x (negate 1) x (-1) == x (negate 1) x (- 1) == x (\y -> y - 1) Just an idea. Twan From isaacdupree at charter.net Thu May 17 13:36:49 2007 From: isaacdupree at charter.net (Isaac Dupree) Date: Thu May 17 13:31:59 2007 Subject: Wanted: warning option for usages of unary minus In-Reply-To: <464C3050.9060203@charter.net> References: <46181A52.8070108@charter.net> <4618E17D.4060706@charter.net> <461C96C1.40408@gmail.com> <20070508032640.GE13654@momenergy.repetae.net> <4648298B.9090300@gmail.com> <5ab17e790705141048y1ac7770g1ec56b856773ff39@mail.gmail.com> <464C3050.9060203@charter.net> Message-ID: <464C92B1.4050205@charter.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I wrote: >> negative :: Num a => Integer -> a >> negative a = fromInteger (negate a) Oops, I forgot Rational literals, they make things a little more complicated :( Isaac -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGTJKxHgcxvIWYTTURAtGMAJ9oetioh1rfTF1o+bqCWqWxG/LSiwCgghq9 pOBHdfUp625ll1lpTbW0X+w= =X0oP -----END PGP SIGNATURE----- From isaacdupree at charter.net Thu May 17 13:44:01 2007 From: isaacdupree at charter.net (Isaac Dupree) Date: Thu May 17 13:39:11 2007 Subject: Wanted: warning option for usages of unary minus In-Reply-To: <464C8564.3020006@gmail.com> References: <46181A52.8070108@charter.net> <4618E17D.4060706@charter.net> <461C96C1.40408@gmail.com> <20070508032640.GE13654@momenergy.repetae.net> <4648298B.9090300@gmail.com> <464C8564.3020006@gmail.com> Message-ID: <464C9461.6090805@charter.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Twan van Laarhoven wrote: > There is one other alternative for parsing: > "-" is a unary minus if and only if it is > a) preceded by whitespace or one of "[({;,", and > b) not followed by whitespace. > > So: > x - 1 == (-) x 1 > x-1 == (-) x 1 > x -1 == x (negate 1) > x -(1) == x (negate 1) > x (-1) == x (negate 1) > x (- 1) == x (\y -> y - 1) > > Just an idea. Indeed, and in some language syntax designs it would certainly be a good system for prefix operators. Existing parsers may have some difficulty. How about > {-comment-}-1 ? how about > WeirdNumber{value=2,weird=True}-1 ? Although likely to make any actual code work, it seems a bit complicated from the mindset of current Haskell parsing/lexing. "(b) not followed by whitespace." can be replaced by (b) followed by a digit if desired not to allow it for negating arbitrary expressions. Isaac -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGTJRgHgcxvIWYTTURAqpMAJ9rpCFwzOG/ZSF0qpM/hD/mFKrQ1wCfSRCK 2nKiBzRs/8thmgrdBT+SowA= =lFCl -----END PGP SIGNATURE----- From taralx at gmail.com Thu May 17 20:03:45 2007 From: taralx at gmail.com (Taral) Date: Thu May 17 20:00:12 2007 Subject: Wanted: warning option for usages of unary minus In-Reply-To: <1179417122.32514.19.camel@escoria.lanl.gov> References: <46181A52.8070108@charter.net> <4618E17D.4060706@charter.net> <461C96C1.40408@gmail.com> <20070508032640.GE13654@momenergy.repetae.net> <4648298B.9090300@gmail.com> <5ab17e790705141048y1ac7770g1ec56b856773ff39@mail.gmail.com> <464C3050.9060203@charter.net> <1179417122.32514.19.camel@escoria.lanl.gov> Message-ID: On 5/17/07, Joseph H. Fasel wrote: > *Sigh* The problems with unary minus were discussed in the dim mists of > time before we published the first Haskell report. We considered then > using a separate symbol for unary negation (as does APL, for example), > but (IIRC) this was regarded as unfriendly to Fortran programmers. [breaking cc list] Would this kind of thing be eligible for Haskell'? I never had a problem with _1 in APL-type languages... and I think it's best to be very clear about intent. -- Taral "Please let me know if there's any further trouble I can give you." -- Unknown From isaacdupree at charter.net Fri May 18 05:43:29 2007 From: isaacdupree at charter.net (Isaac Dupree) Date: Fri May 18 05:38:32 2007 Subject: Wanted: warning option for usages of unary minus In-Reply-To: References: <46181A52.8070108@charter.net> <4618E17D.4060706@charter.net> <461C96C1.40408@gmail.com> <20070508032640.GE13654@momenergy.repetae.net> <4648298B.9090300@gmail.com> <5ab17e790705141048y1ac7770g1ec56b856773ff39@mail.gmail.com> <464C3050.9060203@charter.net> <1179417122.32514.19.camel@escoria.lanl.gov> Message-ID: <464D7541.70607@charter.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Taral wrote: > On 5/17/07, Joseph H. Fasel wrote: >> *Sigh* The problems with unary minus were discussed in the dim mists of >> time before we published the first Haskell report. We considered then >> using a separate symbol for unary negation (as does APL, for example), >> but (IIRC) this was regarded as unfriendly to Fortran programmers. > > [breaking cc list] > > Would this kind of thing be eligible for Haskell'? I never had a > problem with _1 in APL-type languages... and I think it's best to be > very clear about intent. > Haskell' is "supposed to" be a conservative standard describing mostly-already-implemented features. (of course that is why to implement features like this efficiently if there is a good reason for them) underscore seems like a bad candidate in haskell because: _1 is presently a lowercase haskell identifier some people want mid-number underscores 1_048_576 ... Isaac -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGTXVBHgcxvIWYTTURAv+HAJ4mCqpXLLUEHaYeHrw8l6lx3eBr4QCgnTNl +g5Rllpuk/8s6p+1hTxi4Ew= =IvPt -----END PGP SIGNATURE----- From john at repetae.net Fri May 18 20:15:31 2007 From: john at repetae.net (John Meacham) Date: Fri May 18 20:12:00 2007 Subject: Wanted: warning option for usages of unary minus In-Reply-To: <4648298B.9090300@gmail.com> References: <46181A52.8070108@charter.net> <4618E17D.4060706@charter.net> <461C96C1.40408@gmail.com> <20070508032640.GE13654@momenergy.repetae.net> <4648298B.9090300@gmail.com> Message-ID: <20070519001531.GB32584@momenergy.repetae.net> On Mon, May 14, 2007 at 10:19:07AM +0100, Simon Marlow wrote: > Really? I'm beginning to have second thoughts about the proposed change to > negation for Haskell'. The main reason, and this isn't pointed out as well > as it should be on the wiki, is that "x-1" will cease to be an infix > application of (-), it will parse as x applied to the literal (-1). And > this is different from "x - 1" (syntax in which whitespace matters should > be avoided like the plague, IMO). I think this would be worse than the > current situation. White space already matters when it comes to numbers quite a bit 0 x 123 vs 0x123 1.5 vs 1 . 5 3e4 vs 3 e 4 etc. I think this change is more than worth it. I mean, having to write (-4) everywhere is bad enough, but when writing polymorphic code, (fromInteger (-4)) is horrific to embed everywhere. :) another option would be to only count it as a negative if there is a non-identifier character preceeding it. A little ugly. but still better than the current situation IMHO. John -- John Meacham - ?repetae.net?john? From john at repetae.net Fri May 18 20:24:14 2007 From: john at repetae.net (John Meacham) Date: Fri May 18 20:20:40 2007 Subject: Wanted: warning option for usages of unary minus In-Reply-To: <464C8564.3020006@gmail.com> References: <46181A52.8070108@charter.net> <4618E17D.4060706@charter.net> <461C96C1.40408@gmail.com> <20070508032640.GE13654@momenergy.repetae.net> <4648298B.9090300@gmail.com> <464C8564.3020006@gmail.com> Message-ID: <20070519002414.GC32584@momenergy.repetae.net> On Thu, May 17, 2007 at 06:40:04PM +0200, Twan van Laarhoven wrote: > Simon Marlow wrote: > >... > > > >Really? I'm beginning to have second thoughts about the proposed change > >to negation for Haskell'. The main reason, and this isn't pointed out > >as well as it should be on the wiki, is that "x-1" will cease to be an > >infix application of (-), it will parse as x applied to the literal > >(-1). And this is different from "x - 1" > > There is one other alternative for parsing: > "-" is a unary minus if and only if it is > a) preceded by whitespace or one of "[({;,", and > b) not followed by whitespace. > > So: > x - 1 == (-) x 1 > x-1 == (-) x 1 > x -1 == x (negate 1) > x -(1) == x (negate 1) > x (-1) == x (negate 1) > x (- 1) == x (\y -> y - 1) also (c) has a digit after it. also note that a big point of this is that we can get rid of 'negate' in the translation, so the literal -1 now desugars to (fromInteger -1) rather than the current (negate (fromInteger 1)) (which requires 2 dictionary lookups for a simple constant! sigh. we also have the option of removing negate from the 'Num' class if so desired. John -- John Meacham - ?repetae.net?john? From isaacdupree at charter.net Sat May 19 10:00:35 2007 From: isaacdupree at charter.net (Isaac Dupree) Date: Sat May 19 09:55:31 2007 Subject: Wanted: warning option for usages of unary minus In-Reply-To: <20070519001531.GB32584@momenergy.repetae.net> References: <46181A52.8070108@charter.net> <4618E17D.4060706@charter.net> <461C96C1.40408@gmail.com> <20070508032640.GE13654@momenergy.repetae.net> <4648298B.9090300@gmail.com> <20070519001531.GB32584@momenergy.repetae.net> Message-ID: <464F0303.2000502@charter.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 John Meacham wrote: > another option would be to only count it as a negative if there is a > non-identifier character preceeding it. A little ugly. but still better > than the current situation IMHO. I think Ghc's lexer "Alex" can do this although this functionality is not used anywhere else... it seems a little out of character. I don't really like that "(3-2)-1" would be parsed differently because it's a parenthesized expression; consider "3^2-1" vs. "(3^2)-1" ... Isaac -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGTwMCHgcxvIWYTTURAkzHAKCdekuA6rUw4QcnIV3Qq9WJ8ZkljQCfTH5G c0jDDrAGLtBVZ4WVRdTDJu8= =1BDf -----END PGP SIGNATURE----- From ahey at iee.org Sun May 20 10:24:23 2007 From: ahey at iee.org (Adrian Hey) Date: Sun May 20 10:20:50 2007 Subject: [Haskell-cafe] global variables In-Reply-To: <464E0DBE.5080908@charter.net> References: <464C5B8D.1070101@ukfsn.org> <464C750E.60701@iee.org> <464C7D67.8090309@jellybean.co.uk> <464C9DFF.3040209@iee.org> <464CD072.7000201@jellybean.co.uk> <464DAB75.7080206@iee.org> <464E0DBE.5080908@charter.net> Message-ID: <46505A17.7070903@iee.org> [cc'ing HPrime] Isaac Dupree wrote: > The unsafePerformIO hack being used is not very satisfactory given how > many optimizations make it difficult to use safely in practice. This > hack is also used many places. I would be happier if that situation > were not true, and I suspect there's something like a consensus on > _that_. (maybe not as strong as "_needs_ a solution" in the short-to-mid > term future) Considering the value that the Haskell community normally places on sound semantics, reliance on such an appalling hack seems pretty bad to me. If a solution doesn't find it's way into H' then how many more years is it going to be with us? It's just embarrassing :-) Also, I don't know if the OP was a noob, but telling people (especially noobs) that if they can't figure out how to solve a problem without using a "global variable" then that must be down to inexperience and general cluelessness on their part just seems wrong to me. It simply isn't true. (Anyone who disagrees with this should feel free to submit the patches needed to fix up the base package :-) Regards -- Adrian Hey From isaacdupree at charter.net Sun May 20 10:41:54 2007 From: isaacdupree at charter.net (Isaac Dupree) Date: Sun May 20 10:37:02 2007 Subject: [Haskell-cafe] global variables In-Reply-To: <46505A17.7070903@iee.org> References: <464C5B8D.1070101@ukfsn.org> <464C750E.60701@iee.org> <464C7D67.8090309@jellybean.co.uk> <464C9DFF.3040209@iee.org> <464CD072.7000201@jellybean.co.uk> <464DAB75.7080206@iee.org> <464E0DBE.5080908@charter.net> <46505A17.7070903@iee.org> Message-ID: <46505E32.1070806@charter.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Adrian Hey wrote: > [cc'ing HPrime] > > Isaac Dupree wrote: >> The unsafePerformIO hack being used is not very satisfactory given how >> many optimizations make it difficult to use safely in practice. This >> hack is also used many places. I would be happier if that situation >> were not true, and I suspect there's something like a consensus on >> _that_. (maybe not as strong as "_needs_ a solution" in the short-to-mid >> term future) > > Considering the value that the Haskell community normally places on > sound semantics, reliance on such an appalling hack seems pretty bad to > me. If a solution doesn't find it's way into H' then how many more years > is it going to be with us? It's just embarrassing :-) Yes, also it places value on REALLY EXTREMELY (excessively?) SOUND semantics, and on the modularity of the language even more than the modularity of its uses (or something like that :-) Maybe some sort of ISOLATE, DON'T_OPTIMIZE (but CAF), or USED_AS_GLOBAL_VARIABLE pragma instead of just the insufficient NOINLINE would be a good first step... if successful it would remove the occasional need for -fno-cse for a whole module in GHC, at least. Isaac -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGUF4yHgcxvIWYTTURAvqWAJ46eFRt5LK1lUwqr2BmHVSrHljxzwCfYGJB x5ivAFEw5vYKbxTPIg+PrIU= =0xVK -----END PGP SIGNATURE----- From ahey at iee.org Sun May 20 12:51:34 2007 From: ahey at iee.org (Adrian Hey) Date: Sun May 20 12:48:00 2007 Subject: [Haskell-cafe] global variables In-Reply-To: <46505E32.1070806@charter.net> References: <464C5B8D.1070101@ukfsn.org> <464C750E.60701@iee.org> <464C7D67.8090309@jellybean.co.uk> <464C9DFF.3040209@iee.org> <464CD072.7000201@jellybean.co.uk> <464DAB75.7080206@iee.org> <464E0DBE.5080908@charter.net> <46505A17.7070903@iee.org> <46505E32.1070806@charter.net> Message-ID: <46507C96.1070601@iee.org> Isaac Dupree wrote: > Maybe some sort of ISOLATE, DON'T_OPTIMIZE (but CAF), or > USED_AS_GLOBAL_VARIABLE pragma instead of just the insufficient NOINLINE > would be a good first step... if successful it would remove the > occasional need for -fno-cse for a whole module in GHC, at least. I have a hard time trying to understand why anyone would prefer this to the simple and clear <- syntax that's been proposed. As for the ACIO monad itself, this is utterly trivial and requires no language change. It's just a library. Maybe the first pragma you propose might have other uses to control optimisations, so I'm not totally anti this. But generally I dislike pragmas (I always find myself wondering what's wrong with the language design that makes the pragma necessary). So pragmas that influence optimisation are something I can live with. But using pragmas to influence *semantics* really is an evil practice IMO and is something that should be discouraged, not made an unavoidable necessity. But yes, if this problem isn't going to be properly addressed then at the very least the -fno-cse flag or something similar needs standardising (NOINLINE already is I think). Or we port all existing unsafePerfomIO hacked code to use Johm Meachams variant of the hack (uses types to ensure the compiler doesn't see common sub-expressions). Regards -- Adrian Hey From stedolan at gmail.com Sun May 20 14:21:11 2007 From: stedolan at gmail.com (Stephen Dolan) Date: Sun May 20 14:17:30 2007 Subject: Suggestion for module system (to get rid of many uses of unsafePerformIO) Message-ID: <1eff86fb0705201121l5e1385e0k4cde1300661756a0@mail.gmail.com> unsafePerformIO is possibly the most ugly feature of Haskell, yet is necessary to do many things which should be possible without it, such as reading configuration from a file at startup or creating global IORefs, e.g module Main where import Data.IORef a = unsafePerformIO $ newIORef 42 fac n = product [1..n] main = do val <- readIORef a putStrLn $ show (fac val) This can be avoided by putting everything in the monad in main, i.e. module Main where import Data.IORef main = do a <- unsafePerformIO $ newIORef 42 let fac n = product [1..n] let mainFunc = do val <- readIORef a putStrLn $ show (fac val) mainFunc However, this approach does not work for modules which need to do their own initialisation with the current module system. I propose that it be legal to write things like this: MyModule.hs: fac n = product [1..n] do ref <- newIORef 42 module MyModule (ref, fac) and then, in a different file, write this: module Main where main = do import qualified MyModule as M -- implies evaluating newIORef val <- readIORef M.ref putStrLn $ show (M.fac val) The statement "module [()]" would, informally, give a value of type Module. This would not be a first-class type, so it can't be passed around or bound to a variable. So, do ref <- newIORef 42 module MyModule (ref, fac) writeIORef ref 43 would be illegal, since if you expand the do-notation, it is trying to pass around an object of type "IO Module". So, in the previous example, Main :: Module and MyModule :: IO Module. The only valid operation you can perform on a module is to import it, so while import Main would be valid anywhere, import MyModule would only be valid in the IO monad, and would cause the line "ref <- newIORef 42" to be run when the IO action was executed. Following lexical scoping rules, its symbols would only be accessible in the do-block it was imported into, so the IORef "ref" could never "escape" from the IO monad. This would also mean that if main were run twice, each run would see a different IORef for "ref", since the call to newIORef has, in effect, been included into main. If the module were imported in two different places, both places would see different values for "ref", since the evaluation of newIORef has been done twice. Would this be useful, useless, or just downright silly? Thanks, Stephen Dolan From isaacdupree at charter.net Sun May 20 14:53:57 2007 From: isaacdupree at charter.net (Isaac Dupree) Date: Sun May 20 14:49:00 2007 Subject: [Haskell-cafe] global variables In-Reply-To: <46507C96.1070601@iee.org> References: <464C5B8D.1070101@ukfsn.org> <464C750E.60701@iee.org> <464C7D67.8090309@jellybean.co.uk> <464C9DFF.3040209@iee.org> <464CD072.7000201@jellybean.co.uk> <464DAB75.7080206@iee.org> <464E0DBE.5080908@charter.net> <46505A17.7070903@iee.org> <46505E32.1070806@charter.net> <46507C96.1070601@iee.org> Message-ID: <46509945.809@charter.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Adrian Hey wrote: > Isaac Dupree wrote: >> Maybe some sort of ISOLATE, DON'T_OPTIMIZE (but CAF), or >> USED_AS_GLOBAL_VARIABLE pragma instead of just the insufficient NOINLINE >> would be a good first step... if successful it would remove the >> occasional need for -fno-cse for a whole module in GHC, at least. > > I have a hard time trying to understand why anyone would prefer > this to the simple and clear <- syntax that's been proposed. As > for the ACIO monad itself, this is utterly trivial and requires > no language change. It's just a library. > > Maybe the first pragma you propose might have other uses to control > optimisations, so I'm not totally anti this. But generally I > dislike pragmas (I always find myself wondering what's wrong > with the language design that makes the pragma necessary). > > So pragmas that influence optimisation are something I can > live with. But using pragmas to influence *semantics* really > is an evil practice IMO and is something that should be > discouraged, not made an unavoidable necessity. Indeed. My rationale: - It would get some reliable semantics implemented in GHC (and/or other compilers hopefully). Since what we have already is a multi-part hack, this might be a nontrivial/important piece of work, and should make such things more reliable. - Pragmas (NOINLINE) are already used to influence semantics here. This idea doesn't introduce anything "worse" than that. And it doesn't require that people subscribe to particular syntax, ACIO implementation, etc. - Once implemented, if I understand correctly (do I?), it should make it easier for non-Simon to try out the hard work of a "real" solution involving non-pragma-syntax changes, ACIO libraries, or whatever is desired. Not because I think it's a great solution (nor even deserve to be called a real "solution" at all), but because nothing is being implemented now, for whatever reason. So I'm putting out this idea, in case it's a step in the right direction that someone is willing to take. Isaac -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGUJlEHgcxvIWYTTURAiGRAJ9ovzlD1Tc/Ce5tbCbYBBGcWLX/9ACfYzc3 a+xC3hQrXB3V9Iq+0vzxnmg= =EGk7 -----END PGP SIGNATURE----- From bulat.ziganshin at gmail.com Sun May 20 13:44:04 2007 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sun May 20 16:39:58 2007 Subject: [Haskell-cafe] global variables In-Reply-To: <46505E32.1070806@charter.net> References: <464C5B8D.1070101@ukfsn.org> <464C750E.60701@iee.org> <464C7D67.8090309@jellybean.co.uk> <464C9DFF.3040209@iee.org> <464CD072.7000201@jellybean.co.uk> <464DAB75.7080206@iee.org> <464E0DBE.5080908@charter.net> <46505A17.7070903@iee.org> <46505E32.1070806@charter.net> Message-ID: <1055992961.20070520214404@gmail.com> Hello Isaac, Sunday, May 20, 2007, 6:41:54 PM, you wrote: > Maybe some sort of ISOLATE, DON'T_OPTIMIZE (but CAF), or > USED_AS_GLOBAL_VARIABLE pragma instead of just the insufficient NOINLINE > would be a good first step... or LOOK_BUT_DON'T_TOUCH :) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From simonmarhaskell at gmail.com Mon May 21 05:33:56 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Mon May 21 05:30:42 2007 Subject: Wanted: warning option for usages of unary minus In-Reply-To: <20070519001531.GB32584@momenergy.repetae.net> References: <46181A52.8070108@charter.net> <4618E17D.4060706@charter.net> <461C96C1.40408@gmail.com> <20070508032640.GE13654@momenergy.repetae.net> <4648298B.9090300@gmail.com> <20070519001531.GB32584@momenergy.repetae.net> Message-ID: <46516784.1070500@gmail.com> John Meacham wrote: > On Mon, May 14, 2007 at 10:19:07AM +0100, Simon Marlow wrote: >> Really? I'm beginning to have second thoughts about the proposed change to >> negation for Haskell'. The main reason, and this isn't pointed out as well >> as it should be on the wiki, is that "x-1" will cease to be an infix >> application of (-), it will parse as x applied to the literal (-1). And >> this is different from "x - 1" (syntax in which whitespace matters should >> be avoided like the plague, IMO). I think this would be worse than the >> current situation. > > White space already matters when it comes to numbers quite a bit > > 0 x 123 vs 0x123 > 1.5 vs 1 . 5 > 3e4 vs 3 e 4 > > etc. Yes, I happen to think that whitespcae should only be significant where it separates two lexemes of the same category. I'm prepared to make an exception for numbers, because the syntax of numbers is already so familiar to almost everyone. I think that we could easily remove the '3e4' lexical syntax though, since '3*10^^4' works just as well (I often write the latter anyway) (and guess what, I just had to look up the difference between ^ and ^^, only to discover I picked the wrong one). The '3e4' syntax is a common source of compiler bugs, becuase it is rarely used and hence rarely tested. Cheers, Simon From john at repetae.net Mon May 21 21:21:31 2007 From: john at repetae.net (John Meacham) Date: Mon May 21 21:18:00 2007 Subject: Wanted: warning option for usages of unary minus In-Reply-To: <46516784.1070500@gmail.com> References: <46181A52.8070108@charter.net> <4618E17D.4060706@charter.net> <461C96C1.40408@gmail.com> <20070508032640.GE13654@momenergy.repetae.net> <4648298B.9090300@gmail.com> <20070519001531.GB32584@momenergy.repetae.net> <46516784.1070500@gmail.com> Message-ID: <20070522012131.GC24551@momenergy.repetae.net> On Mon, May 21, 2007 at 10:33:56AM +0100, Simon Marlow wrote: > I think that we could easily remove the '3e4' lexical syntax though, since > '3*10^^4' works just as well (I often write the latter anyway) (and guess > what, I just had to look up the difference between ^ and ^^, only to > discover I picked the wrong one). The '3e4' syntax is a common source of > compiler bugs, becuase it is rarely used and hence rarely tested. but they have substantially different translations. 3e2 -> fromRational (300 % 1) 3*10^^2 -> (fromInteger 3) * (fromInteger 10) ^^ (2 :: Foo) where Foo is whatever 4 defaults to, probably Integer, but could be a compile error if defaulting is off or changed. Though, the current floating point support in haskell is pretty funky as is... John -- John Meacham - ?repetae.net?john? From isaacdupree at charter.net Tue May 22 16:07:52 2007 From: isaacdupree at charter.net (Isaac Dupree) Date: Tue May 22 16:02:48 2007 Subject: [Haskell-cafe] global variables In-Reply-To: <46505E32.1070806@charter.net> References: <464C5B8D.1070101@ukfsn.org> <464C750E.60701@iee.org> <464C7D67.8090309@jellybean.co.uk> <464C9DFF.3040209@iee.org> <464CD072.7000201@jellybean.co.uk> <464DAB75.7080206@iee.org> <464E0DBE.5080908@charter.net> <46505A17.7070903@iee.org> <46505E32.1070806@charter.net> Message-ID: <46534D98.5040108@charter.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Isaac Dupree wrote: > Maybe some sort of ISOLATE, DON'T_OPTIMIZE (but CAF), or > USED_AS_GLOBAL_VARIABLE pragma instead of just the insufficient NOINLINE > would be a good first step... if successful it would remove the > occasional need for -fno-cse for a whole module in GHC, at least. ISOLATE, DON'T_OPTIMIZE are actually bad names for the whole effect, which requires persistent CAF semantics. An implementation that doesn't make top-level definitions be CAFs, or even one that is willing to garbage-collect them when memory is tight such that they need recalculation later, would need a special case for global variables to make them work. i.e. I'm not sure if there exists a reasonable pragma while the code still uses unsafePerformIO. Hmm.... How about so, {-# NOINLINE var #-} var :: IORef Int var = unsafePerformIO (newIORef 3) - --> var :: IORef Int var = {-# EVALUATE_THIS_TEXT_ONLY_ONCE #-} (unsafePerformIO (newIORef 3)) to capture the desired semantics: text-based uniqueness, no duplication, no sharing of the IORefs (sharing the pure contents is fine), and no need to actually evaluate it any times at all. {-# EVALUATE_THIS_TEXT_ONLY_ONCE #-} is syntactically like a (special) function. Clearly it is an impossible demand for polymorphic things, so the compiler could complain (at least a warning) if the (var :: IORef Int) line was left off, for example. I guess it would also complain about non-type(class) argument dependencies too such as (f x = (unsafePerformIO (newIORef (x::Int))) )... Food for thought :-) Isaac -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGU02YHgcxvIWYTTURAoCaAKCkDH7Pd7JbNt0TmNig9j7ujiUV9ACZAevI QOjdmMbrPfVrKBafZshCh7c= =9/5v -----END PGP SIGNATURE----- From ahey at iee.org Wed May 23 02:39:58 2007 From: ahey at iee.org (Adrian Hey) Date: Wed May 23 02:36:26 2007 Subject: [Haskell-cafe] global variables In-Reply-To: <46534D98.5040108@charter.net> References: <464C5B8D.1070101@ukfsn.org> <464C750E.60701@iee.org> <464C7D67.8090309@jellybean.co.uk> <464C9DFF.3040209@iee.org> <464CD072.7000201@jellybean.co.uk> <464DAB75.7080206@iee.org> <464E0DBE.5080908@charter.net> <46505A17.7070903@iee.org> <46505E32.1070806@charter.net> <46534D98.5040108@charter.net> Message-ID: <4653E1BE.4010306@iee.org> Isaac Dupree wrote: > var :: IORef Int > var = {-# EVALUATE_THIS_TEXT_ONLY_ONCE #-} (unsafePerformIO (newIORef 3)) I think I still prefer.. var :: IORef Int var <- newIORef 3 or, more likely.. var :: IORef Int var <- ACIO.newIORef 3 The <- syntax should make the intended semantics clear and unambiguous, so it becomes the problem of individual implementors (not standards writers) to make sure that whatever optimisations or transformations that may be appropriate for their implementation preserve those semantics. (IOW there's no need to worry about what a pragma really means in operational terms, AFAICS). The ACIO monad also restricts what programmers may use on the rhs of the <-. But if you want a good name for the pragma how about this.. > var :: IORef Int > var = {-# <- #-} (unsafePerformIO (newIORef 3)) :-) Regards -- Adrian Hey From ahey at iee.org Wed May 23 03:22:58 2007 From: ahey at iee.org (Adrian Hey) Date: Wed May 23 03:19:11 2007 Subject: Suggestion for module system (to get rid of many uses of unsafePerformIO) In-Reply-To: <1eff86fb0705201121l5e1385e0k4cde1300661756a0@mail.gmail.com> References: <1eff86fb0705201121l5e1385e0k4cde1300661756a0@mail.gmail.com> Message-ID: <4653EBD2.5030003@iee.org> Stephen Dolan wrote: > Would this be useful, useless, or just downright silly? The silence is deafening :-) I think what you're describing seems to be so completely different from Haskell as it is now that that people either don't understand it, or they do understand it and do think it's downright silly, but are just too polite to say that. Maybe you should try writing it up in a more comprehensible form on a Haskell wiki page. I would say that I get worried when people talk about "module initialisation" and/or (potentially) side effecting imports. I'm not sure if this is a problem with what you're proposing, but I think it's important that we don't get into a situation where the mere presence or absence of some definition in a module can influence program behaviour, even if it isn't referenced by main somehow. Regards -- Adrian Hey From stedolan at gmail.com Wed May 23 11:43:58 2007 From: stedolan at gmail.com (Stephen Dolan) Date: Wed May 23 11:40:12 2007 Subject: Suggestion for module system (to get rid of many uses of unsafePerformIO) In-Reply-To: <4653EBD2.5030003@iee.org> References: <1eff86fb0705201121l5e1385e0k4cde1300661756a0@mail.gmail.com> <4653EBD2.5030003@iee.org> Message-ID: <1eff86fb0705230843g24ff0fefr5edcbc4b31bd167e@mail.gmail.com> > I think what you're describing seems to be so completely different > from Haskell as it is now that that people either don't understand > it, or they do understand it and do think it's downright silly, but > are just too polite to say that. Maybe you should try writing it up > in a more comprehensible form on a Haskell wiki page. Yeah, that certainly wasn't my most readable piece of writing. > I would say that I get worried when people talk about "module > initialisation" and/or (potentially) side effecting imports. I'm > not sure if this is a problem with what you're proposing, but > I think it's important that we don't get into a situation where > the mere presence or absence of some definition in a module can > influence program behaviour, even if it isn't referenced by main > somehow. No, the point of what I was proposing was that, when a module requires side-effecting initialisation, it would have to be imported inside a do block like any other side-effecting piece of code. At the moment, we have the situation of modules using unsafePerformIO newIORef, which influences program behaviour without being referenced by main. If the import statement was inside a do block, it would be clear when the side-effects are taking place. Regards, Stephen Dolan From taralx at gmail.com Wed May 23 19:31:29 2007 From: taralx at gmail.com (Taral) Date: Wed May 23 19:27:48 2007 Subject: [Haskell-cafe] global variables In-Reply-To: <4653E1BE.4010306@iee.org> References: <464C5B8D.1070101@ukfsn.org> <464C7D67.8090309@jellybean.co.uk> <464C9DFF.3040209@iee.org> <464CD072.7000201@jellybean.co.uk> <464DAB75.7080206@iee.org> <464E0DBE.5080908@charter.net> <46505A17.7070903@iee.org> <46505E32.1070806@charter.net> <46534D98.5040108@charter.net> <4653E1BE.4010306@iee.org> Message-ID: On 5/23/07, Adrian Hey wrote: > I think I still prefer.. > > var :: IORef Int > var <- newIORef 3 So do I. For one very good reason: this syntax could be defined as a "constructor" syntax and guaranteed to run before main. The other syntaxes proposed don't strike me as sufficiently rigorous. -- Taral "Please let me know if there's any further trouble I can give you." -- Unknown From ahey at iee.org Thu May 24 02:00:32 2007 From: ahey at iee.org (Adrian Hey) Date: Thu May 24 01:56:44 2007 Subject: Suggestion for module system (to get rid of many uses of unsafePerformIO) In-Reply-To: <1eff86fb0705230843g24ff0fefr5edcbc4b31bd167e@mail.gmail.com> References: <1eff86fb0705201121l5e1385e0k4cde1300661756a0@mail.gmail.com> <4653EBD2.5030003@iee.org> <1eff86fb0705230843g24ff0fefr5edcbc4b31bd167e@mail.gmail.com> Message-ID: <46552A00.5090400@iee.org> Stephen Dolan wrote: > At the moment, > we have the situation of modules using unsafePerformIO newIORef, which > influences program behaviour without being referenced by main. Not really. Even with things as they currently are, if we have at the top level.. resultOfSomething = unsafePerformIO doSomething .. laziness will ensure that nothing will happen unless the value resultOfSomething is demanded (by main ultimately). Of course, this does not imply the above hack is at all safe. Regards -- Adrian Hey From ahey at iee.org Thu May 24 03:15:54 2007 From: ahey at iee.org (Adrian Hey) Date: Thu May 24 03:12:15 2007 Subject: [Haskell-cafe] global variables In-Reply-To: References: <464C5B8D.1070101@ukfsn.org> <464C7D67.8090309@jellybean.co.uk> <464C9DFF.3040209@iee.org> <464CD072.7000201@jellybean.co.uk> <464DAB75.7080206@iee.org> <464E0DBE.5080908@charter.net> <46505A17.7070903@iee.org> <46505E32.1070806@charter.net> <46534D98.5040108@charter.net> <4653E1BE.4010306@iee.org> Message-ID: <46553BAA.1000705@iee.org> Taral wrote: > On 5/23/07, Adrian Hey wrote: >> I think I still prefer.. >> >> var :: IORef Int >> var <- newIORef 3 > > So do I. For one very good reason: this syntax could be defined as a > "constructor" syntax and guaranteed to run before main. Or even at compile time (which is why I think it's reasonable to regard operations like newIORef etc.. as not really being "IO" operations at all). But anyway, the constraints of the ACIO monad allow creation to occur at any time before the first attempt to read or write the IORef. > The other syntaxes proposed don't strike me as sufficiently rigorous. Me neither. It's always been a great source of puzzlement to me why this very simple and IMO conservative proposal should be so controversial. Unless someone can point out some severe semantic difficulty or suggest something better it seems like a no-brainer to me. Regards -- Adrian Hey From oleg at pobox.com Thu May 24 03:39:07 2007 From: oleg at pobox.com (oleg@pobox.com) Date: Thu May 24 03:37:08 2007 Subject: Suggestion for module system (to get rid of many uses of unsafePerformIO) Message-ID: <20070524073907.1F848AD43@Adric.metnet.fnmoc.navy.mil> Stephen Dolan wrote: > unsafePerformIO is possibly the most ugly feature of Haskell, yet is > necessary to do many things which should be possible without it, such > as reading configuration from a file at startup or creating global > IORefs There is a considerable debate about global mutable state even in imperative languages. As to reading data from a configuration file -- which should be immutable for the rest of the computation -- one solution has been proposed back in 2002: Pure File Reading (was: Dealing with configuration data) http://www.haskell.org/pipermail/haskell/2002-September/010519.html The problem essentially is of separate compilation and dynamic linking -- both of which are far simpler now than it was in 2002, with GHC API and hs-plugins. From taralx at gmail.com Thu May 24 10:50:50 2007 From: taralx at gmail.com (Taral) Date: Thu May 24 10:46:56 2007 Subject: [Haskell-cafe] global variables In-Reply-To: <46553BAA.1000705@iee.org> References: <464C5B8D.1070101@ukfsn.org> <464CD072.7000201@jellybean.co.uk> <464DAB75.7080206@iee.org> <464E0DBE.5080908@charter.net> <46505A17.7070903@iee.org> <46505E32.1070806@charter.net> <46534D98.5040108@charter.net> <4653E1BE.4010306@iee.org> <46553BAA.1000705@iee.org> Message-ID: On 5/24/07, Adrian Hey wrote: > Taral wrote: > > The other syntaxes proposed don't strike me as sufficiently rigorous. > > Me neither. It's always been a great source of puzzlement to me why this > very simple and IMO conservative proposal should be so controversial. > Unless someone can point out some severe semantic difficulty or suggest > something better it seems like a no-brainer to me. I think it lacks implementation. I don't have time, or I'd look into hacking this into GHC. -- Taral "Please let me know if there's any further trouble I can give you." -- Unknown From simonmarhaskell at gmail.com Thu May 24 11:30:34 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Thu May 24 11:26:44 2007 Subject: [Haskell-cafe] global variables In-Reply-To: <46553BAA.1000705@iee.org> References: <464C5B8D.1070101@ukfsn.org> <464C7D67.8090309@jellybean.co.uk> <464C9DFF.3040209@iee.org> <464CD072.7000201@jellybean.co.uk> <464DAB75.7080206@iee.org> <464E0DBE.5080908@charter.net> <46505A17.7070903@iee.org> <46505E32.1070806@charter.net> <46534D98.5040108@charter.net> <4653E1BE.4010306@iee.org> <46553BAA.1000705@iee.org> Message-ID: <4655AF9A.9050906@gmail.com> Adrian Hey wrote: > Taral wrote: >> On 5/23/07, Adrian Hey wrote: >>> I think I still prefer.. >>> >>> var :: IORef Int >>> var <- newIORef 3 >> >> So do I. For one very good reason: this syntax could be defined as a >> "constructor" syntax and guaranteed to run before main. > > Or even at compile time (which is why I think it's reasonable to > regard operations like newIORef etc.. as not really being "IO" > operations at all). But anyway, the constraints of the ACIO monad > allow creation to occur at any time before the first attempt to > read or write the IORef. > >> The other syntaxes proposed don't strike me as sufficiently rigorous. > > Me neither. It's always been a great source of puzzlement to me why this > very simple and IMO conservative proposal should be so controversial. > Unless someone can point out some severe semantic difficulty or suggest > something better it seems like a no-brainer to me. This is going to be highly subjective, but to me it still doesn't feel like it falls under the bar for implementation cost given its usefulness. The new syntax requires additions all the way through the front end of the compiler: parser, abstract syntax, renamer, type checker, desugarer, for something that is rarely used. It's a first-class language construct (a new top-level binding form, no less), and it has to pay its way. Also you want to add the ACIO monad as a built-in to the language. Not that my gut feeling should in any way be considered the final word on the subject, but I thought I should say something about why we're not running to implement this right now. To me it seems like we should let it simmer some more. Cheers, Simon From dmhouse at gmail.com Thu May 24 14:51:14 2007 From: dmhouse at gmail.com (David House) Date: Thu May 24 14:47:27 2007 Subject: [Haskell-cafe] global variables In-Reply-To: <46553BAA.1000705@iee.org> References: <464C5B8D.1070101@ukfsn.org> <464CD072.7000201@jellybean.co.uk> <464DAB75.7080206@iee.org> <464E0DBE.5080908@charter.net> <46505A17.7070903@iee.org> <46505E32.1070806@charter.net> <46534D98.5040108@charter.net> <4653E1BE.4010306@iee.org> <46553BAA.1000705@iee.org> Message-ID: On 24/05/07, Adrian Hey wrote: > Or even at compile time (which is why I think it's reasonable to > regard operations like newIORef etc.. as not really being "IO" > operations at all). You can allocate heap space at compile time? (Well, I guess you could, but that wouldn't still be usable at run time...) I imagine newIORef as mallocing() some room, then returning a pointer to that memory. That doesn't seem like something that could be done at compile time. -- -David House, dmhouse@gmail.com From wnoise at ofb.net Thu May 24 16:04:18 2007 From: wnoise at ofb.net (Aaron Denney) Date: Thu May 24 16:00:40 2007 Subject: [Haskell-cafe] global variables References: <464C5B8D.1070101@ukfsn.org> <464CD072.7000201@jellybean.co.uk> <464DAB75.7080206@iee.org> <464E0DBE.5080908@charter.net> <46505A17.7070903@iee.org> <46505E32.1070806@charter.net> <46534D98.5040108@charter.net> <4653E1BE.4010306@iee.org> <46553BAA.1000705@iee.org> Message-ID: On 2007-05-24, David House wrote: > On 24/05/07, Adrian Hey wrote: >> Or even at compile time (which is why I think it's reasonable to >> regard operations like newIORef etc.. as not really being "IO" >> operations at all). > > You can allocate heap space at compile time? (Well, I guess you could, > but that wouldn't still be usable at run time...) I imagine newIORef > as mallocing() some room, then returning a pointer to that memory. > That doesn't seem like something that could be done at compile time. You can allocate bss or data space at compile time for the executable you are compiling. (Well, if you read compile as compile and link. It's a bit fuzzy.) -- Aaron Denney -><- From ahey at iee.org Thu May 24 15:58:51 2007 From: ahey at iee.org (Adrian Hey) Date: Thu May 24 16:01:04 2007 Subject: [Haskell-cafe] global variables In-Reply-To: References: <464C5B8D.1070101@ukfsn.org> <464CD072.7000201@jellybean.co.uk> <464DAB75.7080206@iee.org> <464E0DBE.5080908@charter.net> <46505A17.7070903@iee.org> <46505E32.1070806@charter.net> <46534D98.5040108@charter.net> <4653E1BE.4010306@iee.org> <46553BAA.1000705@iee.org> Message-ID: <4655EE7B.7080909@iee.org> David House wrote: > On 24/05/07, Adrian Hey wrote: >> Or even at compile time (which is why I think it's reasonable to >> regard operations like newIORef etc.. as not really being "IO" >> operations at all). > > You can allocate heap space at compile time? (Well, I guess you could, > but that wouldn't still be usable at run time...) I imagine newIORef > as mallocing() some room, then returning a pointer to that memory. > That doesn't seem like something that could be done at compile time. There seems to be quite a few implicit (and incorrect) assumptions in your argument, which is fallacious IMO. The logic of your argument would imply that *no* top level expression can be evaluated at compile time. This might be the case with ghc, though I doubt it (and even if it was this would just be a ghc problem). BTW, the Haskell standard says nothing about any kind of heap, let alone a C style malloc. Regards -- Adrian Hey From ahey at iee.org Thu May 24 17:21:50 2007 From: ahey at iee.org (Adrian Hey) Date: Thu May 24 17:18:11 2007 Subject: [Haskell-cafe] global variables In-Reply-To: References: <464C5B8D.1070101@ukfsn.org> <464CD072.7000201@jellybean.co.uk> <464DAB75.7080206@iee.org> <464E0DBE.5080908@charter.net> <46505A17.7070903@iee.org> <46505E32.1070806@charter.net> <46534D98.5040108@charter.net> <4653E1BE.4010306@iee.org> <46553BAA.1000705@iee.org> Message-ID: <465601EE.8010506@iee.org> Aaron Denney wrote: > On 2007-05-24, David House wrote: >> On 24/05/07, Adrian Hey wrote: >>> Or even at compile time (which is why I think it's reasonable to >>> regard operations like newIORef etc.. as not really being "IO" >>> operations at all). >> You can allocate heap space at compile time? (Well, I guess you could, >> but that wouldn't still be usable at run time...) I imagine newIORef >> as mallocing() some room, then returning a pointer to that memory. >> That doesn't seem like something that could be done at compile time. > > You can allocate bss or data space at compile time for the executable > you are compiling. (Well, if you read compile as compile and link. > It's a bit fuzzy.) Well we don't need to get too bogged down with the details of how any particular compiler/linker/rts might work. The point being that with any.. myIORef <- newIORef initialExpression whether or not it's at the top level, the only information needed to create the IORef is the initialExpression, and if it's at the top level then this is available at compile time (it doesn't even have to be evaluated at compile time in order to create the IORef). But it doesn't require any information from, nor should it have any effect on, the outside world that an executing program is interacting with. It is conceivable that for some newIORef implementations this would not be true, but in that case it's difficult to see how such implementations could safely put their newIORef in the ACIO monad anyway. Regards -- Adrian Hey From isaacdupree at charter.net Tue May 29 12:21:28 2007 From: isaacdupree at charter.net (Isaac Dupree) Date: Tue May 29 12:15:54 2007 Subject: Literate Haskell specification In-Reply-To: <46169A70.80909@charter.net> References: <46169A70.80909@charter.net> Message-ID: <465C5308.5030508@charter.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Isaac Dupree wrote: > As I brought up earlier in Haskell-cafe > http://thread.gmane.org/gmane.comp.lang.haskell.cafe/20026 > , the Haskell98 specification for literate haskell (report section 9.4) > could use some work, at least clarifications (existing haskell > implementations differ in some ways) - see that thread for details. > Since I haven't successfully gotten to writing a concrete revision of > that section, I thought I'd at least bring the issue to the attention of > specifically haskell-prime people, as it is an issue that "should > definitely" be addressed in the Report. Hopefully there's someone > around here who might tackle it :) Like myself :) See http://isaac.cedarswampstudios.org/2007/LiterateHaskellPrime/literate.html for my draft (look in http://isaac.cedarswampstudios.org/2007/LiterateHaskellPrime/ for source files). It needs feedback. We could make the "not advisable" things be "if you allow them, they are this way; but you don't need to allow them". I have provided alternate wordings for both possibilities in both places that my draft says something is "not advisable". (is talking about "implementations" the right way to go about wording it?) Technical help needed: There seems to be duplicate sections of the report for this "literate", even in the source-files?? literate.verb and in syntax-iso.verb. In fact in the Haskell 98 revised online report Full Table of Contents, it is duplicated, in sections 9.4 and 9.6. What am I doing wrong that makes the layout of my BNF a little funny, some spaces missing, some lines wrapped where they shouldn't be? What is this \Haskell{} rather than just Haskell? Assuming I should use it... it inserts a space before my commas and periods, ("... Haskell , ...") which is bad. Does the % % $Header: /home/cvs/root/haskell-report/report/literate.verb,v 1.5 2002/12/02 14:53:30 simonpj Exp $ % at the beginning of the files still make sense? Should it be deleted? Other observation: The LaTeX-style example doesn't seem very good - e.g., beginning with \documentstyle, and the lhs2TeX processor, don't go well together. (apparently beginning with \documentclass instead is necessary to make the \usepackage{..}s it generates work, and such a heading may not be necessary at all for that...) Isaac -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGXFMIHgcxvIWYTTURApslAJ4qXnKixhz6aClK/SrJfr/x9odA6wCfYqEm d6vUpTPpLHSm1ObSQqsxI4A= =9Za5 -----END PGP SIGNATURE-----