From apa3a at yahoo.com Thu Nov 1 14:37:17 2007 From: apa3a at yahoo.com (Andriy Palamarchuk) Date: Thu Nov 1 14:34:37 2007 Subject: updateLookupWithKey bug? Was: Data.Map, Data.IntMap documentation (1611) In-Reply-To: <216132.29104.qm@web56414.mail.re3.yahoo.com> Message-ID: <593815.12565.qm@web56404.mail.re3.yahoo.com> I started to update documentation for Data.IntMap. I found a discrepancy between the modules' updateLookupWithKey behavior right in the area brought to my attention earlier: --- Andriy Palamarchuk wrote: > * As per > http://www.haskell.org/pipermail/libraries/2007-March/007304.html > added following information to the description of > updateLookupWithKey: > > The function returns changed value, if it is updated. > Returns the original key value if the map entry is deleted. The test case: > :m Data.Map > let f k x = if x == "a" then Just ((show k) ++ ":new a") else Nothing > updateLookupWithKey f 5 (fromList [(5,"a"), (3,"b")]) (Just "5:new a",fromList [(3,"b"),(5,"5:new a")]) > :m Data.IntMap > updateLookupWithKey f 5 (fromList [(5,"a"), (3,"b")]) (Just "a",fromList [(3,"b"),(5,"5:new a")]) The problem here is that Data.Map.updateLookupWithKey returns the *updated* value, but Data.IntMap.updateLookupWithKey returns the value *before* update. Please agree on the behavior, fix the bug and let me know what to write in the docs. Thanks, Andriy __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From dons at galois.com Thu Nov 1 14:38:21 2007 From: dons at galois.com (Don Stewart) Date: Thu Nov 1 14:35:43 2007 Subject: updateLookupWithKey bug? Was: Data.Map, Data.IntMap documentation (1611) In-Reply-To: <593815.12565.qm@web56404.mail.re3.yahoo.com> References: <216132.29104.qm@web56414.mail.re3.yahoo.com> <593815.12565.qm@web56404.mail.re3.yahoo.com> Message-ID: <20071101183821.GF25269@scytale.galois.com> And sounds like we need some QuickCheck properties too! apa3a: > I started to update documentation for Data.IntMap. I > found a discrepancy between the modules' > updateLookupWithKey behavior right in the area brought > to my attention earlier: > > --- Andriy Palamarchuk wrote: > > > * As per > > > http://www.haskell.org/pipermail/libraries/2007-March/007304.html > > added following information to the description of > > updateLookupWithKey: > > > > The function returns changed value, if it is > updated. > > Returns the original key value if the map entry is > deleted. > > The test case: > > > :m Data.Map > > let f k x = if x == "a" then Just ((show k) ++ ":new > a") else Nothing > > updateLookupWithKey f 5 (fromList [(5,"a"), > (3,"b")]) > > (Just "5:new a",fromList [(3,"b"),(5,"5:new a")]) > > > :m Data.IntMap > > updateLookupWithKey f 5 (fromList [(5,"a"), > (3,"b")]) > > (Just "a",fromList [(3,"b"),(5,"5:new a")]) > > The problem here is that Data.Map.updateLookupWithKey > returns the *updated* value, but > Data.IntMap.updateLookupWithKey returns the value > *before* update. > > Please agree on the behavior, fix the bug and let me > know what to write in the docs. > Thanks, > Andriy > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries From ahey at iee.org Fri Nov 2 04:49:59 2007 From: ahey at iee.org (Adrian Hey) Date: Fri Nov 2 04:47:19 2007 Subject: updateLookupWithKey bug? Was: Data.Map, Data.IntMap documentation (1611) In-Reply-To: <20071101183821.GF25269@scytale.galois.com> References: <216132.29104.qm@web56414.mail.re3.yahoo.com> <593815.12565.qm@web56404.mail.re3.yahoo.com> <20071101183821.GF25269@scytale.galois.com> Message-ID: <472AE4B7.7000000@iee.org> Actually I think there are several functions in Data.Map that should be deprecated, including this one (as I did in the clone I wrote). When it comes to complex hybrid operations like this there are just to many possible variations, none of which are obviously "correct". So unless you're going to provide them all and think of sensible names for them all it's probably best to provide none of them. Instead, it's trivially easy to implement a really cheap (but limited) zipper like thing, as is done with the OMap type in the AVL clone. Using this, the function in question (or anything similar) can easily be implemented by users themselves.. There's special about AVL trees, this can be done with any binary tree. It's just a simple node indexing scheme. And it is really cheap. Even with Ints as keys an OMap based insertion only takes about 10% longer than a regular insertion, and you get the added advantage that if the the tree is unmodified you really do get exactly the same tree (you don't pointlessly burn a lot of heap duplicating all the nodes on the search path). Regards -- Adrian Hey Don Stewart wrote: > And sounds like we need some QuickCheck properties too! > > apa3a: >> I started to update documentation for Data.IntMap. I >> found a discrepancy between the modules' >> updateLookupWithKey behavior right in the area brought >> to my attention earlier: >> >> --- Andriy Palamarchuk wrote: >> >>> * As per >>> >> http://www.haskell.org/pipermail/libraries/2007-March/007304.html >>> added following information to the description of >>> updateLookupWithKey: >>> >>> The function returns changed value, if it is >> updated. >>> Returns the original key value if the map entry is >> deleted. >> >> The test case: >> >>> :m Data.Map >>> let f k x = if x == "a" then Just ((show k) ++ ":new >> a") else Nothing >>> updateLookupWithKey f 5 (fromList [(5,"a"), >> (3,"b")]) >> >> (Just "5:new a",fromList [(3,"b"),(5,"5:new a")]) >> >>> :m Data.IntMap >>> updateLookupWithKey f 5 (fromList [(5,"a"), >> (3,"b")]) >> >> (Just "a",fromList [(3,"b"),(5,"5:new a")]) >> >> The problem here is that Data.Map.updateLookupWithKey >> returns the *updated* value, but >> Data.IntMap.updateLookupWithKey returns the value >> *before* update. >> >> Please agree on the behavior, fix the bug and let me >> know what to write in the docs. >> Thanks, >> Andriy >> >> >> __________________________________________________ >> Do You Yahoo!? >> Tired of spam? Yahoo! Mail has the best spam protection around >> http://mail.yahoo.com >> _______________________________________________ >> Libraries mailing list >> Libraries@haskell.org >> http://www.haskell.org/mailman/listinfo/libraries > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries > > From ahey at iee.org Fri Nov 2 05:06:29 2007 From: ahey at iee.org (Adrian Hey) Date: Fri Nov 2 05:03:49 2007 Subject: updateLookupWithKey bug? Was: Data.Map, Data.IntMap documentation (1611) In-Reply-To: <472AE4B7.7000000@iee.org> References: <216132.29104.qm@web56414.mail.re3.yahoo.com> <593815.12565.qm@web56404.mail.re3.yahoo.com> <20071101183821.GF25269@scytale.galois.com> <472AE4B7.7000000@iee.org> Message-ID: <472AE895.6020602@iee.org> Adrian Hey wrote: > There's special about AVL trees, Oops, insert the word "nothing" in the obvious place. From apa3a at yahoo.com Fri Nov 2 08:36:08 2007 From: apa3a at yahoo.com (Andriy Palamarchuk) Date: Fri Nov 2 08:33:25 2007 Subject: updateLookupWithKey bug? Was: Data.Map, Data.IntMap documentation (1611) In-Reply-To: <472AE895.6020602@iee.org> Message-ID: <772401.97950.qm@web56410.mail.re3.yahoo.com> Don, I'll leave QuickCheck out of scope for the documentation change. Adrian, question whether to deprecate updateLookupWithKey is worth discussing, but we need to fix the function anyway. All my documentation changes are ready. I'm holding the patch only for this problem. What if I leave the function description for IntMap the same as for Map and submit a bug report for the problem? Then the person resolving the bug will either fix the docs or the documentation. Any thoughts? Andriy __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From Christian.Maeder at dfki.de Fri Nov 2 09:47:18 2007 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Fri Nov 2 09:44:43 2007 Subject: updateLookupWithKey bug? Was: Data.Map, Data.IntMap documentation (1611) In-Reply-To: <772401.97950.qm@web56410.mail.re3.yahoo.com> References: <472AE895.6020602@iee.org> <772401.97950.qm@web56410.mail.re3.yahoo.com> Message-ID: <472B2A66.2060509@dfki.de> The original documentation only said "lookup and update". I think it makes more sense to return the old value (i.e. the lookup result in the original input map.), because the new value can be recomputed using the update function. The opposite (recomputation of the old value given the new one) is not possible. But I agree too, that deprecating this function is the right thing (in the future). Cheers Christian Andriy Palamarchuk wrote: > Don, I'll leave QuickCheck out of scope for the > documentation change. > > Adrian, question whether to deprecate > updateLookupWithKey is worth discussing, but we need > to fix the function anyway. > > All my documentation changes are ready. I'm holding > the patch only for this problem. > > What if I leave the function description for IntMap > the same as for Map and submit a bug report for the > problem? > Then the person resolving the bug will either fix the > docs or the documentation. > > Any thoughts? > Andriy > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com From ahey at iee.org Fri Nov 2 09:59:09 2007 From: ahey at iee.org (Adrian Hey) Date: Fri Nov 2 09:56:30 2007 Subject: updateLookupWithKey bug? Was: Data.Map, Data.IntMap documentation (1611) In-Reply-To: <772401.97950.qm@web56410.mail.re3.yahoo.com> References: <772401.97950.qm@web56410.mail.re3.yahoo.com> Message-ID: <472B2D2D.2090105@iee.org> Andriy Palamarchuk wrote: > Adrian, question whether to deprecate > updateLookupWithKey is worth discussing, but we need > to fix the function anyway. I would say just document the code as it is, warts and all. Don't change the functions because maybe someone is using them (though I suspect this is not the case). But also add a DEPRECATE pragma to discourage further use. Maybe do this for both IntMap and Map, because even if they were consistent, I don't think they're very useful. An API that clearly separates the process of searching for the key from whatever you want to do when it's found (or not) is so much more flexible and easy to understand IMHO. BTW, the way I did this should also work for IntMap tries too AFAICT, but I'm not sure it would offer any performance advantage over a repeated lookup in this case. So maybe keep them for IntMap? My 2p.. Regards -- Adrian Hey From iavor.diatchki at gmail.com Fri Nov 2 12:43:41 2007 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Fri Nov 2 12:41:09 2007 Subject: updateLookupWithKey bug? Was: Data.Map, Data.IntMap documentation (1611) In-Reply-To: <472B2D2D.2090105@iee.org> References: <772401.97950.qm@web56410.mail.re3.yahoo.com> <472B2D2D.2090105@iee.org> Message-ID: <5ab17e790711020943n2fd04e4bmb5993146ac50197f@mail.gmail.com> Hi, I have always wondered about the usefulness of the "withKey" functions because the key is one of the arguments that the programmer is passing anyway, so they already know its value. The only situation that I can think of where that might not be the case is if the equality relation on the keys is actually an equivalence relation, so the key in the map might be different from the key that was passed by the programmer even though they are "equal", and the distinction between the two keys is important. I would be a bit suspect of code that relies on that though... Does anybody have other uses of the "withKey" functions? -Iavor PS: as for the bug, I would just fix it (i.e., send a patch) On 11/2/07, Adrian Hey wrote: > Andriy Palamarchuk wrote: > > Adrian, question whether to deprecate > > updateLookupWithKey is worth discussing, but we need > > to fix the function anyway. > > I would say just document the code as it is, warts and all. > Don't change the functions because maybe someone is using them > (though I suspect this is not the case). > > But also add a DEPRECATE pragma to discourage further use. > > Maybe do this for both IntMap and Map, because even if they were > consistent, I don't think they're very useful. An API that clearly > separates the process of searching for the key from whatever you want > to do when it's found (or not) is so much more flexible and easy to > understand IMHO. > > BTW, the way I did this should also work for IntMap tries too AFAICT, > but I'm not sure it would offer any performance advantage over a > repeated lookup in this case. So maybe keep them for IntMap? > > My 2p.. > > Regards > -- > Adrian Hey > > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries > From Christian.Maeder at dfki.de Fri Nov 2 13:40:02 2007 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Fri Nov 2 13:40:07 2007 Subject: updateLookupWithKey bug? Was: Data.Map, Data.IntMap documentation (1611) In-Reply-To: <5ab17e790711020943n2fd04e4bmb5993146ac50197f@mail.gmail.com> References: <772401.97950.qm@web56410.mail.re3.yahoo.com> <472B2D2D.2090105@iee.org> <5ab17e790711020943n2fd04e4bmb5993146ac50197f@mail.gmail.com> Message-ID: <472B60F2.3010001@dfki.de> Iavor Diatchki wrote: > Hi, > I have always wondered about the usefulness of the "withKey" functions > because the key is one of the arguments that the programmer is passing > anyway, so they already know its value. [...] > Does anybody have other uses of the "withKey" functions? > -Iavor The WithKey-variants are used where a new value is computed from an old one and when this function also needs to consider the key. At least filterWithKey and foldWithKey are very useful. > > PS: as for the bug, I would just fix it (i.e., send a patch) Which implementation do you consider buggy? IntMap or Map? (or may just document it as inconsistent) Cheers Christian From apa3a at yahoo.com Fri Nov 2 15:21:25 2007 From: apa3a at yahoo.com (Andriy Palamarchuk) Date: Fri Nov 2 15:18:40 2007 Subject: updateLookupWithKey bug? Was: Data.Map, Data.IntMap documentation (1611) In-Reply-To: <472B60F2.3010001@dfki.de> Message-ID: <181254.77294.qm@web56402.mail.re3.yahoo.com> --- Christian Maeder wrote: > Which implementation do you consider buggy? IntMap > or Map? > > (or may just document it as inconsistent) Map is used much wider, so a change to its behavior would be more disruptive. We should take into account what other Map implementations do. See, e.g. this message mentioned earlier when discussing the documentation change: http://www.haskell.org/pipermail/libraries/2007-March/007304.html Andriy __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From iavor.diatchki at gmail.com Fri Nov 2 16:38:17 2007 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Fri Nov 2 16:35:36 2007 Subject: updateLookupWithKey bug? Was: Data.Map, Data.IntMap documentation (1611) In-Reply-To: <472B60F2.3010001@dfki.de> References: <772401.97950.qm@web56410.mail.re3.yahoo.com> <472B2D2D.2090105@iee.org> <5ab17e790711020943n2fd04e4bmb5993146ac50197f@mail.gmail.com> <472B60F2.3010001@dfki.de> Message-ID: <5ab17e790711021338k2847c9d6jca1ba56eaf7cf0d0@mail.gmail.com> Hello, On 11/2/07, Christian Maeder wrote: > Iavor Diatchki wrote: > > Hi, > > I have always wondered about the usefulness of the "withKey" functions > > because the key is one of the arguments that the programmer is passing > > anyway, so they already know its value. > [...] > > Does anybody have other uses of the "withKey" functions? > > -Iavor > > The WithKey-variants are used where a new value is computed from an old > one and when this function also needs to consider the key. > > At least filterWithKey and foldWithKey are very useful. I was referring to the insert,update,adjust functions where the key is already one of the arguments to the function. For the various traversals having a WithKey version makes sense. > > PS: as for the bug, I would just fix it (i.e., send a patch) > > Which implementation do you consider buggy? IntMap or Map? > > (or may just document it as inconsistent) I think that the two should have the same behaviour. To me, the implementation that returns the _old_ value seems more useful. -Iavor From twanvl at gmail.com Sat Nov 3 13:56:33 2007 From: twanvl at gmail.com (Twan van Laarhoven) Date: Sat Nov 3 13:53:42 2007 Subject: System.FilePath.joinDrive problem Message-ID: <472CB651.7090404@gmail.com> Hello all, The joinDrive function currently produces paths such as "C:File" when calling "C:" "File". This is apparently handled in a special case: > | otherwise = case a of > [a1,':'] | isLetter a1 -> a ++ b > _ -> a ++ [pathSeparator] ++ b This seems wrong, as far as I know "C:File" is not a valid path. What is the reason for this special case? In particular this problem results in cabal wanting to install packages to "E:Haskell" on my computer (unless I pass a --prefix flag). Twan From bulat.ziganshin at gmail.com Sat Nov 3 14:33:21 2007 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sat Nov 3 14:32:30 2007 Subject: System.FilePath.joinDrive problem In-Reply-To: <472CB651.7090404@gmail.com> References: <472CB651.7090404@gmail.com> Message-ID: <719410959.20071103213321@gmail.com> Hello Twan, Saturday, November 3, 2007, 8:56:33 PM, you wrote: > This seems wrong, as far as I know "C:File" is not a valid path. What is > the reason for this special case? it's correct path and i think that program has correct behavior in this case. if you need to construct "c:\file", you should use "c:\" as directory (written as "c:\\", of course) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From twanvl at gmail.com Sat Nov 3 15:48:12 2007 From: twanvl at gmail.com (Twan van Laarhoven) Date: Sun Nov 4 04:59:29 2007 Subject: System.FilePath.joinDrive problem In-Reply-To: <719410959.20071103213321@gmail.com> References: <472CB651.7090404@gmail.com> <719410959.20071103213321@gmail.com> Message-ID: <472CD07C.3000607@gmail.com> Bulat Ziganshin wrote: > Hello Twan, > > Saturday, November 3, 2007, 8:56:33 PM, you wrote: > > >>This seems wrong, as far as I know "C:File" is not a valid path. What is >>the reason for this special case? > > > it's correct path and i think that program has correct behavior in > this case. if you need to construct "c:\file", you should use "c:\" as > directory (written as "c:\\", of course) > On windows the 'path' "C:File" refers to the file named "File" on the drive "C:", in the *current directory* for that drive. It is a kind of half relative path. This behaviour is at the very least unintuitive. In my opinion a 'path' like "C:File" is completely useless. The FilePath library never produces "C:" as an element itself, so what we do here doesn't matter much. A good argument in favor of adding the backslash is that a trailing slash on a directory name should not matter. I.e, for f not ending in a slash: (f g) == (f ++ [pathSeparator] g) This holds for normal directories, but not if f is a drive letter. I have investigated what some different platforms do: - Win32: PathAppend gives "C:\File" - .Net: Path.Combine gives "C:File" - Perl: File::Spec->catfile gives "C:/File" I would take the behaviour of the Win32 api as authorative here. Twan From wnoise at ofb.net Sat Nov 3 14:56:06 2007 From: wnoise at ofb.net (Aaron Denney) Date: Sun Nov 4 04:59:35 2007 Subject: System.FilePath.joinDrive problem References: <472CB651.7090404@gmail.com> Message-ID: On 2007-11-03, Twan van Laarhoven wrote: > Hello all, > > The joinDrive function currently produces paths such as "C:File" when > calling "C:" "File". This is apparently handled in a special case: > > > | otherwise = case a of > > [a1,':'] | isLetter a1 -> a ++ b > > _ -> a ++ [pathSeparator] ++ b > > This seems wrong, as far as I know "C:File" is not a valid path. What is > the reason for this special case? C:File refers to the file "File" in the current directory on drive c:. Each drive in windows has its own current directory. -- Aaron Denney -><- From bulat.ziganshin at gmail.com Sat Nov 3 16:21:43 2007 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sun Nov 4 05:00:10 2007 Subject: System.FilePath.joinDrive problem In-Reply-To: <472CD07C.3000607@gmail.com> References: <472CB651.7090404@gmail.com> <719410959.20071103213321@gmail.com> <472CD07C.3000607@gmail.com> Message-ID: <1691748747.20071103232143@gmail.com> Hello Twan, Saturday, November 3, 2007, 10:48:12 PM, you wrote: > This behaviour is at the very least unintuitive. it was in dos for 23 years, so it is well known and used by all utilities: D:\temp\8> c: C:\Haskell\docs> dir d: Contents of directory D:\temp\8 31.10.2007 12:41 . 31.10.2007 12:41 .. 30.10.2007 23:58 1 15.04.2005 19:31 24 compile.btm C:\Haskell\docs> zip archive d:compile.btm adding: compile.btm (188 bytes security) (stored 0%) C:\Haskell\docs> > I have investigated what some different platforms do: > - Win32: PathAppend gives "C:\File" what documentation on this function says? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From bulat.ziganshin at gmail.com Sat Nov 3 17:19:38 2007 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sun Nov 4 05:00:21 2007 Subject: System.FilePath.joinDrive problem In-Reply-To: <472CD07C.3000607@gmail.com> References: <472CB651.7090404@gmail.com> <719410959.20071103213321@gmail.com> <472CD07C.3000607@gmail.com> Message-ID: <15310363824.20071104001938@gmail.com> Hello Twan, Saturday, November 3, 2007, 10:48:12 PM, you wrote: > - Win32: PathAppend gives "C:\File" i've found and read its docs. my guess is that shell API was provided for GUI programs that doesn't have "current directory on other disks" concept, so your suggestion may be more appropriate for GUI apps, while current one conforms to the behavior of command-line utilities, including MS own ones at least for my own application i need current behavior and there is problem of backward compatibility with existing FilePath versions -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From bulat.ziganshin at gmail.com Sat Nov 3 17:33:24 2007 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sun Nov 4 05:00:22 2007 Subject: bug in System.FilePath.isRelative ? Message-ID: <998082745.20071104003324@gmail.com> Hello libraries, system - win32. *FilePath> isRelative "c:file" False this path should be considered as relative, afaik -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From seth at cql.com Sat Nov 3 17:54:28 2007 From: seth at cql.com (Seth Kurtzberg) Date: Sun Nov 4 05:00:23 2007 Subject: System.FilePath.joinDrive problem In-Reply-To: <1691748747.20071103232143@gmail.com> References: <472CB651.7090404@gmail.com> <719410959.20071103213321@gmail.com> <472CD07C.3000607@gmail.com> <1691748747.20071103232143@gmail.com> Message-ID: <02dd01c81e64$1b9f5990$52de0cb0$@com> I find it esthetically displeasing, but Bulat is correct; it is relied on in many situations by many programs. -----Original Message----- From: libraries-bounces@haskell.org [mailto:libraries-bounces@haskell.org] On Behalf Of Bulat Ziganshin Sent: Saturday, November 03, 2007 4:22 PM To: Twan van Laarhoven Cc: libraries@haskell.org; Bulat Ziganshin Subject: Re[2]: System.FilePath.joinDrive problem Hello Twan, Saturday, November 3, 2007, 10:48:12 PM, you wrote: > This behaviour is at the very least unintuitive. it was in dos for 23 years, so it is well known and used by all utilities: D:\temp\8> c: C:\Haskell\docs> dir d: Contents of directory D:\temp\8 31.10.2007 12:41 . 31.10.2007 12:41 .. 30.10.2007 23:58 1 15.04.2005 19:31 24 compile.btm C:\Haskell\docs> zip archive d:compile.btm adding: compile.btm (188 bytes security) (stored 0%) C:\Haskell\docs> > I have investigated what some different platforms do: > - Win32: PathAppend gives "C:\File" what documentation on this function says? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries From twanvl at gmail.com Sat Nov 3 19:33:44 2007 From: twanvl at gmail.com (Twan van Laarhoven) Date: Sun Nov 4 05:00:30 2007 Subject: System.FilePath.joinDrive problem In-Reply-To: <02dd01c81e64$1b9f5990$52de0cb0$@com> References: <472CB651.7090404@gmail.com> <719410959.20071103213321@gmail.com> <472CD07C.3000607@gmail.com> <1691748747.20071103232143@gmail.com> <02dd01c81e64$1b9f5990$52de0cb0$@com> Message-ID: <472D0558.1000708@gmail.com> Seth Kurtzberg wrote: > I find it esthetically displeasing, but Bulat is correct; it is relied on in > many situations by many programs. It is not the "C:File" filename itself I have a problem with, but rather that "C:" "File" == "C:File". When you are combining "C:" with a filename you are treating it as a kind of directory name. Almost all windows programs *will* treat "C:" the same as "C:\", and from the user's point of view this is IMO correct. The reason I came upon this problem was that my %ProgramFiles% was set to "E:". For years this has worked without incident, all programs handle this just fine. The only program that doesn't accept this is cabal. On the other hand, many other functions do treat "C:" as a kind of relative path name, from that view the current behaviour makes sense. Anyway, I am prepared to admit that I am wrong and that FilePath's behaviour is in fact correct. I guess drive names just really suck. A thing that is even more unexpected is: > "C:" "\\file" == "\\file" A path like "\\file" is relative to the current drive. Giving a drive letter should make it completely absolute. Twan From ndmitchell at gmail.com Sun Nov 4 07:45:33 2007 From: ndmitchell at gmail.com (Neil Mitchell) Date: Sun Nov 4 07:42:44 2007 Subject: bug in System.FilePath.isRelative ? In-Reply-To: <998082745.20071104003324@gmail.com> References: <998082745.20071104003324@gmail.com> Message-ID: <404396ef0711040445k3497bf94sc940147a5e2603ae@mail.gmail.com> Hi > *FilePath> isRelative "c:file" > False > > this path should be considered as relative, afaik Certainly some things treat this as relative. But really, its not that relative by other metrics. A relative path in general should be able to be reconstituted by doing currentDirectory x. This does not have that property. The other property you might expect a relative path to have is that changing the current directory changes the path - which is half true, since on Windows there is a current directory per drive, so this relative path may refer to that, or not. Basically, having c:file is REALLY broken from every sensible point of view. If you can give me a "in this real program it needs to be this way because..." then I'll change it. If its more a theoretical concern, then it depends how loud you shout or what the common concensus is. In summary: filepaths are a nightmare. Thanks Neil From ndmitchell at gmail.com Sun Nov 4 07:54:51 2007 From: ndmitchell at gmail.com (Neil Mitchell) Date: Sun Nov 4 07:52:03 2007 Subject: System.FilePath.joinDrive problem In-Reply-To: <472D0558.1000708@gmail.com> References: <472CB651.7090404@gmail.com> <719410959.20071103213321@gmail.com> <472CD07C.3000607@gmail.com> <1691748747.20071103232143@gmail.com> <02dd01c81e64$1b9f5990$52de0cb0$@com> <472D0558.1000708@gmail.com> Message-ID: <404396ef0711040454t1863f253w79d700698716d62b@mail.gmail.com> Hi > > I find it esthetically displeasing, but Bulat is correct; it is relied on in > > many situations by many programs. > > It is not the "C:File" filename itself I have a problem with, but rather > that "C:" "File" == "C:File". That does seem very unintuative, but that's drives for you. For reference, I did follow the C# path functions as a general reference. The Shell ones are a kind of weird API that isn't in the built in Win32 API, and don't tend to be used that much. > Anyway, I am prepared to admit that I am wrong and that FilePath's > behaviour is in fact correct. I guess drive names just really suck. I think the drive behaviour is totally wrong on many levels. If you use something like Windows CE, then all paths have to be relative - this is a much better choice. Relative directories/drives are an artefact of combining an API with a user interface metaphore (the console) - and as a result are confusing. > A thing that is even more unexpected is: > > "C:" "\\file" == "\\file" > > A path like "\\file" is relative to the current drive. Giving a drive > letter should make it completely absolute. Perhaps - that does sound sensible. Is "\\file" relative or absolute? If its absolute, then combining with "C:" should not change anything. I think in reality its relative in a "drive" sense but absolute in a "path" sense. If anyone wants to knock up a design of a new API for these particularly difficult bits, feel free. Thanks Neil From bulat.ziganshin at gmail.com Sun Nov 4 09:26:36 2007 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sun Nov 4 09:25:39 2007 Subject: System.FilePath.joinDrive problem In-Reply-To: <472D0558.1000708@gmail.com> References: <472CB651.7090404@gmail.com> <719410959.20071103213321@gmail.com> <472CD07C.3000607@gmail.com> <1691748747.20071103232143@gmail.com> <02dd01c81e64$1b9f5990$52de0cb0$@com> <472D0558.1000708@gmail.com> Message-ID: <92333076.20071104172636@gmail.com> Hello Twan, Sunday, November 4, 2007, 2:33:44 AM, you wrote: > The reason I came upon this problem was that my %ProgramFiles% was set > to "E:". For years this has worked without incident, all programs handle > this just fine. The only program that doesn't accept this is cabal. i think that you just violated agreement that here absolute path should be used. while your program was GUI ones, e: and e:\ was the same, but when you installed console program that inherits its environment from cmd, things goes wrong. is it possible to use "e:\" here? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From ross at soi.city.ac.uk Sun Nov 4 10:33:21 2007 From: ross at soi.city.ac.uk (Ross Paterson) Date: Sun Nov 4 10:30:43 2007 Subject: base split in GHC 6.8.1 Message-ID: <20071104153320.GA20185@soi.city.ac.uk> The following library packages on HackageDB fail with missing modules under GHC 6.8.1, usually due to the base split: bencode gd IFS pqc bktrees harpy Imlib Ranged-sets bzlib haskelldb lazysmallcheck regex-base classify HaXml libxml safecopy clevercss HCL ListLike Shellac dataenc HDBC LRU sparsecheck derive hgal metaplug StrategyLib dsp hinotify mime-string strict encoding hmarkup MonadRandom suffixtree Etherbunny hsemail numeric-quest syb-with-class fastcgi HsOpenSSL pandoc template FileManip hsql parsedate uniplate funcmp hsSqlite3 pcap vty functorm hxt plugins zlib From ndmitchell at gmail.com Sun Nov 4 10:38:55 2007 From: ndmitchell at gmail.com (Neil Mitchell) Date: Sun Nov 4 10:36:06 2007 Subject: base split in GHC 6.8.1 In-Reply-To: <20071104153320.GA20185@soi.city.ac.uk> References: <20071104153320.GA20185@soi.city.ac.uk> Message-ID: <404396ef0711040738r1c6d63b7n65a405b7cd558d5a@mail.gmail.com> Hi > The following library packages on HackageDB fail with missing modules > under GHC 6.8.1, usually due to the base split: How do we fix it? Clearly making it 6.8.1 compatible is a good thing, but breaking 6.6.1 compatibility would be bad - and requiring everyone to update their Cabal is likely to be equally painful. If someone could write a brief tutorial (perhaps on the Wiki) of the recommended (TM) way to go, I'll update my packages. Thanks Neil From ross at soi.city.ac.uk Sun Nov 4 10:49:59 2007 From: ross at soi.city.ac.uk (Ross Paterson) Date: Sun Nov 4 10:47:17 2007 Subject: base split in GHC 6.8.1 In-Reply-To: <404396ef0711040738r1c6d63b7n65a405b7cd558d5a@mail.gmail.com> References: <20071104153320.GA20185@soi.city.ac.uk> <404396ef0711040738r1c6d63b7n65a405b7cd558d5a@mail.gmail.com> Message-ID: <20071104154959.GA20314@soi.city.ac.uk> On Sun, Nov 04, 2007 at 03:38:55PM +0000, Neil Mitchell wrote: > How do we fix it? Clearly making it 6.8.1 compatible is a good thing, > but breaking 6.6.1 compatibility would be bad - and requiring everyone > to update their Cabal is likely to be equally painful. > > If someone could write a brief tutorial (perhaps on the Wiki) of the > recommended (TM) way to go, I'll update my packages. http://www.haskell.org/haskellwiki/Upgrading_packages It does require that users upgrade their Cabal, but it provides compatibility with both 6.6 and 6.8. From duncan.coutts at worc.ox.ac.uk Sun Nov 4 11:41:59 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Nov 4 11:36:08 2007 Subject: base split in GHC 6.8.1 In-Reply-To: <20071104153320.GA20185@soi.city.ac.uk> References: <20071104153320.GA20185@soi.city.ac.uk> Message-ID: <1194194519.26140.114.camel@localhost> On Sun, 2007-11-04 at 15:33 +0000, Ross Paterson wrote: > The following library packages on HackageDB fail with missing modules > under GHC 6.8.1, usually due to the base split: Thanks very much Ross for doing this survey. We probably should send an announcement on to the haskell or haskell-cafe list aimed at package maintainers with this info and the info on how to update to enable compatibility with 6.6 and 6.8. We should probably include the standard symptom, ie the build message about missing modules / hidden packages. > bencode gd IFS pqc > bktrees harpy Imlib Ranged-sets > bzlib haskelldb lazysmallcheck regex-base > classify HaXml libxml safecopy > clevercss HCL ListLike Shellac > dataenc HDBC LRU sparsecheck > derive hgal metaplug StrategyLib > dsp hinotify mime-string strict > encoding hmarkup MonadRandom suffixtree > Etherbunny hsemail numeric-quest syb-with-class > fastcgi HsOpenSSL pandoc template > FileManip hsql parsedate uniplate > funcmp hsSqlite3 pcap vty > functorm hxt plugins zlib Was this testing the latest version of each package? I updated the zlib and bzlib packages on hackage to work with 6.8.1 the other day. Maybe it's missing header files rather than package version / configuration failures. Duncan From ross at soi.city.ac.uk Sun Nov 4 12:21:57 2007 From: ross at soi.city.ac.uk (Ross Paterson) Date: Sun Nov 4 12:19:14 2007 Subject: base split in GHC 6.8.1 In-Reply-To: <1194194519.26140.114.camel@localhost> References: <20071104153320.GA20185@soi.city.ac.uk> <1194194519.26140.114.camel@localhost> Message-ID: <20071104172157.GA20461@soi.city.ac.uk> On Sun, Nov 04, 2007 at 04:41:59PM +0000, Duncan Coutts wrote: > Was this testing the latest version of each package? I updated the zlib > and bzlib packages on hackage to work with 6.8.1 the other day. Maybe > it's missing header files rather than package version / configuration > failures. bzlib-0.4.0.1 and zlib-0.4.0.1 both use Data.ByteString.Base, which is absent from bytestring-0.9.0.1. From duncan.coutts at worc.ox.ac.uk Sun Nov 4 13:53:49 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Nov 4 13:47:57 2007 Subject: base split in GHC 6.8.1 In-Reply-To: <20071104172157.GA20461@soi.city.ac.uk> References: <20071104153320.GA20185@soi.city.ac.uk> <1194194519.26140.114.camel@localhost> <20071104172157.GA20461@soi.city.ac.uk> Message-ID: <1194202429.26140.120.camel@localhost> On Sun, 2007-11-04 at 17:21 +0000, Ross Paterson wrote: > On Sun, Nov 04, 2007 at 04:41:59PM +0000, Duncan Coutts wrote: > > Was this testing the latest version of each package? I updated the zlib > > and bzlib packages on hackage to work with 6.8.1 the other day. Maybe > > it's missing header files rather than package version / configuration > > failures. > > bzlib-0.4.0.1 and zlib-0.4.0.1 both use Data.ByteString.Base, which is > absent from bytestring-0.9.0.1. Did it fail to build or did you just grep for Data.ByteString.Base. It uses cpp to work with the bytestring code in base-2.0 or the separate bytestring package. I just tested it again and the zlib and bzlib tarballs from hackage build ok for me with ghc 6.4.2, 6.6.1 and 6.8.1. BTW, thanks also for uploading all the extralib packages to hackage. I've updated the gentoo ebuilds to work from those packages rather than the ghc-6.8.1 extralibs tarball. They all work fine except the regex-posix one as it's missing the regex-posix.buildinfo.in file from the tarball. It'll have to be listed in the extra-source-files field and re-upload the tarball with a micro version bump. I can do this if you like. Duncan From seth at cql.com Sun Nov 4 14:15:14 2007 From: seth at cql.com (Seth Kurtzberg) Date: Sun Nov 4 14:12:28 2007 Subject: System.FilePath.joinDrive problem In-Reply-To: <92333076.20071104172636@gmail.com> References: <472CB651.7090404@gmail.com> <719410959.20071103213321@gmail.com> <472CD07C.3000607@gmail.com> <1691748747.20071103232143@gmail.com> <02dd01c81e64$1b9f5990$52de0cb0$@com> <472D0558.1000708@gmail.com> <92333076.20071104172636@gmail.com> Message-ID: <031b01c81f17$06f57e80$14e07b80$@com> The fact that the behavior (where a current directory is maintained) is related to the command interpreter certainly changes things. Command interpreter programs are not insignificant (if you use cygwin, or something similar), but logically if the win32 API behaves differently, then the win32 API behavior is (IMO) the properly expected behavior. What is the behavior of programs compiled within cygwin? Seth Kurtzberg Software Engineer Specializing in Security, Reliability, and the Hardware/Software Interface -----Original Message----- From: Bulat Ziganshin [mailto:bulat.ziganshin@gmail.com] Sent: Sunday, November 04, 2007 9:27 AM To: Twan van Laarhoven Cc: Seth Kurtzberg; 'Bulat Ziganshin'; libraries@haskell.org Subject: Re[2]: System.FilePath.joinDrive problem Hello Twan, Sunday, November 4, 2007, 2:33:44 AM, you wrote: > The reason I came upon this problem was that my %ProgramFiles% was set > to "E:". For years this has worked without incident, all programs handle > this just fine. The only program that doesn't accept this is cabal. i think that you just violated agreement that here absolute path should be used. while your program was GUI ones, e: and e:\ was the same, but when you installed console program that inherits its environment from cmd, things goes wrong. is it possible to use "e:\" here? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From duncan.coutts at worc.ox.ac.uk Sun Nov 4 14:28:02 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Nov 4 14:22:24 2007 Subject: base split in GHC 6.8.1 In-Reply-To: <1194202429.26140.120.camel@localhost> References: <20071104153320.GA20185@soi.city.ac.uk> <1194194519.26140.114.camel@localhost> <20071104172157.GA20461@soi.city.ac.uk> <1194202429.26140.120.camel@localhost> Message-ID: <1194204482.26140.122.camel@localhost> On Sun, 2007-11-04 at 18:53 +0000, Duncan Coutts wrote: > They all work fine except the regex-posix one as it's missing the > regex-posix.buildinfo.in file from the tarball. It'll have to be listed > in the extra-source-files field and re-upload the tarball with a micro > version bump. I can do this if you like. Done. Duncan From ross at soi.city.ac.uk Sun Nov 4 14:36:05 2007 From: ross at soi.city.ac.uk (Ross Paterson) Date: Sun Nov 4 14:33:46 2007 Subject: base split in GHC 6.8.1 In-Reply-To: <1194202429.26140.120.camel@localhost> References: <20071104153320.GA20185@soi.city.ac.uk> <1194194519.26140.114.camel@localhost> <20071104172157.GA20461@soi.city.ac.uk> <1194202429.26140.120.camel@localhost> Message-ID: <20071104193605.GA21414@soi.city.ac.uk> On Sun, Nov 04, 2007 at 06:53:49PM +0000, Duncan Coutts wrote: > Did it fail to build or did you just grep for Data.ByteString.Base. It > uses cpp to work with the bytestring code in base-2.0 or the separate > bytestring package. I just tested it again and the zlib and bzlib > tarballs from hackage build ok for me with ghc 6.4.2, 6.6.1 and 6.8.1. I used the wrong version of cabal-setup. It's OK with one compiled with GHC 6.8.1. From bulat.ziganshin at gmail.com Sun Nov 4 15:00:33 2007 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sun Nov 4 14:59:31 2007 Subject: System.FilePath.joinDrive problem In-Reply-To: <031b01c81f17$06f57e80$14e07b80$@com> References: <472CB651.7090404@gmail.com> <719410959.20071103213321@gmail.com> <472CD07C.3000607@gmail.com> <1691748747.20071103232143@gmail.com> <02dd01c81e64$1b9f5990$52de0cb0$@com> <472D0558.1000708@gmail.com> <92333076.20071104172636@gmail.com> <031b01c81f17$06f57e80$14e07b80$@com> Message-ID: <1824010742.20071104230033@gmail.com> Hello Seth, Sunday, November 4, 2007, 10:15:14 PM, you wrote: i just simplified my description. console programs has current directory" on each drive and inherit it from parent program. i don't know exact behavior of GUI programs. shlwapi.dll is just helper dll which contains various string functions in particular. i don't think that it defines "Windows API" although i may be wrong here i don't use cygwin and imho its behavior is not definitive in this case > The fact that the behavior (where a current directory is maintained) is > related to the command interpreter certainly changes things. Command > interpreter programs are not insignificant (if you use cygwin, or something > similar), but logically if the win32 API behaves differently, then the win32 > API behavior is (IMO) the properly expected behavior. > What is the behavior of programs compiled within cygwin? > Seth Kurtzberg > Software Engineer > Specializing in Security, Reliability, and the Hardware/Software Interface > -----Original Message----- > From: Bulat Ziganshin [mailto:bulat.ziganshin@gmail.com] > Sent: Sunday, November 04, 2007 9:27 AM > To: Twan van Laarhoven > Cc: Seth Kurtzberg; 'Bulat Ziganshin'; libraries@haskell.org > Subject: Re[2]: System.FilePath.joinDrive problem > Hello Twan, > Sunday, November 4, 2007, 2:33:44 AM, you wrote: >> The reason I came upon this problem was that my %ProgramFiles% was set >> to "E:". For years this has worked without incident, all programs handle >> this just fine. The only program that doesn't accept this is cabal. > i think that you just violated agreement that here absolute path > should be used. while your program was GUI ones, e: and e:\ was the > same, but when you installed console program that inherits its > environment from cmd, things goes wrong. is it possible to use "e:\" > here? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From anakreon at csd.auth.gr Mon Nov 5 06:18:02 2007 From: anakreon at csd.auth.gr (Anakreon Mendis) Date: Mon Nov 5 06:32:17 2007 Subject: Space handling with Parsec Message-ID: <87myttq6tx.fsf@mathind.csd.auth.gr> I hope this is the correct mailing list do address parsec related questions. There is a question about parsec which I hope you could help. According to the documentation space parser recognizes '\n' as a space character. I am implementing a Basic parser where newline is important. For example, now the parser accepts the expression: a = 1 + 2 as equivalent to "a= 1 + 2" when it shouldn't. If this was the only problem, it wouldn't be a big deal. However, in basic, a function call is not required to enclose the arguments with parenthesis. Thus, the expressions: myFunc anOtherFunc arg1, arg2 are valid. Since the newline is skipped, when the parser tries to match the optional arguments of myFunc, it will search them in the line below. The parser will consume characters and will fail. What I tried to do is: imported the Parsec module, hiding the `space`. Reimplemented the space parser as space = oneOf [' ', '\t'] The parser behaved the same. Afterwords, I implemented the whiteSpace parser as whiteSpace = skipMany space This didn't work either. From simonmarhaskell at gmail.com Mon Nov 5 08:14:37 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Mon Nov 5 08:11:48 2007 Subject: [Fwd: Re: readline] Message-ID: <472F173D.7030601@gmail.com> Forwarding on behalf of alpheccar -------------- next part -------------- An embedded message was scrubbed... From: alpheccar Subject: Re: readline Date: Mon, 5 Nov 2007 13:15:03 +0100 Size: 4342 Url: http://www.haskell.org/pipermail/libraries/attachments/20071105/4d1823d1/readline.eml From mdanish at andrew.cmu.edu Mon Nov 5 09:20:13 2007 From: mdanish at andrew.cmu.edu (Matthew Danish) Date: Mon Nov 5 09:17:43 2007 Subject: Space handling with Parsec In-Reply-To: <87myttq6tx.fsf@mathind.csd.auth.gr> References: <87myttq6tx.fsf@mathind.csd.auth.gr> Message-ID: <20071105142013.GA1312@mapcar.org> On Mon, Nov 05, 2007 at 01:18:02PM +0200, Anakreon Mendis wrote: > What I tried to do is: > imported the Parsec module, hiding the `space`. > Reimplemented the space parser as > space = oneOf [' ', '\t'] > > The parser behaved the same. > > Afterwords, I implemented the whiteSpace parser > as > whiteSpace = skipMany space > > This didn't work either. If you're using the lexing functionality found in Parsec.Token then keep in mind that those combinators will drop whitespace automatically. Shadowing the `space' function doesn't affect any other modules. If you want whitespace sensitivity then you'll have to write or use a separate scanner, as described in the manual. -- -- Matthew Danish -- user: mrd domain: cmu.edu -- OpenPGP public key: C24B6010 on keyring.debian.org From duncan.coutts at worc.ox.ac.uk Mon Nov 5 17:00:38 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Nov 5 16:54:44 2007 Subject: new language extensions Message-ID: <1194300038.26140.205.camel@localhost> All, GHC 6.8 has a lot of new names for language extensions which are not yet listed in Language.Haskell.Extension: UnicodeSyntax PatternSignatures UnliftedFFITypes LiberalTypeSynonyms TypeOperators PArr RecordWildCards RecordPuns DisambiguateRecordFields OverloadedStrings GADTs MonoPatBinds RelaxedPolyRec ExtendedDefaultRules UnboxedTuples DeriveDataTypeable ConstrainedClassMethods These are the extension names you can list in the "extensions:" field in a .cabal file and are also in the {-# LANGUAGE #-} pragma. So I propose we add all of these to the Extension enumeration data type. I'd like to keep this addition separate from the proposal to make Extension a String or newtype String, since I expect even in that case we need a central list of extensions so different implementations can agree on names when they implement the same extensions, or to ensure they pick different names for different extensions. It'd also be nice if we could document all these extensions in the Language.Haskell.Extension module so we can refer to it from the cabal documentation about the extensions field. Duncan From chak at cse.unsw.edu.au Mon Nov 5 17:51:11 2007 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Mon Nov 5 17:48:22 2007 Subject: new language extensions In-Reply-To: <1194300038.26140.205.camel@localhost> References: <1194300038.26140.205.camel@localhost> Message-ID: <0A889174-9E63-4239-A0AE-49D7D9452F95@cse.unsw.edu.au> Duncan Coutts wrote: > GHC 6.8 has a lot of new names for language extensions which are not > yet > listed in Language.Haskell.Extension: [..] > PArr [..] > So I propose we add all of these to the Extension enumeration data > type. I am sure we still want to change this one (maybe into ParallelArrays). The feature isn't ready for prime time yet, which is why nobody has been paying attention to flag names. Anyway, this is just to say, please don't bake this in yet. Manuel From duncan.coutts at worc.ox.ac.uk Mon Nov 5 18:43:26 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Nov 5 18:37:30 2007 Subject: new language extensions In-Reply-To: <0A889174-9E63-4239-A0AE-49D7D9452F95@cse.unsw.edu.au> References: <1194300038.26140.205.camel@localhost> <0A889174-9E63-4239-A0AE-49D7D9452F95@cse.unsw.edu.au> Message-ID: <1194306206.26140.244.camel@localhost> On Tue, 2007-11-06 at 09:51 +1100, Manuel M T Chakravarty wrote: > Duncan Coutts wrote: > > GHC 6.8 has a lot of new names for language extensions which are not > > yet > > listed in Language.Haskell.Extension: > [..] > > PArr > [..] > > So I propose we add all of these to the Extension enumeration data > > type. > > I am sure we still want to change this one (maybe into > ParallelArrays). The feature isn't ready for prime time yet, which is > why nobody has been paying attention to flag names. > > Anyway, this is just to say, please don't bake this in yet. Ok, we can leave that one out for now. Duncan From duncan.coutts at worc.ox.ac.uk Wed Nov 7 16:40:25 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Nov 7 16:34:21 2007 Subject: new language extensions In-Reply-To: <1194300038.26140.205.camel@localhost> References: <1194300038.26140.205.camel@localhost> Message-ID: <1194471625.26140.332.camel@localhost> Last call for objections or comments. We'd like to get this into Language.Haskell.Extension asap so we can include it in the Cabal distributed with ghc-6.8.2. Currently there are packages that compiled fine with Cabal and ghc-6.6.x but not with ghc-6.8.x because we're missing these new more fine-grained language extensions. See http://hackage.haskell.org/trac/hackage/ticket/160 Duncan On Mon, 2007-11-05 at 22:00 +0000, Duncan Coutts wrote: > All, > > GHC 6.8 has a lot of new names for language extensions which are not yet > listed in Language.Haskell.Extension: > > UnicodeSyntax > PatternSignatures > UnliftedFFITypes > LiberalTypeSynonyms > TypeOperators > PArr > RecordWildCards > RecordPuns > DisambiguateRecordFields > OverloadedStrings > GADTs > MonoPatBinds > RelaxedPolyRec > ExtendedDefaultRules > UnboxedTuples > DeriveDataTypeable > ConstrainedClassMethods > > These are the extension names you can list in the "extensions:" field in > a .cabal file and are also in the {-# LANGUAGE #-} pragma. > > So I propose we add all of these to the Extension enumeration data type. > > I'd like to keep this addition separate from the proposal to make > Extension a String or newtype String, since I expect even in that case > we need a central list of extensions so different implementations can > agree on names when they implement the same extensions, or to ensure > they pick different names for different extensions. > > It'd also be nice if we could document all these extensions in the > Language.Haskell.Extension module so we can refer to it from the cabal > documentation about the extensions field. > > Duncan > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries From Malcolm.Wallace at cs.york.ac.uk Thu Nov 8 07:29:24 2007 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Thu Nov 8 07:30:26 2007 Subject: new language extensions In-Reply-To: <1194471625.26140.332.camel@localhost> References: <1194300038.26140.205.camel@localhost> <1194471625.26140.332.camel@localhost> Message-ID: <20071108122924.64bdcd31.Malcolm.Wallace@cs.york.ac.uk> Duncan Coutts wrote: > Last call for objections or comments. Is there a definitive (maybe even formal?) description of the change to the language embodied by each of these extensions? If not, then it is going to be difficult for implementations other than ghc to implement them. > > UnicodeSyntax > > PatternSignatures > > UnliftedFFITypes > > LiberalTypeSynonyms > > TypeOperators > > PArr > > RecordWildCards > > RecordPuns > > DisambiguateRecordFields > > OverloadedStrings > > GADTs > > MonoPatBinds > > RelaxedPolyRec > > ExtendedDefaultRules > > UnboxedTuples > > DeriveDataTypeable > > ConstrainedClassMethods Regards, Malcolm From anakreon at csd.auth.gr Thu Nov 8 07:41:47 2007 From: anakreon at csd.auth.gr (Anakreon Mendis) Date: Thu Nov 8 07:42:13 2007 Subject: Space handling with Parsec References: <87myttq6tx.fsf@mathind.csd.auth.gr> <20071105142013.GA1312@mapcar.org> Message-ID: <87d4ukewok.fsf@mathind.csd.auth.gr> Matthew Danish writes: > On Mon, Nov 05, 2007 at 01:18:02PM +0200, Anakreon Mendis wrote: >> What I tried to do is: >> imported the Parsec module, hiding the `space`. >> Reimplemented the space parser as >> space = oneOf [' ', '\t'] >> >> The parser behaved the same. >> >> Afterwords, I implemented the whiteSpace parser >> as >> whiteSpace = skipMany space >> >> This didn't work either. > > If you're using the lexing functionality found in Parsec.Token then > keep in mind that those combinators will drop whitespace > automatically. Shadowing the `space' function doesn't affect any > other modules. If you want whitespace sensitivity then you'll have to > write or use a separate scanner, as described in the manual. It's a pity. I do not want to implement a scanner when Parsec does the job well (except for newline treatment). I wander if parsec could be extended in two issues. 1:Accept in LanguageDef a parser for line comments instead of a char. In basic comments start either with "'" or "REM". 2:Allow to configure in LanguageDef the treatment of newline and whitespace in general. As a workaround, before the input is delivered to the parser, the newline is changed into $\n and it works. From duncan.coutts at worc.ox.ac.uk Thu Nov 8 08:31:46 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Nov 8 08:25:41 2007 Subject: new language extensions In-Reply-To: <20071108122924.64bdcd31.Malcolm.Wallace@cs.york.ac.uk> References: <1194300038.26140.205.camel@localhost> <1194471625.26140.332.camel@localhost> <20071108122924.64bdcd31.Malcolm.Wallace@cs.york.ac.uk> Message-ID: <1194528706.26140.389.camel@localhost> On Thu, 2007-11-08 at 12:29 +0000, Malcolm Wallace wrote: > Duncan Coutts wrote: > > > Last call for objections or comments. > > Is there a definitive (maybe even formal?) description of the change to > the language embodied by each of these extensions? If not, then it is > going to be difficult for implementations other than ghc to implement > them. Most, but not all are documented in the GHC users guide. It would not be unreasonable to ask for a proper description of the remaining ones. http://haskell.org/ghc/docs/latest/html/users_guide/ghc-language-features.html Unfortunately the user guide does not make it entirely clear what language extension name to use in each case. http://www.haskell.org/ghc/docs/latest/html/users_guide/flag-reference.html#id3167937 Personally I would quite like to include documentation and a little example for each one in the Language.Haskell.Extension haddock docs. That would be a useful reference for users trying to figure out which extension it is they need to enable. Duncan From igloo at earth.li Thu Nov 8 09:27:55 2007 From: igloo at earth.li (Ian Lynagh) Date: Thu Nov 8 09:24:52 2007 Subject: new language extensions In-Reply-To: <1194471625.26140.332.camel@localhost> References: <1194300038.26140.205.camel@localhost> <1194471625.26140.332.camel@localhost> Message-ID: <20071108142755.GA10990@matrix.chaos.earth.li> On Wed, Nov 07, 2007 at 09:40:25PM +0000, Duncan Coutts wrote: > Last call for objections or comments. > > We'd like to get this into Language.Haskell.Extension asap so we can > include it in the Cabal distributed with ghc-6.8.2. Currently there are > packages that compiled fine with Cabal and ghc-6.6.x but not with > ghc-6.8.x because we're missing these new more fine-grained language > extensions. > > See http://hackage.haskell.org/trac/hackage/ticket/160 I'd much rather see http://hackage.haskell.org/trac/hackage/ticket/147 fixed. Then Cabal would work with future GHCs, with new extensions as yet undreamt of, as well. This would provide the mechanism we need; the policy, i.e. what the extension names mean, should be defined somewhere outside of Cabal. (you would still need to add the new extension names defined in 6.8.1 to the legacy mapping for 6.6 flags). Thanks Ian From duncan.coutts at worc.ox.ac.uk Thu Nov 8 17:42:29 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Nov 8 17:36:22 2007 Subject: new language extensions In-Reply-To: <20071108142755.GA10990@matrix.chaos.earth.li> References: <1194300038.26140.205.camel@localhost> <1194471625.26140.332.camel@localhost> <20071108142755.GA10990@matrix.chaos.earth.li> Message-ID: <1194561749.26140.402.camel@localhost> On Thu, 2007-11-08 at 14:27 +0000, Ian Lynagh wrote: > On Wed, Nov 07, 2007 at 09:40:25PM +0000, Duncan Coutts wrote: > > Last call for objections or comments. > > > > We'd like to get this into Language.Haskell.Extension asap so we can > > include it in the Cabal distributed with ghc-6.8.2. Currently there are > > packages that compiled fine with Cabal and ghc-6.6.x but not with > > ghc-6.8.x because we're missing these new more fine-grained language > > extensions. > > > > See http://hackage.haskell.org/trac/hackage/ticket/160 > > I'd much rather see http://hackage.haskell.org/trac/hackage/ticket/147 > fixed. I'd prefer to see this proposal debated properly on this list first. Also, do you think that is realistic in the time frame for 6.8.2? Adding new entries is easy. > Then Cabal would work with future GHCs, with new extensions as > yet undreamt of, as well. > This would provide the mechanism we need; the policy, i.e. what the > extension names mean, should be defined somewhere outside of Cabal. Ok, but where should they be defined? I'm not sure the right place is in GHC. Language extensions (names and meanings) are something that needs to be negotiated within the community and especially between developers of different Haskell implementations. So I think keeping the list in Language.Haskell.Extension is not such a bad idea. Any Haskell implementation that wants a new common extension can get it included in that module in time for a release. > (you would still need to add the new extension names defined in 6.8.1 to > the legacy mapping for 6.6 flags). Yep, I'll do that. Duncan From mailing_list at istitutocolli.org Fri Nov 9 06:57:12 2007 From: mailing_list at istitutocolli.org (Andrea Rossato) Date: Fri Nov 9 06:54:52 2007 Subject: -- Cabal-1.2 and Haddock behaviour Message-ID: <20071109115712.GA26527@laptop.nowhere.net> Hi, I don't know whether this is going to be a question of just a way to express my deep frustration: I'm trying to maintain a Haskell tool chain for the Slackware GNU/Linux distribution and I'm now trying to update it to ghc-6.8.1. Packaging a Haskell library/application for a Linux distribution usually means writing a script. For Slackware we use SlackBuilds, shell scripts that perform all the needed steps for compiling and installing a package with all the needed documentation. I'm not going to stress the importance of software documentation. Now, as far as I understand, in the transition from Cabal-1.1 to Cabal-1.2, for which I want to express all my gratitude to the Cabal team since it seems to me a huge step forward in the right direction, a small and undocumented change happened: documentation used to be installed in "$PREFIX/share/packagename-version/doc/html" now, instead, it is installed in "$PREFIX/share/doc/packagename-version/html" Almost the same, you may say. Probably someone thought it was cooler this way. Maybe someone else, in the future, may think differently and change it once again. It doesn't matter if a shell script expects to find the documentation somewhere. It doesn't matter if tens, or thousands, or even millions of shell scripts will be broken. We are work in progress, after all. Nothing is required to be stable, and so on and so forth... I think I'm going to give up, actually. If every .x update requires all that effort on my side for packaging the software I'm compiling for myself in such a way that others may find useful too, well, I'm not that committed to sharing and all that kind of stuff. Or, at least, I prefer to use my limited time for having fun as everyone seems to do in the Haskell community: just write that wonderfully concise and nice code! Haskell is self documenting, if you know what it means, if you are an Haskeller. And I'm coming to think I am an haskeller, after all. Why should I care about the other Slackware users? I know Cabal quite well and it is very powerful to enable me to managing all my libraries and applications, and everything almost effortlessly... You did a great job! Thanks Andrea From igloo at earth.li Fri Nov 9 09:03:05 2007 From: igloo at earth.li (Ian Lynagh) Date: Fri Nov 9 08:59:59 2007 Subject: new language extensions In-Reply-To: <1194561749.26140.402.camel@localhost> References: <1194300038.26140.205.camel@localhost> <1194471625.26140.332.camel@localhost> <20071108142755.GA10990@matrix.chaos.earth.li> <1194561749.26140.402.camel@localhost> Message-ID: <20071109140305.GA25315@matrix.chaos.earth.li> On Thu, Nov 08, 2007 at 10:42:29PM +0000, Duncan Coutts wrote: > On Thu, 2007-11-08 at 14:27 +0000, Ian Lynagh wrote: > > On Wed, Nov 07, 2007 at 09:40:25PM +0000, Duncan Coutts wrote: > > > Last call for objections or comments. > > > > > > We'd like to get this into Language.Haskell.Extension asap so we can > > > include it in the Cabal distributed with ghc-6.8.2. Currently there are > > > packages that compiled fine with Cabal and ghc-6.6.x but not with > > > ghc-6.8.x because we're missing these new more fine-grained language > > > extensions. > > > > > > See http://hackage.haskell.org/trac/hackage/ticket/160 > > > > I'd much rather see http://hackage.haskell.org/trac/hackage/ticket/147 > > fixed. > > I'd prefer to see this proposal debated properly on this list first. > > Also, do you think that is realistic in the time frame for 6.8.2? Yes, you just change the type declaration and fix the compilation errors that result. I've done it before and I don't remember running into any problems. > > Then Cabal would work with future GHCs, with new extensions as > > yet undreamt of, as well. > > > This would provide the mechanism we need; the policy, i.e. what the > > extension names mean, should be defined somewhere outside of Cabal. > > Ok, but where should they be defined? Stable extensions (e.g. MultiParamTypeClasses) should be described somewhere central, perhaps the haskell.org wiki. New exciting stuff that'll probably have completely different semantics tomorrow should be described in the GHC manual. Thanks Ian From jon.fairbairn at cl.cam.ac.uk Fri Nov 9 12:37:26 2007 From: jon.fairbairn at cl.cam.ac.uk (Jon Fairbairn) Date: Fri Nov 9 12:34:36 2007 Subject: Bug/infelicity with System.Locale.iso8601DateFormat Message-ID: According to (and other random sources), the iso format for date+time in one field is YYYY-MM-DDThh:mm:ssTZD (eg 1997-07-16T19:20:30+01:00), ie no spaces around the "T" but iso8601DateFormat outputs a space after the day if the timeFmt is not Nothing, so formatTime System.Locale.defaultTimeLocale (System.Locale.iso8601DateFormat (Just "T%H:%M:%SZ")) (UTCTime (fromGregorian 2007 10 20) 26540) yeilds "2007-10-20 T07:22:20Z". I reckon this is a bug, but at the very least it's not a good design. Please can we change Just fmt -> ' ' : fmt to Just fmt -> fmt ? if someone wants a space, they can put it in the string, but it's a pain to take it out when you want the one field format with a T there. -- J?n Fairbairn Jon.Fairbairn@cl.cam.ac.uk From duncan.coutts at worc.ox.ac.uk Fri Nov 9 13:58:58 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Nov 9 13:52:51 2007 Subject: -- Cabal-1.2 and Haddock behaviour In-Reply-To: <20071109115712.GA26527@laptop.nowhere.net> References: <20071109115712.GA26527@laptop.nowhere.net> Message-ID: <1194634738.26140.451.camel@localhost> On Fri, 2007-11-09 at 12:57 +0100, Andrea Rossato wrote: > Now, as far as I understand, in the transition from Cabal-1.1 to > Cabal-1.2, for which I want to express all my gratitude to the Cabal > team since it seems to me a huge step forward in the right direction, > a small and undocumented change happened: documentation used to be > installed in > "$PREFIX/share/packagename-version/doc/html" > now, instead, it is installed in > "$PREFIX/share/doc/packagename-version/html" Yes. > Almost the same, you may say. Probably someone thought it was cooler > this way. Maybe someone else, in the future, may think differently and > change it once again. At the same time we made it configurable: runghc Setup.hs configure --docdir= there's also --htmldir= It's documented in the Cabal users guide: http://www.haskell.org/ghc/docs/latest/html/Cabal/builders.html#setup-configure-paths and in the configure --help output. You're quite right that we missed it out of the Cabal changelog. Sorry about that. Please don't give up on packaging for Slackware, packaging is so important. I'm sorry that stuff changes. There are usually good reasons for these changes but I do accept that we need to consider transitions more and document changes. Duncan From mailing_list at istitutocolli.org Sat Nov 10 13:46:22 2007 From: mailing_list at istitutocolli.org (Andrea Rossato) Date: Sat Nov 10 13:43:53 2007 Subject: -- Re: -- Cabal-1.2 and Haddock behaviour In-Reply-To: <1194634738.26140.451.camel@localhost> References: <20071109115712.GA26527@laptop.nowhere.net> <1194634738.26140.451.camel@localhost> Message-ID: <20071110184622.GG26527@laptop.nowhere.net> On Fri, Nov 09, 2007 at 06:58:58PM +0000, Duncan Coutts wrote: > Please don't give up on packaging for Slackware, packaging is so > important. I'm sorry that stuff changes. There are usually good reasons > for these changes but I do accept that we need to consider transitions > more and document changes. No, I will not give up... And I also understand that the change was no arbitrary, but done in order to comply with the standard way of dealing with documentation in the linux file system. And indeed my build scripts result now simpler than before. Still, due to some issues with ghc docs generation, I found out about this problem after a couple of days spent in dealing with ghc, and only after all the creation of the build scripts for the last library split had been done... That can be frustrating, believe me: writing shell scripts is not what I like most! I hope tomorrow I'll be able to find the time to write a small announcement for the haskell-cafe ML, but the Slackware packages are now available here: http://gorgias.mine.nu/slack/haskell/ At the present time ghc and ghc-extralibs are available. More will be added later (as soon as compilable with the new tool chain). The documentation is decent I would say. Every package also install a hoogle database. Those databases are collected together in /var/spool/hoogle/hoogle. I have this alias my .bashrc: alias hoogle="hoogle -l /var/spool/hoogle/hoogle" For every package there is a corresponding build (shell) script. These scrips are collected in a darcs repository available here: http://gorgias.mine.nu/repos/haskell-SlackBuild/ (I'm thinking about writing a small haskell application to manage a direct interaction between slackware and hackage, with an automated SlackBuild script generation, which is probably going to be less resource consuming in the long run, and more enjoyable in the short one ;) Finally, OpenLA and ALUT are not present since the relative libraries are missing from a standard Slackware install. ObjectIO is not present too. X11 has been updated to 1.3.0 since I will be releasing xmobar-0.8 (a status bar for XMonad), and it requires that version with the X11-extras merge. Sorry for writing more to express my frustration than for a real need. Anyhow, when I said you did a great job I was not ironic or kidding. I really think it. Cheers, Andrea From igloo at earth.li Sat Nov 10 18:01:25 2007 From: igloo at earth.li (Ian Lynagh) Date: Sat Nov 10 17:58:13 2007 Subject: Data.IntSet bug Message-ID: <20071110230125.GA1029@matrix.chaos.earth.li> Hi all, Can someone familiar with Data.IntSet please look into http://hackage.haskell.org/trac/ghc/ticket/1762 wrong result of isProperSubsetOf IntSet.isProperSubsetOf (IntSet.fromList [2,3]) (IntSet.fromList [1,2,3]) is evaluated to False, but should be True. Thanks Ian From dbenbenn at gmail.com Sun Nov 11 01:58:49 2007 From: dbenbenn at gmail.com (David Benbennick) Date: Sun Nov 11 01:55:37 2007 Subject: Data.IntSet bug In-Reply-To: <20071110230125.GA1029@matrix.chaos.earth.li> References: <20071110230125.GA1029@matrix.chaos.earth.li> Message-ID: I think I have a fix for this bug. I'll use darcs to send a patch, as soon as I'm done checking out the repo. Here's the change that I think fixes the problem: subsetCmp t1@(Bin p1 m1 l1 r1) t2@(Bin p2 m2 l2 r2) | shorter m1 m2 = GT - | shorter m2 m1 = subsetCmpLt + | shorter m2 m1 = case subsetCmpLt of + GT -> GT + _ -> LT | p1 == p2 = subsetCmpEq | otherwise = GT -- disjoint I also intend to send a QuickCheck that catches this bug, and some comments to the IntSet sourcecode. From duncan.coutts at worc.ox.ac.uk Sun Nov 11 08:13:08 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Nov 11 08:07:01 2007 Subject: -- Re: -- Cabal-1.2 and Haddock behaviour In-Reply-To: <20071110184622.GG26527@laptop.nowhere.net> References: <20071109115712.GA26527@laptop.nowhere.net> <1194634738.26140.451.camel@localhost> <20071110184622.GG26527@laptop.nowhere.net> Message-ID: <1194786789.26140.525.camel@localhost> On Sat, 2007-11-10 at 19:46 +0100, Andrea Rossato wrote: > On Fri, Nov 09, 2007 at 06:58:58PM +0000, Duncan Coutts wrote: > > Please don't give up on packaging for Slackware, packaging is so > > important. I'm sorry that stuff changes. There are usually good reasons > > for these changes but I do accept that we need to consider transitions > > more and document changes. > > No, I will not give up... Great, I'm glad to hear it. :-) > And I also understand that the change was no > arbitrary, but done in order to comply with the standard way of > dealing with documentation in the linux file system. Yes. The default was wrong and different distro want to put them in different places anyway so it has to be configurable. > And indeed my > build scripts result now simpler than before. Still, due to some > issues with ghc docs generation, I found out about this problem after > a couple of days spent in dealing with ghc, and only after all the > creation of the build scripts for the last library split had been > done... That can be frustrating, believe me: writing shell scripts is > not what I like most! Yes, we've been having similar issues with doc generation in ghc-6.8.1. There are several bugs open about it. They're not going into a versioned ghc doc directory by default and the inter-package links are not getting created. We hope this will be fixed in 6.8.2. > I hope tomorrow I'll be able to find the time to write a small > announcement for the haskell-cafe ML, but the Slackware packages are > now available here: > http://gorgias.mine.nu/slack/haskell/ > > At the present time ghc and ghc-extralibs are available. More will be > added later (as soon as compilable with the new tool chain). The > documentation is decent I would say. Great. > Every package also install a hoogle database. Oh that's a good idea. We should do that in gentoo too. > Those databases are collected together in /var/spool/hoogle/hoogle. > > I have this alias my .bashrc: > alias hoogle="hoogle -l /var/spool/hoogle/hoogle" > > For every package there is a corresponding build (shell) script. These > scrips are collected in a darcs repository available here: > http://gorgias.mine.nu/repos/haskell-SlackBuild/ > > (I'm thinking about writing a small haskell application to manage a > direct interaction between slackware and hackage, with an automated > SlackBuild script generation, which is probably going to be less > resource consuming in the long run, and more enjoyable in the short > one ;) Yes, that's what we do for Gentoo. We have a program that generates ebuild scripts directly from the hackage index. We've got about 150 hackage packages via this route. You might like to look into adapting our code: darcs get --partial http://haskell.org/~gentoo/hackport/ It's not been fully updated to deal with the new features in Cabal-1.2 yet. > Finally, OpenLA and ALUT are not present since the relative libraries > are missing from a standard Slackware install. ObjectIO is not present > too. X11 has been updated to 1.3.0 since I will be releasing > xmobar-0.8 (a status bar for XMonad), and it requires that version > with the X11-extras merge. Sounds sensible. > Sorry for writing more to express my frustration than for a real need. > Anyhow, when I said you did a great job I was not ironic or kidding. I > really think it. No problem. Sorry for the upheavals. Duncan From alfonso.acosta at gmail.com Wed Nov 14 08:25:53 2007 From: alfonso.acosta at gmail.com (Alfonso Acosta) Date: Wed Nov 14 08:22:31 2007 Subject: Adding a DSEL library to the hierarchy Message-ID: <6a7c66fc0711140525v281fd2a1ma4cfac1a0b249819@mail.gmail.com> Hi, I'm expecting to publicly release the library of a Haskell-embedded Domain Specific Language, ForSyDe [1], in a few weeks time. However, I'm not still sure of what would be the most appropriate place in the hierarchy where to "plug" the library. To provide a little background, ForSyDe is aimed at modelling systems, and its implementation shares many concepts with Lava [2], the successful Haskell-embedded HDL. So the my question could be rephrased as "If you had to adapt the Lava library to the namespace extension, where would you put it?" My options are: 1) Use Language.ForSyDe But I don't know if embedded-languages really fit here since they don't explicitly "operate on source code" for the end-user (i.e. they don't transform or make computations over the representation of a language but rather provide the language itself) 2) Use the Org root name. However, we don't still have a domain, don't really think we'll have it any time soon, and besides, although the "Org" root name is proposed in the namespace extension, it doesn't really seem to be used in practice (tell me if I'm wrong). 3) Use our own root name: "ForSyDe". That's how it's currently implemented, but I guess that one of the purposes of having a namespace extension was precisely to avoid people adding their own root names. I would really appreciate any advice regarding this matter. Thanks in advance, Alfonso Acosta [1] http://www.imit.kth.se/info/FOFU/ForSyDe/ [2] http://www.cs.chalmers.se/~koen/Lava/ From ketil+haskell at ii.uib.no Wed Nov 14 08:45:23 2007 From: ketil+haskell at ii.uib.no (Ketil Malde) Date: Wed Nov 14 08:42:10 2007 Subject: Adding a DSEL library to the hierarchy In-Reply-To: <6a7c66fc0711140525v281fd2a1ma4cfac1a0b249819@mail.gmail.com> (Alfonso Acosta's message of "Wed\, 14 Nov 2007 14\:25\:53 +0100") References: <6a7c66fc0711140525v281fd2a1ma4cfac1a0b249819@mail.gmail.com> Message-ID: <873av97xfw.fsf@nmd9999.imr.no> "Alfonso Acosta" writes: > My options are: > 3) Use our own root name: "ForSyDe". That's how it's currently > implemented, but I guess that one of the purposes of having a > namespace extension was precisely to avoid people adding their own > root names. It's what I do, too. Frankly, I don't see any problem with this, and if I had a penny for every time I had to type D a t a . B y t e S t r i n g . L a z y . C h a r 8 or T e x t . P a r s e r C o m b i n a t o r s . P a r s e c in ghci just to disambiguate some operation... -k -- If I haven't seen further, it is by standing in the footprints of giants From bulat.ziganshin at gmail.com Wed Nov 14 08:42:18 2007 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Wed Nov 14 08:43:37 2007 Subject: Adding a DSEL library to the hierarchy In-Reply-To: <6a7c66fc0711140525v281fd2a1ma4cfac1a0b249819@mail.gmail.com> References: <6a7c66fc0711140525v281fd2a1ma4cfac1a0b249819@mail.gmail.com> Message-ID: <146353353.20071114164218@gmail.com> Hello Alfonso, Wednesday, November 14, 2007, 4:25:53 PM, you wrote: > 1) Use Language.ForSyDe for me seems most appropriate, unless you will invent some other root for DSELs. btw, isn't it better to rename lib into just Forsyde? Mixed-case makes reading a bit difficult -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From rturk at science.uva.nl Wed Nov 14 09:22:50 2007 From: rturk at science.uva.nl (Remi Turk) Date: Wed Nov 14 09:15:57 2007 Subject: Adding a DSEL library to the hierarchy In-Reply-To: <873av97xfw.fsf@nmd9999.imr.no> References: <6a7c66fc0711140525v281fd2a1ma4cfac1a0b249819@mail.gmail.com> <873av97xfw.fsf@nmd9999.imr.no> Message-ID: <20071114142249.GA3009@krikkit.lan> On Wed, Nov 14, 2007 at 02:45:23PM +0100, Ketil Malde wrote: > "Alfonso Acosta" writes: > > > My options are: > > 3) Use our own root name: "ForSyDe". That's how it's currently > > implemented, but I guess that one of the purposes of having a > > namespace extension was precisely to avoid people adding their own > > root names. > > It's what I do, too. Frankly, I don't see any problem with this, and > if I had a penny for every time I had to type D a t a . B y t e S t r > i n g . L a z y . C h a r 8 or T e x t . P a r s e r C o m b i n > a t o r s . P a r s e c in ghci just to disambiguate some > operation... Does that mean I'm not the only one longing for :m +Data.ByteString.Lazy.Char8 as B In that case I should probably submit a feature request for it. Greetings, Remi > -k > -- > If I haven't seen further, it is by standing in the footprints of giants > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries > From lemming at henning-thielemann.de Wed Nov 14 09:30:25 2007 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed Nov 14 09:27:00 2007 Subject: Adding a DSEL library to the hierarchy In-Reply-To: <20071114142249.GA3009@krikkit.lan> References: <6a7c66fc0711140525v281fd2a1ma4cfac1a0b249819@mail.gmail.com> <873av97xfw.fsf@nmd9999.imr.no> <20071114142249.GA3009@krikkit.lan> Message-ID: On Wed, 14 Nov 2007, Remi Turk wrote: > On Wed, Nov 14, 2007 at 02:45:23PM +0100, Ketil Malde wrote: > > > It's what I do, too. Frankly, I don't see any problem with this, and > > if I had a penny for every time I had to type D a t a . B y t e S t r > > i n g . L a z y . C h a r 8 or T e x t . P a r s e r C o m b i n > > a t o r s . P a r s e c in ghci just to disambiguate some > > operation... > Does that mean I'm not the only one longing for > > :m +Data.ByteString.Lazy.Char8 as B > > In that case I should probably submit a feature request for it. If I need these module renamings frequently I usually write a module, which imports the modules with renaming and load that into GHCi. From johan.tibell at gmail.com Wed Nov 14 09:32:27 2007 From: johan.tibell at gmail.com (Johan Tibell) Date: Wed Nov 14 09:29:09 2007 Subject: Adding a DSEL library to the hierarchy In-Reply-To: <20071114142249.GA3009@krikkit.lan> References: <6a7c66fc0711140525v281fd2a1ma4cfac1a0b249819@mail.gmail.com> <873av97xfw.fsf@nmd9999.imr.no> <20071114142249.GA3009@krikkit.lan> Message-ID: <90889fe70711140632p6660def3w1e5269484095ec11@mail.gmail.com> > > It's what I do, too. Frankly, I don't see any problem with this, and > > if I had a penny for every time I had to type D a t a . B y t e S t r > > i n g . L a z y . C h a r 8 or T e x t . P a r s e r C o m b i n > > a t o r s . P a r s e c in ghci just to disambiguate some > > operation... > Does that mean I'm not the only one longing for > > :m +Data.ByteString.Lazy.Char8 as B > > In that case I should probably submit a feature request for it. +1 Importing modules in ghci is really annoying for several reasons: - Above mentioned. - Loose my imports on failed load (maybe we could keep the current bindings, imports until the whole load is finished?) - Super long prompt. Cheers, Johan From dons at galois.com Wed Nov 14 16:48:53 2007 From: dons at galois.com (Don Stewart) Date: Wed Nov 14 16:45:32 2007 Subject: Adding a DSEL library to the hierarchy In-Reply-To: <90889fe70711140632p6660def3w1e5269484095ec11@mail.gmail.com> References: <6a7c66fc0711140525v281fd2a1ma4cfac1a0b249819@mail.gmail.com> <873av97xfw.fsf@nmd9999.imr.no> <20071114142249.GA3009@krikkit.lan> <90889fe70711140632p6660def3w1e5269484095ec11@mail.gmail.com> Message-ID: <20071114214853.GC32762@scytale.galois.com> johan.tibell: > > > It's what I do, too. Frankly, I don't see any problem with this, and > > > if I had a penny for every time I had to type D a t a . B y t e S t r > > > i n g . L a z y . C h a r 8 or T e x t . P a r s e r C o m b i n > > > a t o r s . P a r s e c in ghci just to disambiguate some > > > operation... > > Does that mean I'm not the only one longing for > > > > :m +Data.ByteString.Lazy.Char8 as B > > > > In that case I should probably submit a feature request for it. > > +1 > > Importing modules in ghci is really annoying for several reasons: > > - Above mentioned. > - Loose my imports on failed load (maybe we could keep the current > bindings, imports until the whole load is finished?) > - Super long prompt. +1 From alfonso.acosta at gmail.com Wed Nov 14 18:32:44 2007 From: alfonso.acosta at gmail.com (Alfonso Acosta) Date: Wed Nov 14 18:29:21 2007 Subject: Adding a DSEL library to the hierarchy In-Reply-To: <146353353.20071114164218@gmail.com> References: <6a7c66fc0711140525v281fd2a1ma4cfac1a0b249819@mail.gmail.com> <146353353.20071114164218@gmail.com> Message-ID: <6a7c66fc0711141532o169d11a8rd952a19b378d60e0@mail.gmail.com> Hi Bulat, On Nov 14, 2007 2:42 PM, Bulat Ziganshin wrote: > > 1) Use Language.ForSyDe > > for me seems most appropriate, unless you will invent some other root > for DSELs. Well, I Don't think there is such a demand for a DSEL root, so maybe Language would be appropiate. On the other hand, as Katil mentioned, ForSyDe is simply shorter. Are there any strong opinions against creating a new ForSyDe root name? > btw, isn't it better to rename lib into just Forsyde? > Mixed-case makes reading a bit difficult I guess I'll have to ask the original designers of ForSyDe. ForSyDe's name falls into the case of LaTeX so they might want to keep it unmodified, and besides, they are the ones paying for my work ;). From conal at conal.net Wed Nov 14 20:43:48 2007 From: conal at conal.net (Conal Elliott) Date: Wed Nov 14 20:40:24 2007 Subject: Adding a DSEL library to the hierarchy In-Reply-To: <6a7c66fc0711141532o169d11a8rd952a19b378d60e0@mail.gmail.com> References: <6a7c66fc0711140525v281fd2a1ma4cfac1a0b249819@mail.gmail.com> <146353353.20071114164218@gmail.com> <6a7c66fc0711141532o169d11a8rd952a19b378d60e0@mail.gmail.com> Message-ID: > Are there any strong opinions against creating a new ForSyDe root name? I'd prefer more discussion about when to make new root names, when to wedge things into the existing hierarchy, and when to create new root names, under which to add projects (e.g. DSEL). I often have trouble figuring out where to put things in the hierarchy. For instance, type classes cut across classifications like Data vs Control. That cross-cutting is what makes them so powerful. For TV, I made a new "Interface" root name. It overlaps with Graphics.UI but is more general. For DeepArrow, I used Control.Arrow.DeepArrow, although it's not about "control" (just as monads or arrows are not about control). I have doubts about whether module hierarchy is workable in general. Maybe we could come up with something better. - Conal On Nov 14, 2007 3:32 PM, Alfonso Acosta wrote: > Hi Bulat, > > On Nov 14, 2007 2:42 PM, Bulat Ziganshin > wrote: > > > 1) Use Language.ForSyDe > > > > for me seems most appropriate, unless you will invent some other root > > for DSELs. > > Well, I Don't think there is such a demand for a DSEL root, so maybe > Language would be appropiate. > > On the other hand, as Katil mentioned, ForSyDe is simply shorter. > > Are there any strong opinions against creating a new ForSyDe root name? > > > btw, isn't it better to rename lib into just Forsyde? > > Mixed-case makes reading a bit difficult > > I guess I'll have to ask the original designers of ForSyDe. ForSyDe's > name falls into the case of LaTeX so they might want to keep it > unmodified, and besides, they are the ones paying for my work ;). > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20071114/e38f58d3/attachment.htm From dave at zednenem.com Thu Nov 15 00:13:59 2007 From: dave at zednenem.com (David Menendez) Date: Thu Nov 15 00:10:36 2007 Subject: Adding a DSEL library to the hierarchy In-Reply-To: References: <6a7c66fc0711140525v281fd2a1ma4cfac1a0b249819@mail.gmail.com> <146353353.20071114164218@gmail.com> <6a7c66fc0711141532o169d11a8rd952a19b378d60e0@mail.gmail.com> Message-ID: <49a77b7a0711142113n24fdf48doe6cca1655a5bf00b@mail.gmail.com> On 11/14/07, Conal Elliott wrote: > I'd prefer more discussion about when to make new root names, when to wedge > things into the existing hierarchy, and when to create new root names, under > which to add projects ( e.g. DSEL). The easiest thing to do is just use the package name as the root. Putting modules close together in the hierarchy doesn't have any significance in Haskell or (as far as I can tell) Cabal, so there's no advantage to putting things in the existing structure. -- Dave Menendez From ketil+haskell at ii.uib.no Thu Nov 15 03:02:20 2007 From: ketil+haskell at ii.uib.no (Ketil Malde) Date: Thu Nov 15 02:59:05 2007 Subject: Adding a DSEL library to the hierarchy In-Reply-To: (Conal Elliott's message of "Wed\, 14 Nov 2007 17\:43\:48 -0800") References: <6a7c66fc0711140525v281fd2a1ma4cfac1a0b249819@mail.gmail.com> <146353353.20071114164218@gmail.com> <6a7c66fc0711141532o169d11a8rd952a19b378d60e0@mail.gmail.com> Message-ID: <878x50c4xf.fsf@nmd9999.imr.no> "Conal Elliott" writes: > I'd prefer more discussion about when to make new root names, when to wedge > things into the existing hierarchy, and when to create new root names, under > which to add projects ( e.g. DSEL). I belive the primary - and perhaps only justifiable - purpose of the hierarchy is to avoid namespace collisions. A new root is a good choice when you have a library that has a distinct name (like "ForSyDe", or, for that matter "Parsec"), and includes cross-hierarchy functionality. > I have doubts about whether module hierarchy is workable in general. Maybe we > could come up with something better. Here's an essay about categorizing stuff: http://www.shirky.com/writings/ontology_overrated.html The short version is that any hierarchy is going to have problems, and nobody (except in the physical world) is browsing a hierarchy anyway, they just enter terms in search fields. So a wide/shallow hierarchy incurs no additional cost, and reduces at least some of the problems compared to a narrow/deep one. -k -- If I haven't seen further, it is by standing in the footprints of giants From simonpj at microsoft.com Thu Nov 15 04:03:16 2007 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Thu Nov 15 03:59:54 2007 Subject: Adding a DSEL library to the hierarchy In-Reply-To: <20071114214853.GC32762@scytale.galois.com> References: <6a7c66fc0711140525v281fd2a1ma4cfac1a0b249819@mail.gmail.com> <873av97xfw.fsf@nmd9999.imr.no> <20071114142249.GA3009@krikkit.lan> <90889fe70711140632p6660def3w1e5269484095ec11@mail.gmail.com> <20071114214853.GC32762@scytale.galois.com> Message-ID: | > > Does that mean I'm not the only one longing for | > > | > > :m +Data.ByteString.Lazy.Char8 as B | > > | > > In that case I should probably submit a feature request for it. | > | > +1 | > | > Importing modules in ghci is really annoying for several reasons: | > | > - Above mentioned. | > - Loose my imports on failed load (maybe we could keep the current | > bindings, imports until the whole load is finished?) | > - Super long prompt. Add a feature request by all means! Simon From johan.tibell at gmail.com Thu Nov 15 04:42:51 2007 From: johan.tibell at gmail.com (Johan Tibell) Date: Thu Nov 15 04:39:26 2007 Subject: Adding a DSEL library to the hierarchy In-Reply-To: References: <6a7c66fc0711140525v281fd2a1ma4cfac1a0b249819@mail.gmail.com> <873av97xfw.fsf@nmd9999.imr.no> <20071114142249.GA3009@krikkit.lan> <90889fe70711140632p6660def3w1e5269484095ec11@mail.gmail.com> <20071114214853.GC32762@scytale.galois.com> Message-ID: <90889fe70711150142w38f9959t5434776fcdfc847@mail.gmail.com> On Nov 15, 2007 10:03 AM, Simon Peyton-Jones wrote: > | > > Does that mean I'm not the only one longing for > | > > > | > > :m +Data.ByteString.Lazy.Char8 as B > | > > > | > > In that case I should probably submit a feature request for it. > | > > | > +1 > | > > | > Importing modules in ghci is really annoying for several reasons: > | > > | > - Above mentioned. http://hackage.haskell.org/trac/ghc/ticket/1895 > | > - Loose my imports on failed load (maybe we could keep the current > | > bindings, imports until the whole load is finished?) http://hackage.haskell.org/trac/ghc/ticket/1896 > | > - Super long prompt. Possible to set in .ghci > Add a feature request by all means! > > Simon > From igloo at earth.li Sat Nov 17 09:02:44 2007 From: igloo at earth.li (Ian Lynagh) Date: Sat Nov 17 08:59:12 2007 Subject: PROPOSAL: Restrict the type of (^), (^^), and add genericPower, genericPower' Message-ID: <20071117140244.GA31275@matrix.chaos.earth.li> Hi all, This got a warm reception when I mentioned it in http://www.haskell.org/pipermail/haskell-cafe/2007-June/027557.html so I'm formally proposing it now. It's trac #1902: http://hackage.haskell.org/trac/ghc/ticket/1902 Note that this is a divergence from Haskell 98 (but the libraries already have a handful of small divergences, and Haskell' is just around the corner...). In my opinion, (^) has the wrong type. Just as we have, for example, (!!) :: [a] -> Int -> a genericIndex :: (Integral b) => [a] -> b -> a we should also have (^) :: (Num a) => a -> Int -> a genericPower :: (Num a, Integral b) => a -> b -> a (or some other function name). The same goes for (^^) (genericPower'). In my experience this would remove 99.9% of all defaulting (mostly where you write things like x^12 and 8^12), which means it's easier to get -Wall clean without having to put :: Int annotations everywhere. The impact to GHC's bootlibs and extralibs is minimal. In most cases we have things like 2^15, where Int is clearly fine, although it happens to be defaulted to Integer currently. In Data.Complex we have 2 cases of e^(2::Int) which can now be beautified. There are several cases where the type is inferred to be Int anyway. There are 3 files where we really do have an Integer, and it does matter. They are all for parsing numbers of the form 18e43, in base/Text/Read/Lex.hs, parsec/Text/ParserCombinators/Parsec/Token.hs and haskell-src/Language/Haskell/Lexer.hs. Initial deadline: 1 Dec 2007. Thanks Ian From igloo at earth.li Sat Nov 17 09:13:18 2007 From: igloo at earth.li (Ian Lynagh) Date: Sat Nov 17 09:09:46 2007 Subject: META-PROPOSAL: Documentation should be required to say when exports were introduced Message-ID: <20071117141318.GA31429@matrix.chaos.earth.li> Hi all, This is trac #1903: http://hackage.haskell.org/trac/ghc/ticket/1903 One of the nice things about, for example, PHP is that if you look at the documentation for one of its functions, e.g. http://www.php.net/manual/en/function.file-get-contents.php it tells you that file_get_contents is available in PHP >= 4.3.0. I propose that all exports in Haskell libraries should be required to have such a thing in their haddock documentation. For the current code we could either give the current versions as the date of introduction, or do some digging and put precise data in. Initial deadline: 1 December 2007. Thanks Ian From lemming at henning-thielemann.de Sat Nov 17 10:09:20 2007 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sat Nov 17 10:05:46 2007 Subject: PROPOSAL: Restrict the type of (^), (^^), and add genericPower, genericPower' In-Reply-To: <20071117140244.GA31275@matrix.chaos.earth.li> References: <20071117140244.GA31275@matrix.chaos.earth.li> Message-ID: On Sat, 17 Nov 2007, Ian Lynagh wrote: > Hi all, > > This got a warm reception when I mentioned it in > http://www.haskell.org/pipermail/haskell-cafe/2007-June/027557.html > so I'm formally proposing it now. It's trac #1902: > http://hackage.haskell.org/trac/ghc/ticket/1902 > > Note that this is a divergence from Haskell 98 (but the libraries > already have a handful of small divergences, and Haskell' is just around > the corner...). > > In my opinion, (^) has the wrong type. Just as we have, for example, > (!!) :: [a] -> Int -> a > genericIndex :: (Integral b) => [a] -> b -> a > we should also have > (^) :: (Num a) => a -> Int -> a > genericPower :: (Num a, Integral b) => a -> b -> a > (or some other function name). The same goes for (^^) (genericPower'). I vote for this proposal. In order not to overuse the prime, I propose genericFractionalPower or genericFracPower for (^^). In my code, the exponent is most oftenly 2. From lemming at henning-thielemann.de Sat Nov 17 10:29:45 2007 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sat Nov 17 10:26:11 2007 Subject: META-PROPOSAL: Documentation should be required to say when exports were introduced In-Reply-To: <20071117141318.GA31429@matrix.chaos.earth.li> References: <20071117141318.GA31429@matrix.chaos.earth.li> Message-ID: On Sat, 17 Nov 2007, Ian Lynagh wrote: > This is trac #1903: > http://hackage.haskell.org/trac/ghc/ticket/1903 > > One of the nice things about, for example, PHP is that if you look at > the documentation for one of its functions, e.g. > http://www.php.net/manual/en/function.file-get-contents.php > it tells you that file_get_contents is available in PHP >= 4.3.0. > > I propose that all exports in Haskell libraries should be required to > have such a thing in their haddock documentation. For the current code > we could either give the current versions as the date of introduction, > or do some digging and put precise data in. It should be automated, otherwise it will be a new source of misdocumentation. There should be a tool that determines the earliest occurence of a function given a list of package directories or a darcs repository. This tool could generate a file with the information of when functions were introduced. The file could also be managed incrementally. That is, whenever 'Setup.hs dist' is run, then new function names plus the current .cabal version are added to the function versioning file. This file must be understood by Haddock. Hackage could use this tool to automatically add the information in the online documentation. From stefanor at cox.net Sat Nov 17 10:51:45 2007 From: stefanor at cox.net (Stefan O'Rear) Date: Sat Nov 17 10:48:12 2007 Subject: META-PROPOSAL: Documentation should be required to say when exports were introduced In-Reply-To: References: <20071117141318.GA31429@matrix.chaos.earth.li> Message-ID: <20071117155145.GA3452@localhost.localdomain> On Sat, Nov 17, 2007 at 04:29:45PM +0100, Henning Thielemann wrote: > > On Sat, 17 Nov 2007, Ian Lynagh wrote: > > > This is trac #1903: > > http://hackage.haskell.org/trac/ghc/ticket/1903 > > > > One of the nice things about, for example, PHP is that if you look at > > the documentation for one of its functions, e.g. > > http://www.php.net/manual/en/function.file-get-contents.php > > it tells you that file_get_contents is available in PHP >= 4.3.0. > > > > I propose that all exports in Haskell libraries should be required to > > have such a thing in their haddock documentation. For the current code > > we could either give the current versions as the date of introduction, > > or do some digging and put precise data in. > > It should be automated, otherwise it will be a new source of > misdocumentation. There should be a tool that determines the earliest > occurence of a function given a list of package directories or a darcs > repository. This tool could generate a file with the information of when > functions were introduced. The file could also be managed incrementally. > That is, whenever 'Setup.hs dist' is run, then new function names plus the > current .cabal version are added to the function versioning file. This > file must be understood by Haddock. Hackage could use this tool to > automatically add the information in the online documentation. I think some variation of this is a great idea, and its absense has annoyed me greatly in the past. Stefan -------------- 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/libraries/attachments/20071117/3ab4cb24/attachment.bin From bulat.ziganshin at gmail.com Sat Nov 17 10:53:18 2007 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sat Nov 17 10:55:41 2007 Subject: META-PROPOSAL: Documentation should be required to say when exports were introduced In-Reply-To: <20071117141318.GA31429@matrix.chaos.earth.li> References: <20071117141318.GA31429@matrix.chaos.earth.li> Message-ID: <124471320.20071117185318@gmail.com> Hello Ian, Saturday, November 17, 2007, 5:13:18 PM, you wrote: > it tells you that file_get_contents is available in PHP >= 4.3.0. > I propose that all exports in Haskell libraries should be required to > have such a thing in their haddock documentation. may be we should construct a "Good Library" policy which includes reqs to "well-behaved" or mat be "haskeller-fiendly" lib? in particular, these rules should be required for any lib included in Haskell Standard (as i proposed) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From igloo at earth.li Sat Nov 17 11:10:05 2007 From: igloo at earth.li (Ian Lynagh) Date: Sat Nov 17 11:06:32 2007 Subject: META-PROPOSAL: Documentation should be required to say when exports were introduced In-Reply-To: <124471320.20071117185318@gmail.com> References: <20071117141318.GA31429@matrix.chaos.earth.li> <124471320.20071117185318@gmail.com> Message-ID: <20071117161005.GA569@matrix.chaos.earth.li> On Sat, Nov 17, 2007 at 06:53:18PM +0300, Bulat Ziganshin wrote: > Saturday, November 17, 2007, 5:13:18 PM, you wrote: > > > I propose that all exports in Haskell libraries should be required to > > have such a thing in their haddock documentation. > > may be we should construct a "Good Library" policy which includes reqs > to "well-behaved" or mat be "haskeller-fiendly" lib? in particular, > these rules should be required for any lib included in Haskell > Standard (as i proposed) Oh, right, when I wrote "Haskell libraries" I was thinking "all GHC bootlibs and all libraries covered by the library submissions procedure" (but it would be good if other libraries followed suit). Sorry, I should have said that in the original mail. If we decide to distinguish a set of libraries as "standard" then I agree that they, too, should be required to have versions in the docs. Thanks Ian From bulat.ziganshin at gmail.com Sat Nov 17 11:12:03 2007 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sat Nov 17 11:14:09 2007 Subject: META-PROPOSAL: Documentation should be required to say when exports were introduced In-Reply-To: <20071117161005.GA569@matrix.chaos.earth.li> References: <20071117141318.GA31429@matrix.chaos.earth.li> <124471320.20071117185318@gmail.com> <20071117161005.GA569@matrix.chaos.earth.li> Message-ID: <1178437652.20071117191203@gmail.com> Hello Ian, Saturday, November 17, 2007, 7:10:05 PM, you wrote: >> may be we should construct a "Good Library" policy which includes reqs >> to "well-behaved" or mat be "haskeller-fiendly" lib? in particular, >> these rules should be required for any lib included in Haskell >> Standard (as i proposed) > Oh, right, when I wrote "Haskell libraries" I was thinking "all GHC > bootlibs and all libraries covered by the library submissions > procedure" (but it would be good if other libraries followed suit). well, it was obvious after all. what i mean here is what you will do after this proposal will be accepted? keep it as one more well-known-nowhere-written rule? i propose to make wiki page with rules for "standard libraries" which at this moment may be ones supported by libraries@ community these rules will include "submission procedure" and anything else we agree by standard process -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From cgibbard at gmail.com Sat Nov 17 11:45:52 2007 From: cgibbard at gmail.com (Cale Gibbard) Date: Sat Nov 17 11:42:22 2007 Subject: PROPOSAL: Restrict the type of (^), (^^), and add genericPower, genericPower' In-Reply-To: <20071117140244.GA31275@matrix.chaos.earth.li> References: <20071117140244.GA31275@matrix.chaos.earth.li> Message-ID: <89ca3d1f0711170845t35e673d3kb8a3d698f85fba09@mail.gmail.com> On 17/11/2007, Ian Lynagh wrote: > > Hi all, > > This got a warm reception when I mentioned it in > http://www.haskell.org/pipermail/haskell-cafe/2007-June/027557.html > so I'm formally proposing it now. It's trac #1902: > http://hackage.haskell.org/trac/ghc/ticket/1902 > > Note that this is a divergence from Haskell 98 (but the libraries > already have a handful of small divergences, and Haskell' is just around > the corner...). > > In my opinion, (^) has the wrong type. Just as we have, for example, > (!!) :: [a] -> Int -> a > genericIndex :: (Integral b) => [a] -> b -> a > we should also have > (^) :: (Num a) => a -> Int -> a > genericPower :: (Num a, Integral b) => a -> b -> a > (or some other function name). The same goes for (^^) (genericPower'). > > In my experience this would remove 99.9% of all defaulting (mostly where > you write things like x^12 and 8^12), which means it's easier to get > -Wall clean without having to put :: Int annotations everywhere. > > The impact to GHC's bootlibs and extralibs is minimal. In most cases we > have things like 2^15, where Int is clearly fine, although it happens to > be defaulted to Integer currently. In Data.Complex we have 2 cases of > e^(2::Int) which can now be beautified. There are several cases where > the type is inferred to be Int anyway. > > There are 3 files where we really do have an Integer, and it does > matter. They are all for parsing numbers of the form 18e43, in > base/Text/Read/Lex.hs, parsec/Text/ParserCombinators/Parsec/Token.hs and > haskell-src/Language/Haskell/Lexer.hs. > > Initial deadline: 1 Dec 2007. > > > Thanks > Ian This is a move in the opposite direction from what I'd really like to see. The Int type is usually a premature optimisation, and I usually prefer to work with Integer as much as possible, but this just means more fromIntegral conversions (or the use of the awkwardly named general version). I would much prefer for length, !!, etc. to have more general types, not less general (with compiler specialisation on Int of course). This change would be annoying. - Cale From waldmann at imn.htwk-leipzig.de Sat Nov 17 11:48:52 2007 From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann) Date: Sat Nov 17 11:45:18 2007 Subject: PROPOSAL: Restrict the type of (^), (^^), and add genericPower, genericPower' In-Reply-To: <89ca3d1f0711170845t35e673d3kb8a3d698f85fba09@mail.gmail.com> References: <20071117140244.GA31275@matrix.chaos.earth.li> <89ca3d1f0711170845t35e673d3kb8a3d698f85fba09@mail.gmail.com> Message-ID: <473F1B74.1040102@imn.htwk-leipzig.de> Cale Gibbard wrote: > [...] The Int type is usually a premature optimisation, > [...] I would much prefer for length, !!, etc. to have more general types, > not less general (with compiler specialisation on Int of course). Yes! Best regards, Johannes Waldmann. From igloo at earth.li Sat Nov 17 11:59:02 2007 From: igloo at earth.li (Ian Lynagh) Date: Sat Nov 17 11:55:29 2007 Subject: PROPOSAL: Restrict the type of (^), (^^), and add genericPower, genericPower' In-Reply-To: <89ca3d1f0711170845t35e673d3kb8a3d698f85fba09@mail.gmail.com> References: <20071117140244.GA31275@matrix.chaos.earth.li> <89ca3d1f0711170845t35e673d3kb8a3d698f85fba09@mail.gmail.com> Message-ID: <20071117165902.GA1883@matrix.chaos.earth.li> On Sat, Nov 17, 2007 at 11:45:52AM -0500, Cale Gibbard wrote: > On 17/11/2007, Ian Lynagh wrote: > > > > (^) :: (Num a) => a -> Int -> a > > genericPower :: (Num a, Integral b) => a -> b -> a > > This is a move in the opposite direction from what I'd really like to > see. The Int type is usually a premature optimisation, and I usually > prefer to work with Integer as much as possible, but this just means > more fromIntegral conversions (or the use of the awkwardly named > general version). > > I would much prefer for length, !!, etc. to have more general types, > not less general (with compiler specialisation on Int of course). This proposal is about making (^) and (^^) consistent with everything else. Making everything use Integer rather than Int is an orthogonal question. Someone could also make a Prelude.Integer module, that exports foo :: ... Integer ... foo = genericFoo for various foo which are specialised to Int in Prelude, and reexports all other functions from Prelude. Getting rid of implicit Prelude imports would help too. Thanks Ian From igloo at earth.li Sat Nov 17 12:02:18 2007 From: igloo at earth.li (Ian Lynagh) Date: Sat Nov 17 11:58:45 2007 Subject: META-PROPOSAL: Documentation should be required to say when exports were introduced In-Reply-To: <1178437652.20071117191203@gmail.com> References: <20071117141318.GA31429@matrix.chaos.earth.li> <124471320.20071117185318@gmail.com> <20071117161005.GA569@matrix.chaos.earth.li> <1178437652.20071117191203@gmail.com> Message-ID: <20071117170218.GB1883@matrix.chaos.earth.li> Hi Bulat, On Sat, Nov 17, 2007 at 07:12:03PM +0300, Bulat Ziganshin wrote: > Saturday, November 17, 2007, 7:10:05 PM, you wrote: > > >> may be we should construct a "Good Library" policy which includes reqs > >> to "well-behaved" or mat be "haskeller-fiendly" lib? in particular, > >> these rules should be required for any lib included in Haskell > >> Standard (as i proposed) > > > Oh, right, when I wrote "Haskell libraries" I was thinking "all GHC > > bootlibs and all libraries covered by the library submissions > > procedure" (but it would be good if other libraries followed suit). > > well, it was obvious after all. what i mean here is what you will do > after this proposal will be accepted? keep it as one more > well-known-nowhere-written rule? i propose to make wiki page with > rules for "standard libraries" which at this moment may be ones > supported by libraries@ community > > these rules will include "submission procedure" and anything else we > agree by standard process The libraries submissino procedure is already on the wiki, here: http://www.haskell.org/haskellwiki/Library_submissions If you didn't find it linked from the wiki pages you expected, perhaps you could add links? The export-versioning would probably be used by more libraries than the library submissions procedure, so should probably have its own page, but with links between the two. Thanks Ian From lemming at henning-thielemann.de Sat Nov 17 12:33:23 2007 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sat Nov 17 12:29:48 2007 Subject: PROPOSAL: Restrict the type of (^), (^^), and add genericPower, genericPower' In-Reply-To: <89ca3d1f0711170845t35e673d3kb8a3d698f85fba09@mail.gmail.com> References: <20071117140244.GA31275@matrix.chaos.earth.li> <89ca3d1f0711170845t35e673d3kb8a3d698f85fba09@mail.gmail.com> Message-ID: On Sat, 17 Nov 2007, Cale Gibbard wrote: > On 17/11/2007, Ian Lynagh wrote: > > > > Hi all, > > > > This got a warm reception when I mentioned it in > > http://www.haskell.org/pipermail/haskell-cafe/2007-June/027557.html > > so I'm formally proposing it now. It's trac #1902: > > http://hackage.haskell.org/trac/ghc/ticket/1902 > > > > Note that this is a divergence from Haskell 98 (but the libraries > > already have a handful of small divergences, and Haskell' is just around > > the corner...). > > > > In my opinion, (^) has the wrong type. Just as we have, for example, > > (!!) :: [a] -> Int -> a > > genericIndex :: (Integral b) => [a] -> b -> a > > we should also have > > (^) :: (Num a) => a -> Int -> a > > genericPower :: (Num a, Integral b) => a -> b -> a > > (or some other function name). The same goes for (^^) (genericPower'). > > > > In my experience this would remove 99.9% of all defaulting (mostly where > > you write things like x^12 and 8^12), which means it's easier to get > > -Wall clean without having to put :: Int annotations everywhere. > > > > The impact to GHC's bootlibs and extralibs is minimal. In most cases we > > have things like 2^15, where Int is clearly fine, although it happens to > > be defaulted to Integer currently. In Data.Complex we have 2 cases of > > e^(2::Int) which can now be beautified. There are several cases where > > the type is inferred to be Int anyway. > > > > There are 3 files where we really do have an Integer, and it does > > matter. They are all for parsing numbers of the form 18e43, in > > base/Text/Read/Lex.hs, parsec/Text/ParserCombinators/Parsec/Token.hs and > > haskell-src/Language/Haskell/Lexer.hs. > > > > Initial deadline: 1 Dec 2007. > > > > > > Thanks > > Ian > > This is a move in the opposite direction from what I'd really like to > see. The Int type is usually a premature optimisation, Accepted, but then I prefer fixed type 'Integer' as exponent and some guarantee, that powers with small constant exponents are converted to products by the optimizer. From cgibbard at gmail.com Sat Nov 17 13:00:51 2007 From: cgibbard at gmail.com (Cale Gibbard) Date: Sat Nov 17 12:57:19 2007 Subject: PROPOSAL: Restrict the type of (^), (^^), and add genericPower, genericPower' In-Reply-To: <20071117165902.GA1883@matrix.chaos.earth.li> References: <20071117140244.GA31275@matrix.chaos.earth.li> <89ca3d1f0711170845t35e673d3kb8a3d698f85fba09@mail.gmail.com> <20071117165902.GA1883@matrix.chaos.earth.li> Message-ID: <89ca3d1f0711171000q2da03fcdn8962b38b6061c1e7@mail.gmail.com> On 17/11/2007, Ian Lynagh wrote: > On Sat, Nov 17, 2007 at 11:45:52AM -0500, Cale Gibbard wrote: > > On 17/11/2007, Ian Lynagh wrote: > > > > > > (^) :: (Num a) => a -> Int -> a > > > genericPower :: (Num a, Integral b) => a -> b -> a > > > > This is a move in the opposite direction from what I'd really like to > > see. The Int type is usually a premature optimisation, and I usually > > prefer to work with Integer as much as possible, but this just means > > more fromIntegral conversions (or the use of the awkwardly named > > general version). > > > > I would much prefer for length, !!, etc. to have more general types, > > not less general (with compiler specialisation on Int of course). > > This proposal is about making (^) and (^^) consistent with everything > else. Making everything use Integer rather than Int is an orthogonal > question. > > Someone could also make a Prelude.Integer module, that exports > foo :: ... Integer ... > foo = genericFoo > for various foo which are specialised to Int in Prelude, and reexports > all other functions from Prelude. Getting rid of implicit Prelude > imports would help too. > > > Thanks > Ian I don't want the types specialised to Integer either though. I'd want to have the types be as generic as possible, but include appropriate pragmas to tell GHC how to optimise when they're applied monomorphically. From lemming at henning-thielemann.de Sat Nov 17 13:11:22 2007 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sat Nov 17 13:07:47 2007 Subject: PROPOSAL: Restrict the type of (^), (^^), and add genericPower, genericPower' In-Reply-To: <89ca3d1f0711171000q2da03fcdn8962b38b6061c1e7@mail.gmail.com> References: <20071117140244.GA31275@matrix.chaos.earth.li> <89ca3d1f0711170845t35e673d3kb8a3d698f85fba09@mail.gmail.com> <20071117165902.GA1883@matrix.chaos.earth.li> <89ca3d1f0711171000q2da03fcdn8962b38b6061c1e7@mail.gmail.com> Message-ID: On Sat, 17 Nov 2007, Cale Gibbard wrote: > On 17/11/2007, Ian Lynagh wrote: > > > This proposal is about making (^) and (^^) consistent with everything > > else. Making everything use Integer rather than Int is an orthogonal > > question. > > > > Someone could also make a Prelude.Integer module, that exports > > foo :: ... Integer ... > > foo = genericFoo > > for various foo which are specialised to Int in Prelude, and reexports > > all other functions from Prelude. Getting rid of implicit Prelude > > imports would help too. > > > > > > Thanks > > Ian > > I don't want the types specialised to Integer either though. I'd want > to have the types be as generic as possible, but include appropriate > pragmas to tell GHC how to optimise when they're applied > monomorphically. As Ian pointed to, general types for exponents are rarely used in the code he explored. This is also my experience from doing math with Haskell. Did you make a different experience? The proposal isn't about removing the polymorphism of (^), but to shift it to an alphanumerically named function. I find "to have the types be as generic as possible" isn't always a good design strategy, especially in this case, where the type of the exponent cannot be infered from other operands. Thus in many cases the compiler has to choose a default type. It's just like I find (*) :: (Multiplyable a b c) => a -> b -> c not a good idea, say for various multiplications in linear algebra, because of lost type inference. From igloo at earth.li Sat Nov 17 13:17:08 2007 From: igloo at earth.li (Ian Lynagh) Date: Sat Nov 17 13:13:34 2007 Subject: PROPOSAL: Restrict the type of (^), (^^), and add genericPower, genericPower' In-Reply-To: <89ca3d1f0711171000q2da03fcdn8962b38b6061c1e7@mail.gmail.com> References: <20071117140244.GA31275@matrix.chaos.earth.li> <89ca3d1f0711170845t35e673d3kb8a3d698f85fba09@mail.gmail.com> <20071117165902.GA1883@matrix.chaos.earth.li> <89ca3d1f0711171000q2da03fcdn8962b38b6061c1e7@mail.gmail.com> Message-ID: <20071117181708.GA9955@matrix.chaos.earth.li> On Sat, Nov 17, 2007 at 01:00:51PM -0500, Cale Gibbard wrote: > On 17/11/2007, Ian Lynagh wrote: > > On Sat, Nov 17, 2007 at 11:45:52AM -0500, Cale Gibbard wrote: > > > On 17/11/2007, Ian Lynagh wrote: > > > > > > > > (^) :: (Num a) => a -> Int -> a > > > > genericPower :: (Num a, Integral b) => a -> b -> a > > > > > > This is a move in the opposite direction from what I'd really like to > > > see. The Int type is usually a premature optimisation, and I usually > > > prefer to work with Integer as much as possible, but this just means > > > more fromIntegral conversions (or the use of the awkwardly named > > > general version). > > > > > > I would much prefer for length, !!, etc. to have more general types, > > > not less general (with compiler specialisation on Int of course). > > > > This proposal is about making (^) and (^^) consistent with everything > > else. Making everything use Integer rather than Int is an orthogonal > > question. > > > > Someone could also make a Prelude.Integer module, that exports > > foo :: ... Integer ... > > foo = genericFoo > > for various foo which are specialised to Int in Prelude, and reexports > > all other functions from Prelude. Getting rid of implicit Prelude > > imports would help too. > > I don't want the types specialised to Integer either though. I'd want > to have the types be as generic as possible, but include appropriate > pragmas to tell GHC how to optimise when they're applied > monomorphically. You can also make Prelude.Generic foo :: Integral a => ... a ... foo = genericFoo Or we could just remove the genericFoo functions and have Prelude.Generic.foo be the canonical name. If possible, I would like to separate what we should do /in general/ from whether we should make (^) and (^^) consistent with the rest of the libraries, though. If someone wants to propose a change to the general scheme /now/ then I don't mind this proposal waiting until that is either resolved or fizzles out. Thanks Ian From dbenbenn at gmail.com Sat Nov 17 14:00:55 2007 From: dbenbenn at gmail.com (David Benbennick) Date: Sat Nov 17 13:57:21 2007 Subject: PROPOSAL: Restrict the type of (^), (^^), and add genericPower, genericPower' In-Reply-To: <20071117140244.GA31275@matrix.chaos.earth.li> References: <20071117140244.GA31275@matrix.chaos.earth.li> Message-ID: I vote against this proposal. On 11/17/07, Ian Lynagh wrote: > In my experience this would remove 99.9% of all defaulting (mostly where > you write things like x^12 and 8^12), which means it's easier to get > -Wall clean without having to put :: Int annotations everywhere. I agree that is a benefit (making it easier to avoid warnings), but in my opinion it is a tiny benefit. I don't see any other benefits to this proposal. And I am strongly against making the standard library more complicated by adding multiple functions that do the same thing (^ and genericPower). The inverse proposal has the same benefit, and doesn't require a change to GHC: just add intPower to your own code, and use it wherever you want. If you are unhappy with the idea of using intPower, perhaps you understand why I'm unhappy with the prospect of having to use genericPower. From lemming at henning-thielemann.de Sat Nov 17 16:13:54 2007 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sat Nov 17 16:10:36 2007 Subject: PROPOSAL: Restrict the type of (^), (^^), and add genericPower, genericPower' In-Reply-To: References: <20071117140244.GA31275@matrix.chaos.earth.li> Message-ID: On Sat, 17 Nov 2007, David Benbennick wrote: > I vote against this proposal. > > On 11/17/07, Ian Lynagh wrote: > > In my experience this would remove 99.9% of all defaulting (mostly where > > you write things like x^12 and 8^12), which means it's easier to get > > -Wall clean without having to put :: Int annotations everywhere. > > I agree that is a benefit (making it easier to avoid warnings), but in > my opinion it is a tiny benefit. Let me guess - you don't use -Wall. :-) Warnings are not the problem, warnings point to a problem. The problem here is, that the compiler has to guess a type, because it cannot be infered from other operands. > The inverse proposal has the same benefit, and doesn't require a > change to GHC: just add intPower to your own code, and use it wherever > you want. If you are unhappy with the idea of using intPower, perhaps > you understand why I'm unhappy with the prospect of having to use > genericPower. Question: How often did you need the genericity of Haskell 98 (^) ? That is, how often do you call (^) with a non-constant exponent and how often is the exponent constant? If I have (^) with variable exponents too often in the code, I suspect that I missed some optimizations like (iterate (x*) 1). I have done (semi-automatically) some statistics on my mathematical stuff in Haskell, namely http://darcs.haskell.org/htam/src (^^) used with exponents (1-j) (n2-1) n pred n (^) used with variable exponents i j m n n n n degree xs degree xs degree ys (n2-1) mod n 2 mod (p+1) 2 (^) used with constant exponents 2: 169 times 3: 31 times 4: 9 times 5: 10 times 6: 3 times 7: 2 times 8: 1 times 9: 1 times If I search for '::Int', the most results are exponents of (^), others are from enumerations like [(0::Int)..]. From dbenbenn at gmail.com Sat Nov 17 17:46:56 2007 From: dbenbenn at gmail.com (David Benbennick) Date: Sat Nov 17 17:43:23 2007 Subject: PROPOSAL: Restrict the type of (^), (^^), and add genericPower, genericPower' In-Reply-To: References: <20071117140244.GA31275@matrix.chaos.earth.li> Message-ID: I thought of two more reasons I'm against this proposal: 2) It isn't backwards compatible. It will cause some existing Haskell code to not compile. 3) It makes things more difficult in GHCI. Under this proposal, you'd have the following: Prelude> let x = 2 Prelude> 6 ^ x : Couldn't match expected type `Int' against inferred type `Integer' On 11/17/07, Henning Thielemann wrote: > Let me guess - you don't use -Wall. :-) Warnings are not the problem, > warnings point to a problem. The problem here is, that the compiler has to > guess a type, because it cannot be infered from other operands. I don't see how that's a problem. Have you ever had a case where defaulting to Integer produced the wrong behavior? From igloo at earth.li Sat Nov 17 19:20:03 2007 From: igloo at earth.li (Ian Lynagh) Date: Sat Nov 17 19:16:31 2007 Subject: PROPOSAL: Restrict the type of (^), (^^), and add genericPower, genericPower' In-Reply-To: References: <20071117140244.GA31275@matrix.chaos.earth.li> Message-ID: <20071118002003.GA26999@matrix.chaos.earth.li> On Sat, Nov 17, 2007 at 02:46:56PM -0800, David Benbennick wrote: > I thought of two more reasons I'm against this proposal: > > 2) It isn't backwards compatible. It will cause some existing Haskell > code to not compile. That is true, and is why I checked all the bootlibs and corelibs in my original message. I don't believe many programs/libraries will be affected, but I'm willing to be proven wrong! (The fix is trivial anyway, of course. The only annoying bit is checking that you weren't relying on any cases being defaulted to Integer, but you should be able to check for that easily by compiling with -fwarn-type-defaults). > 3) It makes things more difficult in GHCI. Under this proposal, you'd > have the following: > > Prelude> let x = 2 > Prelude> 6 ^ x > : > Couldn't match expected type `Int' against inferred type `Integer' This is true, just as you currently get: Prelude> let x = 2 Prelude> take x [1..] :1:5: Couldn't match expected type `Int' against inferred type `Integer' and likewise for (!!) etc. I hadn't really noticed that the default defaulting conflicts with the use of Int in the standard functions in this way. I guess in ghci is the only time it comes up, though. > On 11/17/07, Henning Thielemann wrote: > > Let me guess - you don't use -Wall. :-) Warnings are not the problem, > > warnings point to a problem. The problem here is, that the compiler has to > > guess a type, because it cannot be infered from other operands. > > I don't see how that's a problem. Have you ever had a case where > defaulting to Integer produced the wrong behavior? Unintentional defaulting can mean significant performance loss. If you leave intentional defaulting in the code then you will get warnings when you compile with -Wall, and if you always get warnings when you compile then you just ignore all warnings. This means that warnings don't help you to find bugs in your code. Thanks Ian From iavor.diatchki at gmail.com Sat Nov 17 19:42:21 2007 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Sat Nov 17 19:38:48 2007 Subject: PROPOSAL: Restrict the type of (^), (^^), and add genericPower, genericPower' In-Reply-To: <20071118002003.GA26999@matrix.chaos.earth.li> References: <20071117140244.GA31275@matrix.chaos.earth.li> <20071118002003.GA26999@matrix.chaos.earth.li> Message-ID: <5ab17e790711171642h6c22a891sbfa310087037db92@mail.gmail.com> Hello, I also think that this proposal is not a good idea, David Benbennick gave a number of good reasons why, and a perfectly valid solution if you are worried about the defaulting issue. By the way, defaulting to Integer should not loose any performance in the (presumably very common) case when the second argument is a statically known constant. If it does, then we should look at GHC and fix the problem there. -Iavor On Nov 17, 2007 4:20 PM, Ian Lynagh wrote: > On Sat, Nov 17, 2007 at 02:46:56PM -0800, David Benbennick wrote: > > I thought of two more reasons I'm against this proposal: > > > > 2) It isn't backwards compatible. It will cause some existing Haskell > > code to not compile. > > That is true, and is why I checked all the bootlibs and corelibs in my > original message. I don't believe many programs/libraries will be > affected, but I'm willing to be proven wrong! > > (The fix is