From apfelmus at quantentunnel.de Wed Jun 13 05:48:18 2007 From: apfelmus at quantentunnel.de (apfelmus) Date: Wed Jun 13 05:51:14 2007 Subject: inits is too strict Message-ID: Hello, inits [] = [[]] inits (x:xs) = [[]] ++ map (x:) (inits xs) as specified in Data.List has a "semantic bug", namely it's too strict: inits (1:_|_) = []:_|_ as opposed to the expected inits (1:_|_) = []:[1]:_|_ A correct version would be inits xs = []:case xs of [] -> [] (x:xs) -> map (x:) (inits xs) The Haskell report specifies how inits has to behave, so this is a problem in the report, not in a concrete implementation. Where can I report a bug report for the report? ;) Regards, apfelmus From dons at cse.unsw.edu.au Wed Jun 13 05:59:58 2007 From: dons at cse.unsw.edu.au (Donald Bruce Stewart) Date: Wed Jun 13 05:55:04 2007 Subject: inits is too strict In-Reply-To: References: Message-ID: <20070613095958.GA22737@cse.unsw.EDU.AU> apfelmus: > Hello, > > inits [] = [[]] > inits (x:xs) = [[]] ++ map (x:) (inits xs) > > as specified in Data.List has a "semantic bug", namely it's too strict: > > inits (1:_|_) = []:_|_ > > as opposed to the expected > > inits (1:_|_) = []:[1]:_|_ > > A correct version would be > > inits xs = []:case xs of > [] -> [] > (x:xs) -> map (x:) (inits xs) > > The Haskell report specifies how inits has to behave, so this is a > problem in the report, not in a concrete implementation. Where can I > report a bug report for the report? ;) > > Regards, > apfelmus Well, right here. There are other strictness issues either differing from the spec, or not clearly defined (foldl', for example). A useful tool for checking these is the StrictCheck/ChasingBottoms library, QuickCheck for partial values, by the way. -- Don From stefanor at cox.net Wed Jun 13 09:54:03 2007 From: stefanor at cox.net (Stefan O'Rear) Date: Wed Jun 13 09:49:02 2007 Subject: inits is too strict In-Reply-To: References: Message-ID: <20070613135403.GA2906@localhost.localdomain> On Wed, Jun 13, 2007 at 11:48:18AM +0200, apfelmus wrote: > Hello, > > inits [] = [[]] > inits (x:xs) = [[]] ++ map (x:) (inits xs) > > as specified in Data.List has a "semantic bug", namely it's too strict: > > inits (1:_|_) = []:_|_ > > as opposed to the expected > > inits (1:_|_) = []:[1]:_|_ > > A correct version would be > > inits xs = []:case xs of > [] -> [] > (x:xs) -> map (x:) (inits xs) > > The Haskell report specifies how inits has to behave, so this is a > problem in the report, not in a concrete implementation. Where can I > report a bug report for the report? ;) http://haskell.org/haskellwiki/Language_and_library_specification says: The report still has minor bugs. There are tracked at the Haskell 98 bugs page. Report any new bugs to Malcolm Wallace. Stefan From isaacdupree at charter.net Thu Jun 14 09:11:12 2007 From: isaacdupree at charter.net (Isaac Dupree) Date: Thu Jun 14 09:04:33 2007 Subject: What separates lines in Haskell code? Message-ID: <46713E70.7020809@charter.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In the report, under the layout rule (section 9.3), "The characters newline, return, linefeed, and formfeed, all start a new line." (Which four characters are those? from http://en.wikipedia.org/wiki/Linefeed , I'm guessing "LF: Line Feed, U+000A", "CR: Carriage Return, U+000D", "FF: Form Feed, U+000C", and what's the fourth one? Newline usually refers to '\n', which is LF, but linefeed has a direct name correspondence to that also!) The literate haskell section 9.4 just talks about lines without being specific about how they're specified. My proposed sample implementation uses Prelude.lines ... Prelude.lines presumes that lines are separated only by '\n'. (Of course, for Prelude.unlines to be an inverse operation (which it's not anyway) there has to be only one character that makes a line-separation) Isaac -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGcT5vHgcxvIWYTTURAowrAJ4rz3/Sc763l8TEharcnWcma5BkBgCfRhAF XbfCIG8tnym1gZFRZf4KuRo= =it7M -----END PGP SIGNATURE----- From antti-juhani at kaijanaho.fi Thu Jun 14 09:21:11 2007 From: antti-juhani at kaijanaho.fi (Antti-Juhani Kaijanaho) Date: Thu Jun 14 09:16:22 2007 Subject: What separates lines in Haskell code? In-Reply-To: <46713E70.7020809@charter.net> References: <46713E70.7020809@charter.net> Message-ID: <20070614132109.GA15114@kukkaseppele.kaijanaho.fi> On Thu, Jun 14, 2007 at 09:11:12AM -0400, Isaac Dupree wrote: > In the report, under the layout rule (section 9.3), "The characters > newline, return, linefeed, and formfeed, all start a new line." (Which > four characters are those? from http://en.wikipedia.org/wiki/Linefeed , > I'm guessing "LF: Line Feed, U+000A", "CR: Carriage Return, U+000D", > "FF: Form Feed, U+000C", and what's the fourth one? Newline usually > refers to '\n', which is LF, but linefeed has a direct name > correspondence to that also!) The H98 lexical syntax defines newline as newline -> return linefeed | return | linefeed | formfeed It could, I suppose, also refer to the Unicode character U+2028 LINE SEPARATOR, but then probably U+2029 PARAGRAPH SEPARATOR ought to be included as well. There are, BTW, Unicode guidelines for newline usage in section 5.8 of the Unicode 5.0 online edition. -- Antti-Juhani Kaijanaho, Jyv?skyl? http://antti-juhani.kaijanaho.fi/newblog/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/haskell-prime/attachments/20070614/b75d44c2/attachment.bin From apfelmus at quantentunnel.de Thu Jun 14 14:04:40 2007 From: apfelmus at quantentunnel.de (apfelmus) Date: Thu Jun 14 14:05:24 2007 Subject: inits is too strict In-Reply-To: <20070613095958.GA22737@cse.unsw.EDU.AU> References: <20070613095958.GA22737@cse.unsw.EDU.AU> Message-ID: > apfelmus: >> Where can I report a bug report for the report? ;) Stefan O'Rear wrote: > http://haskell.org/haskellwiki/Language_and_library_specification > says: > > The report still has minor bugs. There are tracked at the Haskell 98 > bugs page. Report any new bugs to Malcolm Wallace. Donald Bruce Stewart wrote: > Well, right here. There are other strictness issues either differing > from the spec, or not clearly defined (foldl', for example). Ah. Actually, I thought that there's something like a bug-tracker for the standardized libraries. I wouldn't change inits in the existing H98 standard, it's not really worth the hassle. But I'd change it to the lazy version for Haskell'. > A useful tool for checking these is the StrictCheck/ChasingBottoms > library, QuickCheck for partial values, by the way. Oh, really useful :) Regards, apfelmus From isaacdupree at charter.net Sat Jun 16 14:28:03 2007 From: isaacdupree at charter.net (Isaac Dupree) Date: Sat Jun 16 14:21:20 2007 Subject: "qvars"? pragma syntax generally? Message-ID: <46742BB3.5090102@charter.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 For INLINE and NOINLINE the report uses "qvars" http://haskell.org/onlinereport/pragmas.html which is not defined in http://haskell.org/onlinereport/syntax-iso.html (although its meaning is obvious since var, qvar and vars are all defined). Is it permissible for compilers to die on pragma syntax they don't personally like? For example GHC chokes on {-# INLINE Ma-in.ma-in #-} at top level, but it would be worse with non-standardized pragmas. (the compiler giving a warning that it understands a pragma of that name, but not the syntax given, would be best.) "the pragma should be ignored if an implementation is not prepared to handle it." WHAT IS pragma syntax?? The report doesn't say how whitespace is handled. syntax-iso doesn't mention pragmas; in its opinion everything from {-# hi-} to {-#{-##-}#-} to {-# INLINE main #-} is a perfectly good comment. [1] But the report recommends some specific syntaxes. To all appearances, it is expected that they follow (guessing from other Haskell syntax) the form pragma -> {-# pragmaid (some pragma-specific syntax that is consistent with the whole thing being ncomment) #-} pragmaid -> (large|_) {large|_|'} Still... whitespace? GHC understands as a pragma {-# LINE 3 "foo.hs" #-} but not {-# {- nested comment -} LINE 3 "foo.hs" #-} ; I don't even know about inside or next to the (some pragma-specific syntax). Is the inside of pragmas supposed to be lexed somewhat the same way as the rest of the Haskell file, or "it can vary" because pragmas can be anything they want... hopefully the convention of beginning pragmas with a name cannot vary. [1] (hmm, maybe pragmas should be used to indicate haddock comments - too late now, and probably too verbose too) Isaac -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGdCuyHgcxvIWYTTURAnljAJ9NLJKW+CTroJ0Vg43bgGWZ3DXJHwCgp+Z3 SAX/cK5PSV7B4TBfwg664xM= =81g6 -----END PGP SIGNATURE----- From isaacdupree at charter.net Sun Jun 17 13:36:19 2007 From: isaacdupree at charter.net (Isaac Dupree) Date: Sun Jun 17 13:29:34 2007 Subject: What separates lines in Haskell code? In-Reply-To: <20070614132109.GA15114@kukkaseppele.kaijanaho.fi> References: <46713E70.7020809@charter.net> <20070614132109.GA15114@kukkaseppele.kaijanaho.fi> Message-ID: <46757113.9020305@charter.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Antti-Juhani Kaijanaho wrote: > On Thu, Jun 14, 2007 at 09:11:12AM -0400, Isaac Dupree wrote: >> In the report, under the layout rule (section 9.3), "The characters >> newline, return, linefeed, and formfeed, all start a new line." (Which >> four characters are those? from http://en.wikipedia.org/wiki/Linefeed , >> I'm guessing "LF: Line Feed, U+000A", "CR: Carriage Return, U+000D", >> "FF: Form Feed, U+000C", and what's the fourth one? Newline usually >> refers to '\n', which is LF, but linefeed has a direct name >> correspondence to that also!) > > The H98 lexical syntax defines newline as > newline -> return linefeed | return | linefeed | formfeed > > It could, I suppose, also refer to the Unicode character U+2028 LINE SEPARATOR, > but then probably U+2029 PARAGRAPH SEPARATOR ought to be included as well. > > There are, BTW, Unicode guidelines for newline usage in section 5.8 of the > Unicode 5.0 online edition. http://www.unicode.org/versions/Unicode5.0.0/ch05.pdf#G10213 Alright, I think the comment in the layout-rule section should not try to enumerate newlines, but rather should refer back to the lexical definition of 'newline'. As per the above Unicode guideline, the existing set of characters that Haskell98 accepts as newlines, and a section of the Unicode regex guidelines , I propose all should be accepted as line separators: \u000A | \u000B | \u000C | \u000D | \u0085 | \u2028 | \u2029 | \u000D\u000A i.e. (not in the same order) CR, LF, CRLF, NEL, VT, FF, LS, PS. Unfortunately that makes it a little hard to process; maybe translate all into '\n' before doing any processing (such as unliteration). Isaac -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGdXETHgcxvIWYTTURApE8AJsEdw8zUrri+EzXfa+EhlyC1UT2TACdHjgp RjtYbkXTMFadsavlzhCHDJ0= =Nbl0 -----END PGP SIGNATURE----- From isaacdupree at charter.net Mon Jun 18 07:17:51 2007 From: isaacdupree at charter.net (Isaac Dupree) Date: Mon Jun 18 07:10:59 2007 Subject: type signatures in export lists Message-ID: <467669DF.8050806@charter.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 They're not implemented, but they won't be until we decide exactly what they mean - it's not simple. (at least the syntax is obvious: http://hackage.haskell.org/trac/haskell-prime/wiki/PermitSignaturesInExports ) One big question: can their presence have any effect? * on the module doing the exporting (conflict with the presence of in-module type-signature for the same thing; type restriction in-module; monomorphism-restriction-lifting or defaulting-removal of the named thing) * on modules importing this one (can a module re-export something, giving it a more restrictive type-signature?) Case study 1: module Foo1 (Foo(..), foo :: Foo) where data Foo = CFoo foo :: Foo foo = CFoo If we interpret it as an in-module type signature, it will be a problem because there already is one for foo. (unless we should relax the rules for uniqueness of type signatures anyway?) Case study 2: module Foo2 (foo :: Foo) where data Foo = CFoo foo :: Foo foo = CFoo The type doesn't need to be exported. (which is more likely if it's just a type synonym than a new type.) So what scope are the names in the export-list-type-signature drawn from? It would be odd if a type signature couldn't be given because some names weren't exported; but it would be odd if a module-user looking at the interface saw some types that weren't defined anywhere visible. This suggests that wildcards in type signatures could be helpful for this: module Foo3 (foo :: Int -> Foo -> Bool) versus module Foo4 (foo :: Int -> _ -> Bool) Open for discussion. Isaac -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGdmneHgcxvIWYTTURAlTpAJ425ZL8WPzkAeIxRbgGSOQFCKtrnwCeIG0P aawB6GDwSfiRNM20MErBj8E= =KCKj -----END PGP SIGNATURE----- From ariep at xs4all.nl Mon Jun 18 10:00:46 2007 From: ariep at xs4all.nl (Arie Peterson) Date: Mon Jun 18 09:55:30 2007 Subject: type signatures in export lists In-Reply-To: <467669DF.8050806@charter.net> References: <467669DF.8050806@charter.net> Message-ID: <4360.213.84.177.94.1182175246.squirrel@webmail.xs4all.nl> Isaac Dupree wrote: > One big question: can their presence have any effect? > * on the module doing the exporting (conflict with the presence of > in-module type-signature for the same thing; type restriction in-module; > monomorphism-restriction-lifting or defaulting-removal of the named thing) > * on modules importing this one (can a module re-export something, > giving it a more restrictive type-signature?) Letting an export-list type signature be equivalent to a normal one has the benefit of being simple (to explain and implement). Exporting a function with a less polymorphic type than its in-module type seems a bit awkward: you would have two different functions (one internal and one exported) with the same name. If export-list and normal type signatures would be equivalent, the only benefit of allowing the former (compared to writing it in a comment) would be that the compiler can check it for consistency. Right? > The type doesn't need to be exported. (which is more likely if it's just > a type synonym than a new type.) So what scope are the names in the > export-list-type-signature drawn from? It would be odd if a type > signature couldn't be given because some names weren't exported; but it > would be odd if a module-user looking at the interface saw some types > that weren't defined anywhere visible. As a user of the module, I would argue that all types (including synonyms) appearing in the signature of an exported function should be exported as well. Not sure if this needs to be enforced, though. Regards, Arie From isaacdupree at charter.net Mon Jun 18 13:20:29 2007 From: isaacdupree at charter.net (Isaac Dupree) Date: Mon Jun 18 13:13:36 2007 Subject: default fixity for `quotRem`, `divMod` ?? Message-ID: <4676BEDD.4010900@charter.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I was just bitten in ghci by `divMod` being the default infixl 9 instead of the same as `div` and `mod`. Sure enough, the standard prelude doesn't specify a fixity for `quotRem` and `divMod` even though `quot`, `rem`, `div`, and `mod` are all infixl 7. I propose that `quotRem` and `divMod` also become infixl 7. Isaac -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGdr7dHgcxvIWYTTURAu07AKCb0RAI343lnRlH1FgI1rMy0dx1FQCfcnsV g6HUB5vDVbk9LPGi51WpY+o= =iESL -----END PGP SIGNATURE----- From iavor.diatchki at gmail.com Mon Jun 18 13:35:57 2007 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Mon Jun 18 13:30:40 2007 Subject: default fixity for `quotRem`, `divMod` ?? In-Reply-To: <4676BEDD.4010900@charter.net> References: <4676BEDD.4010900@charter.net> Message-ID: <5ab17e790706181035r7433429bhc72830dc9f32cbf6@mail.gmail.com> Hi, This seems like a good idea. We should make sure that we are writing down such bugfixes somewhere besides the mailing list so that they do not get lost. -Iavor On 6/18/07, Isaac Dupree wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I was just bitten in ghci by `divMod` being the default infixl 9 instead > of the same as `div` and `mod`. Sure enough, the standard prelude > doesn't specify a fixity for `quotRem` and `divMod` even though `quot`, > `rem`, `div`, and `mod` are all infixl 7. I propose that `quotRem` and > `divMod` also become infixl 7. > > Isaac > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFGdr7dHgcxvIWYTTURAu07AKCb0RAI343lnRlH1FgI1rMy0dx1FQCfcnsV > g6HUB5vDVbk9LPGi51WpY+o= > =iESL > -----END PGP SIGNATURE----- > _______________________________________________ > Haskell-prime mailing list > Haskell-prime@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-prime > From isaacdupree at charter.net Mon Jun 18 14:02:36 2007 From: isaacdupree at charter.net (Isaac Dupree) Date: Mon Jun 18 13:55:47 2007 Subject: type signatures in export lists In-Reply-To: <4360.213.84.177.94.1182175246.squirrel@webmail.xs4all.nl> References: <467669DF.8050806@charter.net> <4360.213.84.177.94.1182175246.squirrel@webmail.xs4all.nl> Message-ID: <4676C8BC.9070605@charter.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Arie Peterson wrote: > Isaac Dupree wrote: > >> One big question: can their presence have any effect? >> * on the module doing the exporting (conflict with the presence of >> in-module type-signature for the same thing; type restriction in-module; >> monomorphism-restriction-lifting or defaulting-removal of the named thing) >> * on modules importing this one (can a module re-export something, >> giving it a more restrictive type-signature?) > > Letting an export-list type signature be equivalent to a normal one has > the benefit of being simple (to explain and implement). Exporting a > function with a less polymorphic type than its in-module type seems a bit > awkward: you would have two different functions (one internal and one > exported) with the same name. Agreed. > > If export-list and normal type signatures would be equivalent, the only > benefit of allowing the former (compared to writing it in a comment) would > be that the compiler can check it for consistency. Right? Currently, it is not allowed to provide duplicate equivalent type-signatures for something. Neither is it allowed to put top-level type signatures that describe a function you import with the intent of exporting it; even so, you should be able to specify your module's interface however the exported functions are provided. How about this: the presence of an export-list type signature means that you will get a compile error if the type provided is not equivalent to the type the exported object has anyway, defined as: "((exportedObject :: type in export list) :: actual type)" typechecks. (where "actual type" is after all effects of monomorphism restriction, defaulting, etc., have taken effect) > >> The type doesn't need to be exported. (which is more likely if it's just >> a type synonym than a new type.) So what scope are the names in the >> export-list-type-signature drawn from? It would be odd if a type >> signature couldn't be given because some names weren't exported; but it >> would be odd if a module-user looking at the interface saw some types >> that weren't defined anywhere visible. > > As a user of the module, I would argue that all types (including synonyms) > appearing in the signature of an exported function should be exported as > well. Not sure if this needs to be enforced, though. Probably shouldn't be enforced - compilers could be made to give a warning for such bad behavior though. Luckily, "just outside" a module export list is purely a subset of in the module, so ... wait. module Foo1 where data Foo = CFoo1 module Foo2 where data Foo = CFoo2 module Ambig (Foo2.Foo(), foo) where import Foo1 import Foo2 foo = CFoo2 Not in the presence of ambiguity. Here, to be precise, we have (foo :: Foo2.Foo). Since the export list allows and requires Foo to be qualified when Foo is exported, I think it's fair to require that a type signature for 'foo' in the export list qualifies the Foo type it has with Foo2, even though from the module-user's point of view, there is only one Foo. Isaac -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGdsi7HgcxvIWYTTURAmqPAJ4lIrpsSK7bJWXYMxj/t6SOQkq+XwCgxtu2 9NHc1sG8qMtB6LmzyAfi9FY= =xlwH -----END PGP SIGNATURE----- From bulat.ziganshin at gmail.com Tue Jun 19 04:09:16 2007 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Tue Jun 19 04:06:43 2007 Subject: default fixity for `quotRem`, `divMod` ?? In-Reply-To: <4676BEDD.4010900@charter.net> References: <4676BEDD.4010900@charter.net> Message-ID: <1267954121.20070619120916@gmail.com> Hello Isaac, Monday, June 18, 2007, 9:20:29 PM, you wrote: > I was just bitten in ghci by `divMod` being the default infixl 9 instead > of the same as `div` and `mod`. one of my hard-to-find bugs was exactly in this area: i wrote something like x `div` y+1 instead of x `div` (y+1) so, based on practical experience, i have opposite proposal: give to all `op` lowest precedence (a bit higher than of '$') because it complies to its visual effect otoh this relates to my other (too revolutionary) proposal: bind "x+y" more closely than "x * y" for any (+) and (*), i.e. operation written without spaces around it should increase its priority by whole 10 points. it will allow significantly decrease amount of parentheses: f a+b*c x:xs ++ g u&&v record.$field -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From isaacdupree at charter.net Tue Jun 19 16:00:54 2007 From: isaacdupree at charter.net (Isaac Dupree) Date: Tue Jun 19 15:54:20 2007 Subject: default fixity for `quotRem`, `divMod` ?? In-Reply-To: <1267954121.20070619120916@gmail.com> References: <4676BEDD.4010900@charter.net> <1267954121.20070619120916@gmail.com> Message-ID: <467835F6.7080104@charter.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Bulat Ziganshin wrote: > Hello Isaac, > > Monday, June 18, 2007, 9:20:29 PM, you wrote: > >> I was just bitten in ghci by `divMod` being the default infixl 9 instead >> of the same as `div` and `mod`. > > one of my hard-to-find bugs was exactly in this area: i wrote > something like x `div` y+1 instead of x `div` (y+1) > > so, based on practical experience, i have opposite proposal: give to > all `op` lowest precedence (a bit higher than of '$') because it > complies to its visual effect I wonder how much code this would break. Maybe we could have a warning for anything that relies on the default fixity anyway (for things like x `div` y+1 , that don't give a type error anyway). And it would be nice if even e.g. `div` had the same precedence as all other `op`s in existence -- but I'm pretty sure that would break a bunch of code. Isaac -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGeDX1HgcxvIWYTTURAqA7AJ9WqCXZy2X/LhV18o6dpENaYx0k6gCgqXeG yAubnfVm3LBBj3l1/z/MZ18= =G8Uf -----END PGP SIGNATURE----- From dusty-aquarius at narod.ru Thu Jun 21 01:14:55 2007 From: dusty-aquarius at narod.ru (Dusty) Date: Thu Jun 21 01:09:41 2007 Subject: Newbie proposal: operator backquoting Message-ID: <30761182402895@webmail20.yandex.ru> Hello, dear list members! I'm just a Haskell newbie, but I want to make some proposal to Haskell'. There are some tickets in tracking system, that inspired by conflict between binary operators and other use of the same lexeme. At least I found 3 of that: "get rid of unary '-' operator" (http://hackage.haskell.org/trac/haskell-prime/ticket/50), "Eliminate . as an operator" (http://hackage.haskell.org/trac/haskell-prime/ticket/20) and "Replace the array indexing operator, '!'" (http://hackage.haskell.org/trac/haskell-prime/ticket/96). IMHO, all specified problems may be made less embarrassing - if not completly solved - if Haskell' have some way to solve lexical ambiguity in concrete position. As for those problems have similar lexical construct (binary operator) on one side - and different construct on other side: so this solution must take place over binary operators. I propose to use the same construct, that always used to convert function application to binary operator: backquoting. Any lexeme, bounded by backquotes, will be treated by grammar as binary operator; and no special grammatic case can be applied. So: ('-'1) is operator section, \x -> x-1, while (-1) is negative number ('-'y) is operator section, \x -> x-y, while (-y) is unary function application, negate y foo '-'1 has two arguments, (-) and 1, while foo -1 has one argument, -1 F'.'g is composition of function and constructor, while F.g is qualified function name ('!'x) is operator section, while !x is bang pattern (or strictness annotation). I think, this proposal does not require neither big changes in Haskell grammar, nor it ruins any existing code. Alexander Dakhov. From dusty-aquarius at narod.ru Mon Jun 25 01:07:52 2007 From: dusty-aquarius at narod.ru (Dusty) Date: Mon Jun 25 01:02:26 2007 Subject: Newbie proposal: operator backquoting In-Reply-To: <30761182402895@webmail20.yandex.ru> References: <30761182402895@webmail20.yandex.ru> Message-ID: <467F4DA8.000002.11827@webmail9.yandex.ru> I'm too sorry about that, but my post client does not compatible with Haskell: it replace all occurence of backquotes by ordinary quotes. Please, replace them back when look at my letter :(( Alexander Dakhov. > Hello, dear list members! > I'm just a Haskell newbie, but I want to make some proposal to Haskell'. > There are some tickets in tracking system, that inspired by conflict between binary operators and other use of the same lexeme. At least I found 3 of that: "get rid of unary '-' operator" (http://hackage.haskell.org/trac/haskell-prime/ticket/50), "Eliminate . as an operator" (http://hackage.haskell.org/trac/haskell-prime/ticket/20) and "Replace the array indexing operator, '!'" (http://hackage.haskell.org/trac/haskell-prime/ticket/96). > IMHO, all specified problems may be made less embarrassing - if not completly solved - if Haskell' have some way to solve lexical ambiguity in concrete position. As for those problems have similar lexical construct (binary operator) on one side - and different construct on other side: so this solution must take place over binary operators. > I propose to use the same construct, that always used to convert function application to binary operator: backquoting. Any lexeme, bounded by backquotes, will be treated by grammar as binary operator; and no special grammatic case can be applied. So: >('-'1) is operator section, \x -> x-1, while (-1) is negative number >('-'y) is operator section, \x -> x-y, while (-y) is unary function application, negate y >foo '-'1 has two arguments, (-) and 1, while foo -1 has one argument, -1 >F'.'g is composition of function and constructor, while F.g is qualified function name >('!'x) is operator section, while !x is bang pattern (or strictness annotation). > I think, this proposal does not require neither big changes in Haskell grammar, nor it ruins any existing code. > > Alexander Dakhov. >_______________________________________________ >Haskell-prime mailing list >Haskell-prime@haskell.org >http://www.haskell.org/mailman/listinfo/haskell-prime From igloo at earth.li Mon Jun 25 10:46:19 2007 From: igloo at earth.li (Ian Lynagh) Date: Mon Jun 25 10:40:41 2007 Subject: Newbie proposal: operator backquoting In-Reply-To: <30761182402895@webmail20.yandex.ru> References: <30761182402895@webmail20.yandex.ru> Message-ID: <20070625144619.GA16256@matrix.chaos.earth.li> On Thu, Jun 21, 2007 at 09:14:55AM +0400, Dusty wrote: > > foo '-'1 has two arguments, (-) and 1, while foo -1 has one argument, -1 You mean foo '-'1 is parsed as (-) foo 1 and foo -1 is parsed as foo (-1) right? What would foo - 1 mean? If it means (-) foo 1 then putting the extra space in looks a lot nicer to me than using backquotes. If it means foo (-1) then I think this will break a lot of code, and is also very unintuitive. Thanks Ian, a member of the "Out with DMR, defaulting, unary negation and n+k patterns" club From stefanor at cox.net Mon Jun 25 16:29:04 2007 From: stefanor at cox.net (Stefan O'Rear) Date: Mon Jun 25 16:23:25 2007 Subject: Newbie proposal: operator backquoting In-Reply-To: <20070625144619.GA16256@matrix.chaos.earth.li> References: <30761182402895@webmail20.yandex.ru> <20070625144619.GA16256@matrix.chaos.earth.li> Message-ID: <20070625202904.GA3122@localhost.localdomain> On Mon, Jun 25, 2007 at 03:46:19PM +0100, Ian Lynagh wrote: > On Thu, Jun 21, 2007 at 09:14:55AM +0400, Dusty wrote: > > > > foo '-'1 has two arguments, (-) and 1, while foo -1 has one argument, -1 > As *I* understood this, foo - 1 would not change. In fact except for the new `varsym` and `consym` forms, the grammer would not change. How would this break existing code? > Thanks > Ian, a member of the "Out with DMR, defaulting, unary negation and n+k > patterns" club Ian: what's DMR? Stefan From dusty-aquarius at narod.ru Mon Jun 25 16:35:49 2007 From: dusty-aquarius at narod.ru (Dusty) Date: Mon Jun 25 16:30:13 2007 Subject: Newbie proposal: operator backquoting Message-ID: <4021182803749@webmail19.yandex.ru> > On Thu, Jun 21, 2007 at 09:14:55AM +0400, Dusty wrote: > > > > foo '-'1 has two arguments, (-) and 1, while foo -1 has one argument, -1 > You mean > foo '-'1 > is parsed as > (-) foo 1 > and > foo -1 > is parsed as > foo (-1) > right? Yes! It was my mistake... > What would > foo - 1 > mean? If it means > (-) foo 1 > then putting the extra space in looks a lot nicer to me than using > backquotes. If it means > foo (-1) > then I think this will break a lot of code, and is also very > unintuitive. As for me, it must still parse as foo (-1). While this solution _is_ contra-intuitive, any other variant is _worse_. I suppose, parsing can take differently 0 and 1 spaces, but not 1 and 2... Alexander Dakhov. From dmhouse at gmail.com Mon Jun 25 16:46:51 2007 From: dmhouse at gmail.com (David House) Date: Mon Jun 25 16:41:15 2007 Subject: Newbie proposal: operator backquoting In-Reply-To: <20070625202904.GA3122@localhost.localdomain> References: <30761182402895@webmail20.yandex.ru> <20070625144619.GA16256@matrix.chaos.earth.li> <20070625202904.GA3122@localhost.localdomain> Message-ID: <18048.10683.513815.370968@gargle.gargle.HOWL> Stefan O'Rear writes: > what's DMR? The something monomorphism restriction, is my guess. http://haskell.org/onlinereport/decls.html#sect4.5.5 -- -David House, dmhouse@gmail.com From dmhouse at gmail.com Mon Jun 25 16:54:51 2007 From: dmhouse at gmail.com (David House) Date: Mon Jun 25 16:49:13 2007 Subject: Newbie proposal: operator backquoting In-Reply-To: <30761182402895@webmail20.yandex.ru> References: <30761182402895@webmail20.yandex.ru> Message-ID: <18048.11163.424278.895206@gargle.gargle.HOWL> Dusty writes: > I propose to use the same construct, that always used to convert function > application to binary operator: backquoting. Any lexeme, bounded by > backquotes, will be treated by grammar as binary operator; and no special > grammatic case can be applied. Presumably it wouldn't be _required_ to backquote operators. So the only time you'd be thinking of using backquotes is when you have some expression which is parsing weirdly, and you want to make it clearer. But then rather than using backquotes, as you propose, you could just disambiguate it in a different way that already exiss. For example, suppose you make the classic mistake of trying to use (.) with a constructor without putting sufficient space in: foo = Just.negate And this parses as the identifier 'negate' from the module Just. So under your proposal you could write this as: foo = Just`.`negate But equally one could just put spaces in: foo = Just . negate This is always possible. Therefore I don't see the value of your proposal, unless people get into the habit of using backquotes all the time, and thereby avoiding things like Just.negate from ever coming up in the first place. But I think this is unlikely. -- -David House, dmhouse@gmail.com From ndmitchell at gmail.com Mon Jun 25 18:39:20 2007 From: ndmitchell at gmail.com (Neil Mitchell) Date: Mon Jun 25 18:33:39 2007 Subject: Newbie proposal: operator backquoting In-Reply-To: <20070625202904.GA3122@localhost.localdomain> References: <30761182402895@webmail20.yandex.ru> <20070625144619.GA16256@matrix.chaos.earth.li> <20070625202904.GA3122@localhost.localdomain> Message-ID: <404396ef0706251539i38e0f1bam394dcc4d7b482c84@mail.gmail.com> Hi > > Ian, a member of the "Out with DMR, defaulting, unary negation and n+k > > patterns" club > > Ian: what's DMR? That's what I asked on IRC - answer: Dreaded Monomorphism Restriction. And as it happens, I am a member of the same club as Ian. Thanks Neil