From dons at galois.com Sat Jan 5 00:37:41 2008 From: dons at galois.com (Don Stewart) Date: Sat Jan 5 00:31:46 2008 Subject: bytestring 0.9.0.4 Message-ID: <20080105053741.GA15950@scytale.galois.com> 2.5 years after the first release, bytestring 0.9.0.4 is now available on hackage, http://hackage.haskell.org/cgi-bin/hackage-scripts/package/bytestring-0.9.0.4 Changes since the 0.9 release include: * support for bytestring literals (use -XOverloadedStrings) * make Data.ByteString.Lazy.Char8.lines lazier * fixes Handle resource leak in getContents/readFile * faster isSpace operations * performance improvements The most notable change is the instance IsString for strict and lazy bytestrings, enabling bytestrings to be written as direct string literals, without needing 'pack'. That is, the following is valid: import Data.ByteString.Char8 main = print ("abcdef" :: ByteString) (and the compile will even turn the pack into a no-op at compile time). Or, using the (soon to be released pcre-light package), bytestring regex literals can be written as: compile "a(.*)b" where compile :: ByteString -> Either String Regex With -XOverloadedStrings, the 'pack'for the regex is inferred. -- Don & Duncan From dave at zednenem.com Sat Jan 5 14:52:52 2008 From: dave at zednenem.com (David Menendez) Date: Sat Jan 5 14:46:41 2008 Subject: bytestring 0.9.0.4 In-Reply-To: <20080105053741.GA15950@scytale.galois.com> References: <20080105053741.GA15950@scytale.galois.com> Message-ID: <49a77b7a0801051152i8c2d869m3b5560d4aaecbe20@mail.gmail.com> On Jan 5, 2008 12:37 AM, Don Stewart wrote: > The most notable change is the instance IsString for strict and > lazy bytestrings, enabling bytestrings to be written as direct string > literals, without needing 'pack'. > > That is, the following is valid: > > import Data.ByteString.Char8 > > main = print ("abcdef" :: ByteString) > What encoding is used? -- Dave Menendez -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20080105/129f22bc/attachment.htm From dons at galois.com Sat Jan 5 15:19:33 2008 From: dons at galois.com (Don Stewart) Date: Sat Jan 5 15:13:24 2008 Subject: bytestring 0.9.0.4 In-Reply-To: <49a77b7a0801051152i8c2d869m3b5560d4aaecbe20@mail.gmail.com> References: <20080105053741.GA15950@scytale.galois.com> <49a77b7a0801051152i8c2d869m3b5560d4aaecbe20@mail.gmail.com> Message-ID: <20080105201933.GC17767@scytale.galois.com> dave: > On Jan 5, 2008 12:37 AM, Don Stewart <[1]dons@galois.com> wrote: > > The most notable change is the instance IsString for strict and > lazy bytestrings, enabling bytestrings to be written as direct string > literals, without needing 'pack'. > > That is, the following is valid: > > import Data.ByteString.Char8 > > main = print ("abcdef" :: ByteString) > > What encoding is used? The 'Data.ByteString.Char8' encodin: -- ... these byte strings are taken to be in the -- subset of Unicode covered by code points 0-255. This covers -- Unicode Basic Latin, Latin-1 Supplement and C0+C1 Controls. You'll need to import Data.ByteString.Char8 to get the instance, so the encoding should be clear in this case. -- Don From john at repetae.net Sun Jan 6 12:51:19 2008 From: john at repetae.net (John Meacham) Date: Sun Jan 6 12:45:05 2008 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: <20080106175119.GB16859@momenergy.repetae.net> On Thu, Nov 08, 2007 at 02:27:55PM +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. Then Cabal would work with future GHCs, with new extensions as > yet undreamt of, as well. Yes, I would like to see this too, I have not really done a lot of work integrating jhc with cabal, but this 'baked in' extension type was something of an issue. (jhc itself understands a subset of the cabal file type and can build libraries based on them with jhc --build-hl). There are a couple other places where a 'newtype String' made more sense too if I recall. Perhaps just a simple wiki page where we can "register" extension names is in order as there are a few jhc understands that arn't in the cabal extension type (nor should they be if this fix is completed). John -- John Meacham - ?repetae.net?john? From iavor.diatchki at gmail.com Sun Jan 6 16:35:41 2008 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Sun Jan 6 16:29:26 2008 Subject: PROPOSAL: Some more 'Applicative' combinators Message-ID: <5ab17e790801061335t59d53588s2c935067457bde0e@mail.gmail.com> Hello, I propose that we add the following combinators to the 'Control.Applicative' module: skipMany :: (Alternative f) => f a -> f () skipMany p = skipSome p <|> pure () skipSome :: (Alternative f) => f a -> f () skipSome p = p *> skipMany p endBy :: (Alternative f) => f a -> f b -> f [a] endBy p s = many (p <* s) endBy1 :: (Alternative f) => f a -> f b -> f [a] endBy1 p s = some (p <* s) sepBy :: (Alternative f) => f a -> f v -> f [a] sepBy p s = sepBy1 p s <|> pure [] sepBy1 :: (Alternative f) => f a -> f v -> f [a] sepBy1 p s = (:) <$> p <*> many (s *> p) Any objections? Deadline for discussion is 2 weeks from now, which would be the 20th of Jan. -Iavor From seth at cql.com Sun Jan 6 18:34:40 2008 From: seth at cql.com (Seth Kurtzberg) Date: Sun Jan 6 18:29:01 2008 Subject: PROPOSAL: Some more 'Applicative' combinators In-Reply-To: <5ab17e790801061335t59d53588s2c935067457bde0e@mail.gmail.com> References: <5ab17e790801061335t59d53588s2c935067457bde0e@mail.gmail.com> Message-ID: <20080106183440.5f02057c.seth@cql.com> Can you show some code fragments demonstrating how the combinators are used? I find it easier to understand the underlying concepts when I have not only the signature and implementation but an example of a typical use. It doesn't have to be working code, and it might even be pseudo code. (I'm not sure whether other Haskell folks feel the same way.) On Sun, 6 Jan 2008 13:35:41 -0800 "Iavor Diatchki" wrote: > Hello, > I propose that we add the following combinators to the > 'Control.Applicative' module: > > skipMany :: (Alternative f) => f a -> f () > skipMany p = skipSome p <|> pure () > > skipSome :: (Alternative f) => f a -> f () > skipSome p = p *> skipMany p > > endBy :: (Alternative f) => f a -> f b -> f [a] > endBy p s = many (p <* s) > > endBy1 :: (Alternative f) => f a -> f b -> f [a] > endBy1 p s = some (p <* s) > > sepBy :: (Alternative f) => f a -> f v -> f [a] > sepBy p s = sepBy1 p s <|> pure [] > > sepBy1 :: (Alternative f) => f a -> f v -> f [a] > sepBy1 p s = (:) <$> p <*> many (s *> p) > > > Any objections? Deadline for discussion is 2 weeks from now, which > would be the 20th of Jan. > > -Iavor > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries > -- Seth Kurtzberg Hardware/Software/Driver Engineering From iavor.diatchki at gmail.com Sun Jan 6 21:11:39 2008 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Sun Jan 6 21:05:24 2008 Subject: PROPOSAL: Some more 'Applicative' combinators In-Reply-To: <20080106183440.5f02057c.seth@cql.com> References: <5ab17e790801061335t59d53588s2c935067457bde0e@mail.gmail.com> <20080106183440.5f02057c.seth@cql.com> Message-ID: <5ab17e790801061811j1621bc85ja3430daae3ab6db4@mail.gmail.com> Hello, Sorry, I should have mentioned the origin of the combinators. These are (generalizations of) standard parser combinators, so think of "f a" in the type as a parser that can construct values of type "a". With this in mind, it should be more obvious what these combinators are used for. For example: > p `sepBy` sep is a parser that will return 0 or more occurances of 'p' separated by 'sep'. Many (all?) parser combinator libraries provide these functions, so having the generic 'Alternative' interface makes it easier to write parser that can work with different libraries. -Iavor On Jan 6, 2008 3:34 PM, Seth Kurtzberg wrote: > Can you show some code fragments demonstrating how the combinators are used? I find it easier to understand the underlying concepts when I have not only the signature and implementation but an example of a typical use. It doesn't have to be working code, and it might even be pseudo code. (I'm not sure whether other Haskell folks feel the same way.) > > > On Sun, 6 Jan 2008 13:35:41 -0800 > "Iavor Diatchki" wrote: > > > Hello, > > I propose that we add the following combinators to the > > 'Control.Applicative' module: > > > > skipMany :: (Alternative f) => f a -> f () > > skipMany p = skipSome p <|> pure () > > > > skipSome :: (Alternative f) => f a -> f () > > skipSome p = p *> skipMany p > > > > endBy :: (Alternative f) => f a -> f b -> f [a] > > endBy p s = many (p <* s) > > > > endBy1 :: (Alternative f) => f a -> f b -> f [a] > > endBy1 p s = some (p <* s) > > > > sepBy :: (Alternative f) => f a -> f v -> f [a] > > sepBy p s = sepBy1 p s <|> pure [] > > > > sepBy1 :: (Alternative f) => f a -> f v -> f [a] > > sepBy1 p s = (:) <$> p <*> many (s *> p) > > > > > > Any objections? Deadline for discussion is 2 weeks from now, which > > would be the 20th of Jan. > > > > -Iavor > > _______________________________________________ > > Libraries mailing list > > Libraries@haskell.org > > http://www.haskell.org/mailman/listinfo/libraries > > > > > -- > Seth Kurtzberg > Hardware/Software/Driver Engineering > From bos at serpentine.com Mon Jan 7 00:20:05 2008 From: bos at serpentine.com (Bryan O'Sullivan) Date: Mon Jan 7 00:13:47 2008 Subject: PROPOSAL: Some more 'Applicative' combinators In-Reply-To: <5ab17e790801061335t59d53588s2c935067457bde0e@mail.gmail.com> References: <5ab17e790801061335t59d53588s2c935067457bde0e@mail.gmail.com> Message-ID: <4781B685.7050500@serpentine.com> Iavor Diatchki wrote: > I propose that we add the following combinators to the > 'Control.Applicative' module: While applicative functors are good for this task, it would be a shame if the innocent reader of haddocks were to acquire the impression that parsing was all they were for. Why not make the task specificity clearer, with a separate Control.Applicative.Parsing module? It's been pointed out by a couple of people that the type of forever is overly constrained. We get a few more useful programs for free if we change the type: [generalise type of 'forever' from returning m () to m a Don Stewart **20080107062656] { hunk ./Control/Monad.hs 42 - , forever -- :: (Monad m) => m a -> m () + , forever -- :: (Monad m) => m a -> m a hunk ./Control/Monad.hs 190 -forever :: (Monad m) => m a -> m () +forever :: (Monad m) => m a -> m a } In particular, fail breaks out nicely. > forever Nothing Nothing Deadline: 12th January. -- Don -------------- next part -------------- New patches: [generalise type of 'forever' from returning m () to m a Don Stewart **20080107062656] { hunk ./Control/Monad.hs 42 - , forever -- :: (Monad m) => m a -> m () + , forever -- :: (Monad m) => m a -> m a hunk ./Control/Monad.hs 190 -forever :: (Monad m) => m a -> m () +forever :: (Monad m) => m a -> m a } Context: [Tuple tycons have parens around their names simonpj@microsoft**20071220171812 The name of the pair TyCon, in the Typeable instance, should be "(,)" not ",". Don't merge to 6.8; it's a minor API change. ] [Add groupWith, sortWith, the, to support generalised list comprehensions simonpj@microsoft.com**20071220111929 This the base-library patch to support the main compiler patch Implement generalised list comprehensions It just adds three functions to GHC.Exts. ] [Add GHC.Prim to exposedModules in the Haddock 0.x hook David Waern *-20071209173931 Please merge to the stable branch ] [Add GHC.Prim to exposedModules in the Haddock 0.x hook David Waern **20071209173931 Please merge to the stable branch ] [Simplify the GHC.Prim hack in base.cabal/Setup.hs Ian Lynagh **20071202215758] [Implement 'openTempFile' for nhc98. Malcolm.Wallace@cs.york.ac.uk**20071207133335] [docs: describe the changes to forkIO, and document forkOnIO Simon Marlow **20071205091423] [doc only: use realToFrac instead of fromRational.toRational Simon Marlow **20071205091334] [Add singletonP to GHC.PArr Roman Leshchinskiy **20071205220859] [FIX #1621: bug in Windows code for getCPUTime Simon Marlow **20071205120118 We were reading the components of FILETIME as CLong, when they should be unsigned. Word32 seems to be the correct type here. ] [protect console handler against concurrent access (#1922) Simon Marlow **20071204153940] [protect against concurrent access to the signal handlers (#1922) Simon Marlow **20071204110817] [restore fdToHandle' to avoid breaking clients (#1109) Simon Marlow **20071130135122 ] [note about how to convert CTime (aka EpochTime) to UTCTime Simon Marlow **20071130101648] [Fix some URLs Ian Lynagh **20071126214213] [Fix some links in haddock docs Ian Lynagh **20071126184428] [Don't try to make haddock links to the mtl package as we don't depend on it Ian Lynagh **20071126170631] [Escape some special characters in haddock docs Ian Lynagh **20071126163443] [FIX BUILD: maybeUpdateFile: ignore failures when removing the target Simon Marlow **20071123092219] [FIX #1753 Simon Marlow **20071122094207 hClose should close the Handle and unlock the file even if calling close() fails for some reason. ] [remove lockFile.h from install-includes Simon Marlow **20071121102248] [oops, we forgot to export traceShow Simon Marlow **20071121094300] [Fix compilation with GHC 6.2.x Simon Marlow **20071121084341] [Move file locking into the RTS, fixing #629, #1109 Simon Marlow **20071120121053 File locking (of the Haskell 98 variety) was previously done using a static table with linear search, which had two problems: the array had a fixed size and was sometimes too small (#1109), and performance of lockFile/unlockFile was suboptimal due to the linear search. Also the algorithm failed to count readers as required by Haskell 98 (#629). Now it's done using a hash table (provided by the RTS). Furthermore I avoided the extra fstat() for every open file by passing the dev_t and ino_t into lockFile. This and the improvements to the locking algorithm result in a healthy 20% or so performance increase for opening/closing files (see openFile008 test). ] [Only overwrite GHC/Prim.hs and GHC/Primopwrappers.hs if they change Simon Marlow **20071120102042 This avoids make doing unnecessary work after 'setup makefile'. ] [fix comment Simon Marlow **20071116091227] [Fix ` characters in elem's haddock docs Ian Lynagh **20071110173052] [Filter out GHC.Prim also for the Haddock step David Waern **20071109000806 Please merge to the GHC 6.8.2 branch ] [Add module of special magic GHC desugaring helper functions Simon Marlow **20071102160054 Currently containing only one such helper: (>>>) for arrow desugaring ] [add Control.Category to the nhc98 build Malcolm.Wallace@cs.york.ac.uk**20071030120459] [fix nhc98 build: need a qualified Prelude import Malcolm.Wallace@cs.york.ac.uk**20071030120410] [Fix performance regression: re-instate -funbox-strict-fields Simon Marlow **20071029150730 Yikes! While investigating the increase in code size with GHC 6.8 relative to 6.6, I noticed that in the transition to Cabal for the libraries we lost -funbox-strict-fields, which is more or less depended on by the IO library for performance. I'm astonished that we didn't notice this earlier! To reduce the chances of this happening again, I put -funbox-strict-fields in the OPTIONS_GHC pragma of the modules that need it. {-# UNPACK #-} pragmas would be better, though. ] [FIX BUILD: Haddock 1.x fails to parse (Prelude..) Simon Marlow **20071029131921] [new Control.Category, ghc ticket #1773 Ashley Yakeley **20071029022526] [new Control.Compositor module Ashley Yakeley **20071013074851 The Compositor class is a superclass of Arrow. ] [Fix doc building with Haddock 0.9 Simon Marlow **20071024090947 I was using a recent build here, which is more tolerant. ] [FIX #1258: document that openTempFile is secure(ish) Simon Marlow **20071023130928 Also change the mode from 0666 to 0600, which seems like a more sensible value and matches what C's mkstemp() does. ] [Clean up .cabal file a bit Duncan Coutts **20071022132708 specify build-type and cabal-version >= 1.2 put extra-tmp-files in the right place use os(windows) rather than os(mingw32) ] [FIX #1652: openTempFile should accept an empty string for the directory Simon Marlow **20071018122345] [clean up duplicate code Simon Marlow **20071017141311] [expose the value of +RTS -N as GHC.Conc.numCapabilities (see #1733) Simon Marlow **20071009132042] [base in 6.8 and head branch should be version 3.0 Don Stewart **20071007150408] [typo Simon Marlow **20070917130703] [put extra-tmp-files field in the right place Simon Marlow **20070914140812] [Add more entries to boring file Ian Lynagh **20070913210500] [Add a boring file Ian Lynagh **20070913204641] [TAG 2007-09-13 Ian Lynagh **20070913215720] [FIX #1689 (openTempFile returns wrong filename) Tim Chevalier **20070913052025] [TAG ghc-6.8 branched 2007-09-03 Ian Lynagh **20070903155541] [Remove some incorrect rules; fixes #1658: CSE [of Doubles] changes semantics Ian Lynagh **20070904134140] [make hWaitForInput/hReady not fail with "invalid argument" on Windows Simon Marlow **20070830131115 See #1198. This doesn't fully fix it, because hReady still always returns False on file handles. I'm not really sure how to fix that. ] [Fix haddock docs in Hashtable Ian Lynagh **20070830154131] [Fix building HashTable: Use ord rather than fromEnum Ian Lynagh **20070830150214] [Better hash functions for Data.HashTable, from Jan-Willem Maessen Ian Lynagh **20070830142844] [Remove redundant include/Makefile Ian Lynagh **20070828205659] [Make arrays safer (e.g. trac #1046) Ian Lynagh **20070810163405] [delete configure droppings in setup clean Simon Marlow **20070824104100] [FIX #1282: 64-bit unchecked shifts are not exported from base Simon Marlow **20070823135033 I've exported these functions from GHC.Exts. They are still implemented using the FFI underneath, though. To avoid conditional exports, on a 64-bit build: uncheckedShiftL64# = uncheckShiftL# (etc.) which has a different type than the 32-bit version of uncheckedShiftL64#, but at least GHC.Exts exports the same names. ] [Fix hashInt Ian Lynagh **20070821140706 As pointed out in http://www.haskell.org/pipermail/glasgow-haskell-bugs/2007-August/009545.html the old behaviour was Prelude Data.HashTable> map hashInt [0..10] [0,-1,-1,-2,-2,-2,-3,-3,-4,-4,-4] Fixed according to the "Fibonacci Hashing" algorithm described in http://www.brpreiss.com/books/opus4/html/page213.html http://www.brpreiss.com/books/opus4/html/page214.html ] [test impl(ghc) instead of IsGHC Ross Paterson **20070819233500] [fpstring.h has moved to bytestring Ross Paterson **20070819233815] [remove now-unused SIG constants Ross Paterson **20070819233745] [include Win32 extra-libraries for non-GHC's too Ross Paterson **20070819233611] [Don't import Distribution.Setup in Setup.hs as we no longer need it Ian Lynagh **20070816151643] [Correct the swapMVar haddock doc Ian Lynagh **20070814145028] [install Typeable.h for use by other packages Malcolm.Wallace@cs.york.ac.uk**20070813112855] [Don't try to build modules no longer living in base. Malcolm.Wallace@cs.york.ac.uk**20070813112803] [Move Data.{Foldable,Traversable} back to base Ian Lynagh **20070812165654 The Array instances are now in Data.Array. ] [Remove bits left over from the old build system Ian Lynagh **20070811135019] [Move the datamap001 (our only test) to the containers package Ian Lynagh **20070803180932] [Data.Array* and Data.PackedString have now moved to their own packages Ian Lynagh **20070801235542] [Remove a number of modules now in a "containers" package Ian Lynagh **20070801223858] [Remove System.Posix.Signals (moving to unix) Ian Lynagh **20070729215213] [bytestring is now in its own package Ian Lynagh **20070729132215] [Export throwErrnoPath* functions Ian Lynagh **20070722002923] [Add simple haddock docs for throwErrnoPath* functions Ian Lynagh **20070722002817] [Move throwErrnoPath* functions from unix:System.Posix.Error Ian Lynagh **20070722002746] [Clarify the swapMVar haddock doc Ian Lynagh **20070807185557] [fix Haddock markup Simon Marlow **20070802081717] [Temporarily fix breakage for nhc98. Malcolm.Wallace@cs.york.ac.uk**20070801163750 A recent patch to System.IO introduced a cyclic dependency on Foreign.C.Error, and also inadvertently dragged along System.Posix.Internals which has non-H'98 layout, causing many build problems. The solution for now is to #ifndef __NHC__ all of the recent the openTempFile additions, and mark them non-portable once again. (I also took the opportunity to note a number of other non-portable functions in their Haddock comments.) ] [Generalise the type of synthesize, as suggested by Trac #1571 simonpj@microsoft**20070801125208 I have not looked at the details, but the type checker is happy with the more general type, and more general types are usually a Good Thing. ] [Fix fdToHandle on Windows Ian Lynagh **20070730133139 The old setmode code was throwing an exception, and I'm not sure it is meant to do what we need anyway. For now we assume that all FDs are both readable and writable. ] [Correct Windows OS name in cabal configuration Ian Lynagh **20070729161739] [Use cabal configurations rather than Setup hacks Ian Lynagh **20070729132157] [Handle buffers should be allocated with newPinnedByteArray# always Simon Marlow **20070725095550 Not just on Windows. This change is required because we now use safe foreign calls for I/O on blocking file descriptors with the threaded RTS. Exposed by concio001.thr on MacOS X: MacOS apparently uses smaller buffers by default, so they weren't being allocated as large objects. ] [fix Hugs implementation of openTempFile Ross Paterson **20070724114003] [Hugs only: avoid dependency cycle Ross Paterson **20070724113852] [open(Binary)TempFile is now portable Ian Lynagh **20070722152752] [Tweak temporary file filename chooser Ian Lynagh **20070722105445] [Move open(Binary)TempFile to System.IO Ian Lynagh **20070722010205] [Rename openFd to fdToHandle' Ian Lynagh **20070721235538 The name collision with System.Posix.IO.openFd made my brain hurt. ] [Add a test for Data.Map, for a bug on the libraries@ list Ian Lynagh **20070721002119] [fix Data.Map.updateAt Bertram Felgenhauer **20070718150340 See http://haskell.org/pipermail/libraries/2007-July/007785.html for a piece of code triggering the bug. updateAt threw away parts of the tree making up the map. ] [in hClose, free the handle buffer by replacing it with an empty one Simon Marlow **20070719161419 This helps reduce the memory requirements for a closed but unfinalised Handle. ] [Implement GHC.Environment.getFullArgs Ian Lynagh **20070717141918 This returns all the arguments, including those normally eaten by the RTS (+RTS ... -RTS). This is mainly for ghc-inplace, where we need to pass /all/ the arguments on to the real ghc. e.g. ioref001(ghci) was failing because the +RTS -K32m -RTS wasn't getting passed on. ] [Define stripPrefix; fixes trac #1464 Ian Lynagh **20070714235204] [no need to hide Maybe Malcolm.Wallace@cs.york.ac.uk**20070710154058] [Add a more efficient Data.List.foldl' for GHC (from GHC's utils/Util.lhs) Ian Lynagh **20070706205526] [Remove include-dirs ../../includes and ../../rts Ian Lynagh **20070705205356 We get these by virtue of depending on the rts package. ] [FIX #1131 (newArray_ allocates an array full of garbage) Simon Marlow **20070704102020 Now newArray_ returns a deterministic result in the ST monad, and behaves as before in other contexts. The current newArray_ is renamed to unsafeNewArray_; the MArray class therefore has one more method than before. ] [change nhc98 option from -prelude to --prelude Malcolm.Wallace@cs.york.ac.uk**20070702150355] [Word is a type synonym in nhc98 - so class instance not permitted. Malcolm.Wallace@cs.york.ac.uk**20070629122035] [fix bug in writes to blocking FDs in the non-threaded RTS Simon Marlow **20070628134320] [Modernize printf. lennart.augustsson@credit-suisse.com**20070628083852 Add instances for Int8, Int16, Int32, Int64, Word, Word8, Word16, Word32, and Word64. Handle + flag. Handle X, E, and G formatting characters. Rewrite internals to make it simpler. ] [Speed up number printing and remove the need for Array by using the standard 'intToDigit' routine John Meacham **20070608182353] [Use "-- //" (2 spaces) rather than "-- //" (1) to avoid tripping haddock up Ian Lynagh **20070627010930 Are we nearly there yet? ] [Use a combination of Haskell/C comments to ensure robustness. Malcolm.Wallace@cs.york.ac.uk**20070626095222 e.g. -- // ensures that _no_ preprocessor will try to tokenise the rest of the line. ] [Change C-style comments to Haskell-style. Malcolm.Wallace@cs.york.ac.uk**20070625094515 These two headers are only ever used for pre-processing Haskell code, and are never seen by any C tools except cpp. Using the Haskell comment convention means that cpphs no longer needs to be given the --strip option to remove C comments from open code. This is a Good Thing, because all of /* */ and // are valid Haskell operator names, and there is no compelling reason to forbid using them in files which also happen to have C-preprocessor directives. ] [makefileHook needs to generate PrimopWrappers.hs too Simon Marlow **20070622073424] [Hugs now gets MonadFix(mfix) from its prelude Ross Paterson **20070620000343] [Typo (consUtils.hs -> consUtils.h) Ian Lynagh **20070619124140] [install dependent include files and Typeable.h Bertram Felgenhauer **20070613041734] [update prototype following inputReady->fdReady change Simon Marlow **20070614095309] [FIX hGetBuf001: cut-and-pasto in readRawBufferNoBlock Simon Marlow **20070614094222] [fix description of CWStringLen Ross Paterson **20070605223345] [Remove unsafeCoerce-importing kludgery in favor of Unsafe.Coerce Isaac Dupree **20070601203625] [--configure-option and --ghc-option are now provided by Cabal Ross Paterson **20070604115233] [Data.PackedString: Data.Generics is GHC-only Ross Paterson **20070529232427] [Add Data instance for PackedString; patch from greenrd in trac #1263 Ian Lynagh **20070529205420] [Control.Concurrent documentation fix shae@ScannedInAvian.com**20070524163325] [add nhc98-options: field to .cabal file Malcolm.Wallace@cs.york.ac.uk**20070528122626] [add a dummy implementation of System.Timeout.timeout for nhc98 Malcolm.Wallace@cs.york.ac.uk**20070528110309] [Add System.Timeout to base.cabal Ian Lynagh **20070527123314 Filtered out for non-GHC by Setup.hs. ] [add module Data.Fixed to nhc98 build Malcolm.Wallace@cs.york.ac.uk**20070525141021] [DIRS now lives in package Makefile, not script/pkgdirlist Malcolm.Wallace@cs.york.ac.uk**20070525111749] [delete unused constants Ross Paterson **20070525001741] [remove System.Cmd and System.Time too Malcolm.Wallace@cs.york.ac.uk**20070524163200] [remove locale as well Malcolm.Wallace@cs.york.ac.uk**20070524161943] [nhc98 version of instance Show (a->b) copied from Prelude Malcolm.Wallace@cs.york.ac.uk**20070524160615] [remove directory, pretty, and random bits from base for nhc98 Malcolm.Wallace@cs.york.ac.uk**20070524160608] [Remove Makefile and package.conf.in (used in the old build system) Ian Lynagh **20070524142545] [Split off process package Ian Lynagh **20070523210523] [Fix comment: maperrno is in Win32Utils.c, not runProcess.c Ian Lynagh **20070523181331] [System.Locale is now split out Ian Lynagh **20070519132638] [Split off directory, random and old-time packages Ian Lynagh **20070519120642] [Remove Control.Parallel*, now in package parallel Ian Lynagh **20070518165431] [Remove the pretty-printing modules (now in package pretty( Ian Lynagh **20070518162521] [add install-includes: field Simon Marlow **20070517094948] [correct the documentation for newForeignPtr Simon Marlow **20070516082019] [When doing safe writes, handle EAGAIN rather than raising an exception Simon Marlow **20070515114615 It might be that stdin was set to O_NONBLOCK by someone else, and we should handle this case. (this happens with GHCi, I'm not quite sure why) ] [Use FilePath to make paths when building GHC/Prim.hs and GHC/PrimopWrappers.hs Ian Lynagh **20070514110409] [Build GHC/Prim.hs and GHC/PrimopWrappers.hs from Cabal Ian Lynagh **20070509142655] [fix imports for non-GHC Ross Paterson **20070513001138] [Give an example of how intersection takes elements from the first set Ian Lynagh **20070512160253] [further clarify the docs for 'evaluate' Malcolm.Wallace@cs.york.ac.uk**20070508101124] [improve documentation for evaluate Simon Marlow **20070508081712] [FIX: #724 (tee complains if used in a process started by ghc) Simon Marlow **20070507123537 Now, we only set O_NONBLOCK on file descriptors that we create ourselves. File descriptors that we inherit (stdin, stdout, stderr) are kept in blocking mode. The way we deal with this differs between the threaded and non-threaded runtimes: - with -threaded, we just make a safe foreign call to read(), which may block, but this is ok. - without -threaded, we test the descriptor with select() before attempting any I/O. This isn't completely safe - someone else might read the data between the select() and the read() - but it's a reasonable compromise and doesn't seem to measurably affect performance. ] [the "unknown" types are no longer required Simon Marlow **20070426135931] [Make Control.Exception buildable by nhc98. Malcolm.Wallace@cs.york.ac.uk**20070504105548 The nhc98 does not have true exceptions, but these additions should be enough infrastructure to pretend that it does. Only IO exceptions will actually work. ] [Trim imports, remove a cycle simonpj@microsoft**20070503123010 A first attempt at removing gratuitous cycles in the base package. I've removed the useless module GHC.Dynamic, which gets rid of a cycle; and trimmed off various unnecesary imports. This also fixes the IsString import problem. ] [Be less quiet about building the base package simonpj@microsoft**20070503093707] [Remove Splittable class (a vestige of linear implicit parameters) simonpj@microsoft**20070221104329] [Add IsString to exports of GHC.Exts simonpj@microsoft**20070221104249] [tweak documentation as per suggestion from Marc Weber on libraries@haskell.org Simon Marlow **20070426075921] [Add extra libraries when compiling with GHC on Windows Ian Lynagh **20070424213127] [Follow Cabal changes in Setup.hs Ian Lynagh **20070418114345] [inclusion of libc.h is conditional on __APPLE__ Malcolm.Wallace@cs.york.ac.uk**20070417085556] [MERGE: fix ugly uses of memcpy foreign import inside ST Simon Marlow **20070416101530 fixes cg026 ] [Fix configure with no --with-cc Ian Lynagh **20070415165143] [MacOS 10.3 needs #include as well Malcolm.Wallace@cs.york.ac.uk**20070414155507] [For nhc98 only, use hsc2hs to determine System.Posix.Types. Malcolm.Wallace@cs.york.ac.uk**20070413155831 Avoids the existing autoconf stuff, by introducing an auxiliary module called NHC.PosixTypes that uses hsc2hs, which is then simply re-exported from System.Posix.Types. ] [we need a makefileHook too Simon Marlow **20070413151307] [Remove unnecesary SOURCE import of GHC.Err in GHC.Pack Ian Lynagh **20070412235908] [add System.Posix.Types to default nhc98 build Malcolm.Wallace@cs.york.ac.uk**20070412195026] [mark System.IO.openTempFile as non-portable in haddocks Malcolm.Wallace@cs.york.ac.uk**20070412135359] [Don't turn on -Werror in Data.Fixed Ian Lynagh **20070411155721 This may be responsible for the x86_64/Linux nightly build failing. ] [Fix -Wall warnings Ian Lynagh **20070411004929] [Add missing case in removePrefix Ian Lynagh **20070411002537] [Allow additional options to pass on to ./configure to be given Ian Lynagh **20070406151856] [Hugs only: fix location of unsafeCoerce Ross Paterson **20070406113731] [fix isPortableBuild test Ross Paterson **20070406111304] [Unsafe.Coerce doesn't need Prelude Ian Lynagh **20070405175930] [make Setup and base.cabal suitable for building the libraries with GHC Ian Lynagh **20070308163824] [HsByteArray doesn't exist Ian Lynagh **20070404163051] [Don't use Fd/FD in foreign decls Ian Lynagh **20070404155822 Using CInt makes it much easier to verify that it is right, and we won't get caught out by possible newtype switches between CInt/Int. ] [HsByteArray doesn't exist Ian Lynagh **20070404155732] [Fix braino Ian Lynagh **20070404144508] [Fix incorrect changes to C types in a foreign import for nhc98. Malcolm.Wallace@cs.york.ac.uk**20070404120954 If we use type CTime, it needs to be imported. Also, CTime is not an instance of Integral, so use some other mechanism to convert it. ] [Fix C/Haskell type mismatches Ian Lynagh **20070403194943] [add new module Unsafe.Coerce to build system Malcolm.Wallace@cs.york.ac.uk**20070403131333] [Fix type mismatches between foreign imports and HsBase.h Ian Lynagh **20070403001611 Merge to stable, checking for interface changes. ] [put 'unsafeCoerce' in a standard location Malcolm.Wallace@cs.york.ac.uk**20061113114103] [fix for nhc98 build Malcolm.Wallace@cs.york.ac.uk**20070402141712] [Function crossMapP for fixing desugaring of comprehensions Manuel M T Chakravarty **20070402082906 Merge into 6.6 branch. ] [Add min/max handling operations for IntSet/IntMap jeanphilippe.bernardy@gmail.com**20070315072352] [Monoid instance for Maybe and two wrappers: First and Last. trac proposal #1189 Jeffrey Yasskin **20070309062550] [Fix the type of wgencat Ian Lynagh **20070329164223] [fix strictness of foldr/build rule for take, see #1219 Simon Marlow **20070327103941] [remove Makefile.inc (only affects nhc98) Malcolm.Wallace@cs.york.ac.uk**20070320120057] [copyBytes copies bytes, not elements; fixes trac #1203 Ian Lynagh **20070312113555] [Add ioeGetLocation, ioeSetLocation to System/IO/Error.hs; trac #1191 Ian Lynagh **20070304130315] [fix race condition in prodServiceThread Simon Marlow **20070307134330 See #1187 ] [Prevent duplication of unsafePerformIO on a multiprocessor Simon Marlow **20070306145424 Fixes #986. The idea is to add a new operation noDuplicate :: IO () it is guaranteed that if two threads have executed noDuplicate, then they are not duplicating any computation. We now provide two new unsafe operations: unsafeDupablePerformIO :: IO a -> a unsafeDupableInterleaveIO :: IO a -> IO a which are equivalent to the old unsafePerformIO and unsafeInterleaveIO respectively. The new versions of these functions are defined as: unsafePerformIO m = unsafeDupablePerformIO (noDuplicate >> m) unsafeInterleaveIO m = unsafeDupableInterleaveIO (noDuplicate >> m) ] [expand docs for forkOS Simon Marlow **20070305160921] [document timeout limitations Peter Simons **20070228223540] [So many people were involved in the writing of this module that Peter Simons **20070228223415 it feels unfair to single anyone out as the lone copyright holder. ] [This patch adds a timeout function to the base libraries. Trac #980 is Peter Simons **20070126222615 concerned with this issue. The design guideline for this implementation is that 'timeout N E' should behave exactly the same as E as long as E doesn't time out. In our implementation, this means that E has the same myThreadId it would have without the timeout wrapper. Any exception E might throw cancels the timeout and propagates further up. It also possible for E to receive exceptions thrown to it by another thread. ] [PArr: fixed permutations Manuel M T Chakravarty **20070305055807] [Add Data.String, containing IsString(fromString); trac proposal #1126 Ian Lynagh **20070130134841 This is used by the overloaded strings extension (-foverloaded-strings in GHC). ] [GHC.PArr: add bounds checking Manuel M T Chakravarty **20070302053224] [Bump nhc98 stack size for System/Time.hsc sven.panne@aedion.de**20070301153009] [FDs are CInts now, fixing non-GHC builds sven.panne@aedion.de**20070225105620] [Fixed PArr.dropP Manuel M T Chakravarty **20070222032405 - Thanks to Audrey Tang for the bug report ] [Keep the same FD in both halves of a duplex handle when dup'ing Ian Lynagh **20070220141039 Otherwise we only close one of the FDs when closing the handle. Fixes trac #1149. ] [Remove more redundant FD conversions Ian Lynagh **20070220092520] [Fix FD changes on Windows Ian Lynagh **20070220091516] [Consistently use CInt rather than Int for FDs Ian Lynagh **20070219233854] [Fix the types of minView/maxView (ticket #1134) jeanphilippe.bernardy@gmail.com**20070210065115] [fix for hashString, from Jan-Willem Maessen (see #1137) Simon Marlow **20070215094304 ] [fix to getUSecOfDay(): arithmetic was overflowing Simon Marlow **20070214161719] [The Windows counterpart to 'wrapround of thread delays' Ian Lynagh **20070209173510] [wrapround of thread delays Neil Davies **20070129160519 * made the wrapround of the underlying O/S occur before the wrapround of the delayed threads by making threads delay in microseconds since O/S epoch (1970 - Unix, 1601 - Windows) stored in Word64. * removed redundant calls reading O/S realtime clock * removed rounding to 1/50th of sec for timers * Only for Unix version of scheduler. ] [Whitespace changes only Ian Lynagh **20070206232722] [Add some type sigs Ian Lynagh **20070206232439] [Use static inline rather than extern inline/inline Ian Lynagh **20070205203628 I understand this is more portable, and it also fixes warnings when C things we are wrapping are themselves static inlines (which FD_ISSET is on ppc OS X). ] [add derived instances for Dual monoid Ross Paterson **20070202190847] [add doc pointers to Foldable Ross Paterson **20070202110931 Could be applied to STABLE. ] [Eliminate some warnings Ian Lynagh **20060729220854 Eliminate warnings in the libraries caused by mixing pattern matching with numeric literal matching. ] [Remove IsString(fromString) from the Prelude Ian Lynagh **20070130124136] [Add Kleisli composition Don Stewart **20061113015442] [IsString is GHC-only (so why is it in the Prelude?) Ross Paterson **20070123183007] [Applicative and Monad instances for Tree Ross Paterson **20070115174510] [Add IsString class for overloaded string literals. lennart@augustsson.net**20061221210532] [Added examples, more detailed documentation to Data.List Extracting sublists functions Andriy Palamarchuk **20061204164710] [fix threadDelay Simon Marlow **20070117091702 In "Add support for the IO manager thread" I accidentally spammed part of "Make sure the threaded threadDelay sleeps at least as long as it is asked", which is why the ThreadDelay001 test has been failing. ] [update section on "blocking" Simon Marlow **20070116124328] [Fix crash with (minBound :: Int*) `div (-1) as result is maxBound + 1. Ian Lynagh **20070115142005] [version of example using Tomasz Zielonka's technique Ross Paterson **20070105175907] [Added Unknowns for higher kinds Pepe Iborra **20061108155938] [Improved the Show instance for Unknown Pepe Iborra **20060813111816] [Show instance for GHC.Base.Unknown mnislaih@gmail.com**20060801233530] [Introduce Unknowns for the closure viewer. Add breakpointCond which was missing mnislaih@gmail.com**20060725174537] [Fix missing comma in Fractional documentation Alec Berryman **20061201173237] [Mention that throwTo does not guarantee promptness of delivery simonpj@microsoft**20061211123215] [Add note about synhronous delivery of throwTo simonpj@microsoft**20061211122257] [documentation for installHandler Simon Marlow **20061205154927 merge to 6.6 ] [dos2unix Simon Marlow **20061204095439] [don't try to compile this on Unix Simon Marlow **20061204095427] [TAG 6.6 release Ian Lynagh **20061011124740] [TAG Version 2.1 Ian Lynagh **20061009114014] [Bump version number Ian Lynagh **20061009114009] [Add support for the IO manager thread on Windows Simon Marlow **20061201152042 Fixes #637. The test program in that report now works for me with -threaded, but it doesn't work without -threaded (I don't know if that's new behaviour or not, though). ] [deriving (Eq, Ord, Enum, Show, Read, Typeab) for ConsoleEvent Simon Marlow **20061201144032] [Make sure the threaded threadDelay sleeps at least as long as it is asked to Ian Lynagh **20061128204807] [Add comments about argument order to the definitions of gmapQ and constrFields simonpj@microsoft**20061124164505] [Hugs: add Control.Parallel.Strategies Ross Paterson **20061124161039] [Move instance of Show Ptr to Ptr.hs (fewer orphans) simonpj@microsoft.com**20061124100639] [Add type signatures simonpj@microsoft.com**20061124100621] [Add an example of the use of unfoldr, following doc feedback from dozer Don Stewart **20061124011249] [trim imports Ross Paterson **20061123190352] [Data.Graph is now portable (enable for nhc98) Malcolm.Wallace@cs.york.ac.uk**20061123174913] [remove Data.FunctorM and Data.Queue Ross Paterson **20061112001046 These were deprecated in 6.6, and can thus be removed in 6.8. ] [make Data.Graph portable (no change to the interface) Ross Paterson **20061122010040 The algorithm now uses STArrays on GHC and IntSets elsewhere. (Hugs has STArrays, but avoiding them saves a -98, and boxed arrays aren't fast under Hugs anyway.) ] [One less unsafeCoerce# in the tree Don Stewart **20061120120242] [typo in comment Ross Paterson **20061120115106] [fix shift docs to match ffi spec Ross Paterson **20061117003144] [(nhc98) use new primitive implementations of h{Put,Get}Buf. Malcolm.Wallace@cs.york.ac.uk**20061116173104] [The wrong 'cycle' was exported from Data.ByteString.Lazy.Char8, spotted by sjanssen Don Stewart **20061110021311] [LPS chunk sizes should be 16 bytes, not 17. Don Stewart **20061110021254] [Update comments on Prelude organisation in GHC/Base.lhs Ian Lynagh **20061115001926] [Control.Parallel.Strategies clean-up: Added export list to avoid exporting seq, fixed import list strangeness that haddock choked on, and moved the deprecated functions to a separate section. bringert@cs.chalmers.se**20061113224202] [Control.Parallel.Strategies: added NFData instances for Data.Int.*, Data.Word.*, Maybe, Either, Map, Set, Tree, IntMap, IntSet. bringert@cs.chalmers.se**20061113221843] [Control.Parallel.Strategies: deprecate sPar, sSeq, Assoc, fstPairFstList, force and sforce. bringert@cs.chalmers.se**20061113215219 Code comments indicated that sPar and sSeq have been superceded by sparking and demanding, and that Assoc, fstPairFstList, force and sforce are examples and hacks needed by the Lolita system. ] [add Control.Monad.Instances to nhc98 build Malcolm.Wallace@cs.york.ac.uk**20061113113221] [Control.Parallel.Strategies: clarified documentation of parListChunk. bringert@cs.chalmers.se**20061112232904] [Added and cleaned up Haddock comments in Control.Parallel.Strategies. bringert@cs.chalmers.se**20061112220445 Many of the definitions in Control.Parallel.Strategies had missing or unclear Haddock comments. I converted most of the existing plain code comments to haddock comments, added some missing documentation and cleaned up the existing Haddock mark-up. ] [Fix broken pragmas; spotted by Bulat Ziganshin Ian Lynagh **20061111205916] [add doc link to bound threads section Ross Paterson **20060929103252] [hide Data.Array.IO.Internals Ross Paterson **20061111113248 It's hidden from haddock, and everything it exports is re-exported by Data.Array.IO. ] [add Data.Function Malcolm.Wallace@cs.york.ac.uk**20061110142710] [add Data.Function Ross Paterson **20061110141354] [whitespace only Ross Paterson **20061110141326] [move fix to Data.Function Ross Paterson **20061110141120] [import Prelude Ross Paterson **20061110140445] [Added Data.Function (Trac ticket #979). Nils Anders Danielsson **20061110122503 + A module with simple combinators working solely on and with functions. + The only new function is "on". + Some functions from the Prelude are re-exported. ] [__hscore_long_path_size is not portable beyond GHC Malcolm.Wallace@cs.york.ac.uk**20061110113222] [redefine writeFile and appendFile using withFile Ross Paterson **20061107140359] [add withFile and withBinaryFile (#966) Ross Paterson **20061107134510] [remove conflicting import for nhc98 Malcolm.Wallace@cs.york.ac.uk**20061108111215] [Add intercalate to Data.List (ticket #971) Josef Svenningsson **20061102122052] [non-GHC: fix canonicalizeFilePath Ross Paterson **20061107133902 I've also removed the #ifdef __GLASGOW_HASKELL__ from the proper Windows versions of a few functions. These will need testing with Hugs on Windows. ] [enable canonicalizePath for non-GHC platforms Simon Marlow **20061107121141] [Update documentation for hWaitForInput Simon Marlow **20061107111430 See #972 Merge to 6.6 branch. ] [Use unchecked shifts to implement Data.Bits.rotate Samuel Bronson **20061012125553 This should get rid of those cases, maybe lower the size enough that the inliner will like it? ] [fix Haddock module headers Ross Paterson **20061106124140] [fix example in docs Ross Paterson **20061106115628] [Add intercalate and split to Data.List Josef Svenningsson *-20061024172357] [Data.Generics.Basics is GHC-only Ross Paterson **20061102111736] [#ifdef around non-portable Data.Generics.Basics Malcolm.Wallace@cs.york.ac.uk**20061102103445] [Add deriving Data to Complex simonpj@microsoft**20061101102059] [minor clarification of RandomGen doc Ross Paterson **20061030230842] [rearrange docs a bit Ross Paterson **20061030161223] [Add intercalate and split to Data.List Josef Svenningsson **20061024172357] [Export pseq from Control.Parallel, and use it in Control.Parallel.Strategies Simon Marlow **20061027150141] [`par` should be infixr 0 Simon Marlow **20061027130800 Alas, I didn't spot this due to lack of testing, and the symptom is that an expression like x `par` y `seq z will have exactly the wrong parallelism properties. The workaround is to add parantheses. I think we could push this to the 6.6 branch. ] [fix example in comment Ross Paterson **20061023163925] [Use the new Any type for dynamics (GHC only) simonpj@microsoft**20061019160408] [add Data.Sequence to nhc98 build Malcolm.Wallace@cs.york.ac.uk**20061012135200] [Remove Data.FiniteMap, add Control.Applicative, Data.Traversable, and Malcolm.Wallace@cs.york.ac.uk**20061012095605 Data.Foldable to the nhc98 build. ] [STM invariants tharris@microsoft.com**20061007123253] [Inline shift in GHC's Bits instances for {Int,Word}{,8,16,32,64} Samuel Bronson **20061009020906] [Don't create GHC.Prim when bootstrapping; we can't, and we don't need it Ian Lynagh **20061004165355] [Data.ByteString: fix lazyness of take, drop & splitAt Don Stewart **20061005011703 ByteString.Lazy's take, drop and splitAt were too strict when demanding a byte string. Spotted by Einar Karttunen. Thanks to him and to Bertram Felgenhauer for explaining the problem and the fix. ] [Fix syntax error that prevents building Haddock documentation on Windows brianlsmith@gmail.com**20060917013530] [Hugs only: unbreak typeRepKey Ross Paterson **20060929102743] [make hGetBufNonBlocking do something on Windows w/ -threaded Simon Marlow **20060927145811 hGetBufNonBlocking will behave the same as hGetBuf on Windows now, which is better than just crashing (which it did previously). ] [add typeRepKey :: TypeRep -> IO Int Simon Marlow **20060927100342 See feature request #880 ] [fix header comment Ross Paterson **20060926135843] [Add strict versions of insertWith and insertWithKey (Data.Map) jeanphilippe.bernardy@gmail.com**20060910162443] [doc tweaks, including more precise equations for evaluate Ross Paterson **20060910115259] [Sync Data.ByteString with stable branch Don Stewart **20060909050111 This patch: * hides the LPS constructor (its in .Base if you need it) * adds functions to convert between strict and lazy bytestrings * and adds readInteger ] [Typeable1 instances for STM and TVar Ross Paterson **20060904231425] [remove obsolete Hugs stuff Ross Paterson **20060904223944] [Cleaner isInfixOf suggestion from Ross Paterson John Goerzen **20060901143654] [New function isInfixOf that searches a list for a given sublist John Goerzen **20060831151556 Example: isInfixOf "Haskell" "I really like Haskell." -> True isInfixOf "Ial" "I really like Haskell." -> False This function was first implemented in MissingH as MissingH.List.contains ] [Better doc on Data.Map.lookup: explain what the monad is for jeanphilippe.bernardy@gmail.com**20060903133440] [fix hDuplicateTo on Windows Simon Marlow **20060901150016 deja vu - I'm sure I remember fixing this before... ] [Improve documentation of atomically simonpj@microsoft**20060714120207] [Add missing method genRange for StdGen (fixes #794) simonpj@microsoft**20060707151901 MERGE TO STABLE Trac #794 reports (correctly) that the implementation of StdGen only returns numbers in the range (0..something) rather than (minBound, maxBound), which is what StdGen's genRange claims. This commit fixes the problem, by implementing genRange for StdGen (previously it just used the default method). ] [mark nhc98 import hack Ross Paterson **20060831125219] [remove some outdated comments Simon Marlow **20060831104200] [import Control.Arrow.ArrowZero to help nhc98's type checker Malcolm.Wallace@cs.york.ac.uk**20060831101105] [remove Text.Regex(.Posix) from nhc98 build Malcolm.Wallace@cs.york.ac.uk**20060831101016] [add Data.Foldable.{msum,asum}, plus tweaks to comments Ross Paterson **20060830163521] [fix doc typo Ross Paterson **20060830134123] [add Data.Foldable.{for_,forM_} and Data.Traversable.{for,forM} Ross Paterson **20060830133805 generalizing Control.Monad.{forM_,forM} ] [Make length a good consumer simonpj@microsoft*-20060508142726 Make length into a good consumer. Fixes Trac bug #707. (Before length simply didn't use foldr.) ] [Add Control.Monad.forM and forM_ Don Stewart **20060824081118 flip mapM_ is more and more common, I find. Several suggestions have been made to add this, as foreach or something similar. This patch does just that: forM :: (Monad m) => [a] -> (a -> m b) -> m [b] forM_ :: (Monad m) => [a] -> (a -> m b) -> m () So we can write: Prelude Control.Monad> forM_ [1..4] $ \x -> print x 1 2 3 4 ] [Hide internal module from haddock in Data.ByteString Don Stewart **20060828011515] [add advice on avoiding import ambiguities Ross Paterson **20060827170407] [expand advice on importing these modules Ross Paterson **20060827164044] [add Haddock marker Ross Paterson **20060827115140] [Clarify how one hides Prelude.catch Don Stewart **20060826124346 User feedback indicated that an example was required, of how to hide Prelude.catch, so add such an example to the docs ] [Workaround for OSes that don't have intmax_t and uintmax_t Ian Lynagh **20060825134936 OpenBSD (and possibly others) do not have intmax_t and uintmax_t types: http://www.mail-archive.com/haskell-prime@haskell.org/msg01548.html so substitute (unsigned) long long if we have them, otherwise (unsigned) long. ] [add docs for par Simon Marlow **20060825110610] [document minimal complete definition for Bits Ross Paterson **20060824140504] [C regex library bits have moved to the regex-posix package Simon Marlow **20060824132311] [Add shared Typeable support (ghc only) Esa Ilari Vuokko **20060823003126] [this should have been removed with the previous patch Simon Marlow **20060824121223] [remove Text.Regx & Text.Regex.Posix Simon Marlow **20060824094615 These are subsumed by the new regex-base, regex-posix and regex-compat packages. ] [explicitly tag Data.ByteString rules with the FPS prefix. Don Stewart **20060824041326] [Add spec rules for sections in Data.ByteString Don Stewart **20060824012611] [Sync Data.ByteString with current stable branch, 0.7 Don Stewart **20060823143338] [add notes about why copyFile doesn't remove the target Simon Marlow **20060823095059] [copyFile: try removing the target file before opening it for writing Simon Marlow *-20060822121909] [copyFile: try removing the target file before opening it for writing Simon Marlow **20060822121909] [add alternative functors and extra instances Ross Paterson **20060821152151 * Alternative class, for functors with a monoid * instances for Const * instances for arrows ] [generate Haddock docs on all platforms Simon Marlow **20060821131612] [remove extra comma from import Ross Paterson **20060819173954] [fix docs for withC(A)StringLen Ross Paterson **20060818170328] [use Haskell'98 compliant indentation in do blocks Malcolm.Wallace@cs.york.ac.uk**20060818130810] [use correct names of IOArray operations for nhc98 Malcolm.Wallace@cs.york.ac.uk**20060818130714] [add mapMaybe and mapEither, plus WithKey variants Ross Paterson **20060817235041] [remove Text.Html from nhc98 build Malcolm.Wallace@cs.york.ac.uk**20060817135502] [eliminate more HOST_OS tests Ross Paterson **20060815190609] [Hugs only: disable unused process primitives Ross Paterson **20060813184435 These were the cause of Hugs bug #30, I think, and weren't used by Hugs anyway. ] [markup fix to Data.HashTable Ross Paterson **20060812103835] [revert removal of ghcconfig.h from package.conf.in Ross Paterson **20060812082702 as it's preprocessed with -undef (pointed out by Esa Ilari Vuokko) ] [fix Data.HashTable for non-GHC Ross Paterson **20060811231521] [remove deprecated 'withObject' Simon Marlow **20060811152350] [Jan-Willem Maessen's improved implementation of Data.HashTable Simon Marlow **20060811151024 Rather than incrementally enlarging the hash table, this version just does it in one go when the table gets too full. ] [Warning police: Make some prototypes from the RTS known sven.panne@aedion.de**20060811144629] [Warning police: Removed useless catch-all clause sven.panne@aedion.de**20060811142208] [reduce dependency on ghcconfig.h Ross Paterson **20060811124030 The only remaining use is in cbits/dirUtils.h, which tests solaris2_HOST_OS (Also System.Info uses ghcplatform.h and several modules import MachDeps.h to get SIZEOF_* and ALIGNMENT_* from ghcautoconf.h) ] [(non-GHC only) track MArray interface change Ross Paterson **20060810182902] [move Text.Html to a separate package Simon Marlow **20060810113017] [bump version to 2.0 Simon Marlow **20060810112833] [Remove deprecated Data.FiniteMap and Data.Set interfaces Simon Marlow **20060809153810] [move altzone test from ghc to base package Ross Paterson **20060809124259] [remove unnecessary #include "ghcconfig.h" Ross Paterson **20060809123812] [Change the API of MArray to allow resizable arrays Simon Marlow **20060809100548 See #704 The MArray class doesn't currently allow a mutable array to change its size, because of the pure function bounds :: (HasBounds a, Ix i) => a i e -> (i,i) This patch removes the HasBounds class, and adds getBounds :: (MArray a e m, Ix i) => a i e -> m (i,i) to the MArray class, and bounds :: (IArray a e, Ix i) => a i e -> (i,i) to the IArray class. The reason that bounds had to be incorporated into the IArray class is because I couldn't make DiffArray work without doing this. DiffArray acts as a layer converting an MArray into an IArray, and there was no way (that I could find) to define an instance of HasBounds for DiffArray. ] [deprecate this module. Simon Marlow **20060808100708] [add traceShow (see #474) Simon Marlow **20060807155545] [remove spurious 'extern "C" {' Simon Marlow **20060724160258] [Fix unsafeIndex for large ranges Simon Marlow **20060721100225] [disambiguate uses of foldr for nhc98 to compile without errors Malcolm.Wallace@cs.york.ac.uk**20060711161614] [make Control.Monad.Instances compilable by nhc98 Malcolm.Wallace@cs.york.ac.uk**20060711160941] [breakpointCond Lemmih **20060708055528] [UNDO: Merge "unrecognized long opt" fix from 6.4.2 Simon Marlow **20060705142537 This patch undid the previous patch, "RequireOrder: do not collect unrecognised options after a non-opt". I asked Sven to revert it, but didn't get an answer. See bug #473. ] [Avoid strictness in accumulator for unpackFoldr Don Stewart **20060703091806 The seq on the accumulator for unpackFoldr will break in the presence of head/build rewrite rules. The empty list case will be forced, producing an exception. This is a known issue with seq and rewrite rules that we just stumbled on to. ] [Disable unpack/build fusion Don Stewart **20060702083913 unpack/build on bytestrings seems to trigger a bug when interacting with head/build fusion in GHC.List. The bytestring001 testcase catches it. I'll investigate further, but best to disable this for now (its not often used anyway). Note that with -frules-off or ghc 6.4.2 things are fine. It seems to have emerged with the recent rules changes. ] [Import Data.ByteString.Lazy, improve ByteString Fusion, and resync with FPS head Don Stewart **20060701084345 This patch imports the Data.ByteString.Lazy module, and its helpers, providing a ByteString implemented as a lazy list of strict cache-sized chunks. This type allows the usual lazy operations to be written on bytestrings, including lazy IO, with much improved space and time over the [Char] equivalents. ] [Wibble in docs for new ForeignPtr functionsn Don Stewart **20060609075924] [comments for Applicative and Traversable Ross Paterson **20060622170436] [default to NoBuffering on Windows for a read/write text file Simon Marlow **20060622144446 Fixes (works around) #679 ] [remove dead code Simon Marlow **20060622144433] [clarify and expand docs Simon Marlow **20060622112911] [Add minView and maxView to Map and Set jeanphilippe.bernardy@gmail.com**20060616180121] [add signature for registerDelay Ross Paterson **20060614114456] [a few doc comments Ross Paterson **20060613142704] [Optimised foreign pointer representation, for heap-allocated objects Don Stewart **20060608015011] [Add the inline function, and many comments simonpj@microsoft.com**20060605115814 This commit adds the 'inline' function described in the related patch in the compiler. I've also added comments about the 'lazy' function. ] [small intro to exceptions Ross Paterson **20060525111604] [export breakpoint Simon Marlow **20060525090456] [Merge in changes from fps head. Highlights: Don Stewart **20060525065012 Wed May 24 15:49:38 EST 2006 sjanssen@cse.unl.edu * instance Monoid ByteString Wed May 24 15:04:04 EST 2006 Duncan Coutts * Rearange export lists for the .Char8 modules Wed May 24 14:59:56 EST 2006 Duncan Coutts * Implement mapAccumL and reimplement mapIndexed using loopU Wed May 24 14:47:32 EST 2006 Duncan Coutts * Change the implementation of the unfoldr(N) functions. Use a more compact implementation for unfoldrN and change it's behaviour to only return Just in the case that it actually 'overflowed' the N, so the boundary case of unfolding exactly N gives Nothing. Implement unfoldr and Lazy.unfoldr in terms of unfoldrN. Use fibonacci growth for the chunk size in unfoldr Wed May 24 08:32:29 EST 2006 sjanssen@cse.unl.edu * Add unfoldr to ByteString and .Char8 A preliminary implementation of unfoldr. Wed May 24 01:39:41 EST 2006 Duncan Coutts * Reorder the export lists to better match the Data.List api Tue May 23 14:04:32 EST 2006 Don Stewart * pack{Byte,Char} -> singleton. As per fptools convention Tue May 23 14:00:51 EST 2006 Don Stewart * elemIndexLast -> elemIndexEnd Tue May 23 13:57:34 EST 2006 Don Stewart * In the search for a more orthogonal api, we kill breakFirst/breakLast, which were of dubious value Tue May 23 12:24:09 EST 2006 Don Stewart * Abolish elems. It's name implied it was unpack, but its type didn't. it made no sense Tue May 23 10:42:09 EST 2006 Duncan Coutts * Minor doc tidyup. Use haddock markup better. Tue May 23 11:00:31 EST 2006 Don Stewart * Simplify the join() implementation. Spotted by Duncan. ] [add a way to ask the IO manager thread to exit Simon Marlow **20060524121823] [Sync with FPS head, including the following patches: Don Stewart **20060520030436 Thu May 18 15:45:46 EST 2006 sjanssen@cse.unl.edu * Export unsafeTake and unsafeDrop Fri May 19 11:53:08 EST 2006 Don Stewart * Add foldl1' Fri May 19 13:41:24 EST 2006 Don Stewart * Add fuseable scanl, scanl1 + properties Fri May 19 18:20:40 EST 2006 Don Stewart * Spotted another chance to use unsafeTake,Drop (in groupBy) Thu May 18 09:24:25 EST 2006 Duncan Coutts * More effecient findIndexOrEnd based on the impl of findIndex Thu May 18 09:22:49 EST 2006 Duncan Coutts * Eliminate special case in findIndex since it's handled anyway. Thu May 18 09:19:08 EST 2006 Duncan Coutts * Add unsafeTake and unsafeDrop These versions assume the n is in the bounds of the bytestring, saving two comparison tests. Then use them in varous places where we think this holds. These cases need double checking (and there are a few remaining internal uses of take / drop that might be possible to convert). Not exported for the moment. Tue May 16 23:15:11 EST 2006 Don Stewart * Handle n < 0 in drop and splitAt. Spotted by QC. Tue May 16 22:46:22 EST 2006 Don Stewart * Handle n <= 0 cases for unfoldr and replicate. Spotted by QC Tue May 16 21:34:11 EST 2006 Don Stewart * mapF -> map', filterF -> filter' ] [haddock fix Ross Paterson **20060518154723] [simplify indexing in Data.Sequence Ross Paterson **20060518154316] [Move Eq, Ord, Show instances for ThreadId to GHC.Conc Simon Marlow **20060518113339 Eliminates orphans. ] [Better error handling in the IO manager thread Simon Marlow **20060518113303 In particular, handle EBADF just like rts/posix/Select.c, by waking up all the waiting threads. Other errors are thrown, instead of just being ignored. ] [#define _REENTRANT 1 (needed to get the right errno on some OSs) Simon Marlow **20060518104151 Part 2 of the fix for threaded RTS problems on Solaris and possibly *BSD (Part 1 was the same change in ghc/includes/Rts.h). ] [copyCString* should be in IO. Spotted by Tomasz Zielonka Don Stewart **20060518012154] [add import Prelude to get dependencies right for Data/Fixed.hs Duncan Coutts **20060517222044 Hopefully this fixes parallel builds. ] [Fix negative index handling in splitAt, replicate and unfoldrN. Move mapF, filterF -> map', filter' while we're here Don Stewart **20060517020150] [Use our own realloc. Thus reduction functions (like filter) allocate on the Haskell heap. Makes around 10% difference. Don Stewart **20060513051736] [Last two CInt fixes for 64 bit, and bracket writeFile while we're here Don Stewart **20060512050750] [Some small optimisations, generalise the type of unfold Don Stewart **20060510043309 Tue May 9 22:36:29 EST 2006 Duncan Coutts * Surely the error function should not be inlined. Tue May 9 22:35:53 EST 2006 Duncan Coutts * Reorder memory writes for better cache locality. Tue May 9 23:28:09 EST 2006 Duncan Coutts * Generalise the type of unfoldrN The type of unfoldrN was overly constrained: unfoldrN :: Int -> (Word8 -> Maybe (Word8, Word8)) -> Word8 -> ByteString if we compare that to unfoldr: unfoldr :: (b -> Maybe (a, b)) -> b -> [a] So we can generalise unfoldrN to this type: unfoldrN :: Int -> (a -> Maybe (Word8, a)) -> a -> ByteString and something similar for the .Char8 version. If people really do want to use it a lot with Word8/Char then perhaps we should add a specialise pragma. Wed May 10 13:26:40 EST 2006 Don Stewart * Add foldl', and thus a fusion rule for length . {map,filter,fold}, that avoids creating an array at all if the end of the pipeline is a 'length' reduction **END OF DESCRIPTION*** Place the long patch description above the ***END OF DESCRIPTION*** marker. The first line of this file will be the patch name. This patch contains the following changes: M ./Data/ByteString.hs -8 +38 M ./Data/ByteString/Char8.hs -6 +12 ] [portable implementation of WordPtr/IntPtr for non-GHC Ross Paterson **20060510001826 plus much tweaking of imports to avoid cycles ] [add WordPtr and IntPtr types to Foreign.Ptr, with associated conversions Simon Marlow **20060509092606 As suggested by John Meacham. I had to move the Show instance for Ptr into GHC.ForeignPtr to avoid recursive dependencies. ] [add CIntPtr, CUIntPtr, CIntMax, CUIntMax types Simon Marlow **20060509092427] [add GHC.Dynamic Simon Marlow **20060509082739] [Two things. #if defined(__GLASGOW_HASKELL__) on INLINE [n] pragmas (for jhc). And careful use of INLINE on words/unwords halves runtime for those functions Don Stewart **20060509023425] [Make length a good consumer simonpj@microsoft**20060508142726 Make length into a good consumer. Fixes Trac bug #707. (Before length simply didn't use foldr.) ] [Trim imports simonpj@microsoft**20060508142557] [Make unsafePerformIO lazy simonpj@microsoft**20060508142507 The stricteness analyser used to have a HACK which ensured that NOINLNE things were not strictness-analysed. The reason was unsafePerformIO. Left to itself, the strictness analyser would discover this strictness for unsafePerformIO: unsafePerformIO: C(U(AV)) But then consider this sub-expression unsafePerformIO (\s -> let r = f x in case writeIORef v r s of (# s1, _ #) -> (# s1, r #) The strictness analyser will now find that r is sure to be eval'd, and may then hoist it out. This makes tests/lib/should_run/memo002 deadlock. Solving this by making all NOINLINE things have no strictness info is overkill. In particular, it's overkill for runST, which is perfectly respectable. Consider f x = runST (return x) This should be strict in x. So the new plan is to define unsafePerformIO using the 'lazy' combinator: unsafePerformIO (IO m) = lazy (case m realWorld# of (# _, r #) -> r) Remember, 'lazy' is a wired-in identity-function Id, of type a->a, which is magically NON-STRICT, and is inlined after strictness analysis. So unsafePerformIO will look non-strict, and that's what we want. ] [Sync with FPS head. Don Stewart **20060508122322 Mon May 8 10:40:14 EST 2006 Don Stewart * Fix all uses for Int that should be CInt or CSize in ffi imports. Spotted by Igloo, dcoutts Mon May 8 16:09:41 EST 2006 Don Stewart * Import nicer loop/loop fusion rule from ghc-ndp Mon May 8 17:36:07 EST 2006 Don Stewart * Fix stack leak in split on > 60M strings Mon May 8 17:50:13 EST 2006 Don Stewart * Try same fix for stack overflow in elemIndices ] [Fix all uses for Int that should be CInt or CSize in ffi imports. Spotted by Duncan and Ian Don Stewart **20060508010311] [Fixed import list syntax Sven Panne **20060507155008] [Faster filterF, filterNotByte dons@cse.unsw.edu.au**20060507042301] [Much faster find, findIndex. Hint from sjanssen dons@cse.unsw.edu.au**20060507033048] [Merge "unrecognized long opt" fix from 6.4.2 Sven Panne **20060506110519] [ dons@cse.unsw.edu.au**20060506061029 Sat May 6 13:01:34 EST 2006 Don Stewart * Do loopU realloc on the Haskell heap. And add a really tough stress test Sat May 6 12:28:58 EST 2006 Don Stewart * Use simple, 3x faster concat. Plus QC properties. Suggested by sjanssen and dcoutts Sat May 6 15:59:31 EST 2006 Don Stewart * dcoutt's packByte bug squashed With inlinePerformIO, ghc head was compiling: packByte 255 `compare` packByte 127 into roughly case mallocByteString 2 of ForeignPtr f internals -> case writeWord8OffAddr# f 0 255 of _ -> case writeWord8OffAddr# f 0 127 of _ -> case eqAddr# f f of False -> case compare (GHC.Prim.plusAddr# f 0) (GHC.Prim.plusAddr# f 0) which is rather stunning. unsafePerformIO seems to prevent whatever magic inlining was leading to this. Only affected the head. ] [Add array fusion versions of map, filter and foldl dons@cse.unsw.edu.au**20060505060858 This patch adds fusable map, filter and foldl, using the array fusion code for unlifted, flat arrays, from the Data Parallel Haskell branch, after kind help from Roman Leshchinskiy, Pipelines of maps, filters and folds should now need to walk the bytestring once only, and intermediate bytestrings won't be constructed. ] [fix for non-GHC Ross Paterson **20060504093044] [use bracket in appendFile (like writeFile) Ross Paterson **20060504091528] [writeFile: close the file on error Simon Marlow **20060504084505 Suggested by Ross Paterson, via Neil Mitchell ] [Sync with FPS head dons@cse.unsw.edu.au**20060503105259 This patch brings Data.ByteString into sync with the FPS head. The most significant of which is the new Haskell counting sort. Changes: Sun Apr 30 18:16:29 EST 2006 sjanssen@cse.unl.edu * Fix foldr1 in Data.ByteString and Data.ByteString.Char8 Mon May 1 11:51:16 EST 2006 Don Stewart * Add group and groupBy. Suggested by conversation between sjanssen and petekaz on #haskell Mon May 1 16:42:04 EST 2006 sjanssen@cse.unl.edu * Fix groupBy to match Data.List.groupBy. Wed May 3 15:01:07 EST 2006 sjanssen@cse.unl.edu * Migrate to counting sort. Data.ByteString.sort used C's qsort(), which is O(n log n). The new algorithm is O(n), and is faster for strings larger than approximately thirty bytes. We also reduce our dependency on cbits! ] [improve performance of Integer->String conversion Simon Marlow **20060503113306 See http://www.haskell.org//pipermail/libraries/2006-April/005227.html Submitted by: bertram.felgenhauer@googlemail.com ] [inline withMVar, modifyMVar, modifyMVar_ Simon Marlow **20060503111152] [Fix string truncating in hGetLine -- it was a pasto from Simon's code Simon Marlow **20060503103504 (from Don Stewart) ] [Merge in Data.ByteString head. Fixes ByteString+cbits in hugs Don Stewart **20060429040733] [Import Data.ByteString from fps 0.5. Don Stewart **20060428130718 Fast, packed byte vectors, providing a better PackedString. ] [fix previous patch Ross Paterson **20060501154847] [fixes for non-GHC Ross Paterson **20060501144322] [fix imports for mingw32 && !GHC Ross Paterson **20060427163248] [RequireOrder: do not collect unrecognised options after a non-opt Simon Marlow **20060426121110 The documentation for RequireOrder says "no option processing after first non-option", so it doesn't seem right that we should process the rest of the arguments to collect the unrecognised ones. Presumably the client wants to know about the unrecognised options up to the first non-option, and will be using a different option parser for the rest of the command line. eg. before: Prelude System.Console.GetOpt> getOpt' RequireOrder [] ["bar","--foo"] ([],["bar","--foo"],["--foo"],[]) after: Prelude System.Console.GetOpt> getOpt' RequireOrder [] ["bar","--foo"] ([],["bar","--foo"],[],[]) ] [fix for Haddock 0.7 Ashley Yakeley **20060426072521] [add Data.Fixed module Ashley Yakeley **20060425071853] [add instances Ross Paterson **20060424102146] [add superclasses to Applicative and Traversable Ross Paterson **20060411144734 Functor is now a superclass of Applicative, and Functor and Foldable are now superclasses of Traversable. The new hierarchy makes clear the inclusions between the classes, but means more work in defining instances. Default definitions are provided to help. ] [add Functor and Monad instances for Prelude types Ross Paterson **20060410111443] [GHC.Base.breakpoint Lemmih **20060407125827] [Track the GHC source tree reorganisation Simon Marlow **20060407041631] [in the show instance for Exception, print the type of dynamic exceptions Simon Marlow **20060406112444 Unfortunately this requires some recursve module hackery to get at the show instance for Typeable. ] [implement ForeignEnvPtr, newForeignPtrEnv, addForeignPtrEnv for GHC Simon Marlow **20060405155448] [add forkOnIO :: Int -> IO () -> IO ThreadId Simon Marlow **20060327135018] [Rework previous: not a gcc bug after all Simon Marlow **20060323161229 It turns out that we were relying on behaviour that is undefined in C, and undefined behaviour in C means "the compiler can do whatever the hell it likes with your entire program". So avoid that. ] [work around a gcc 4.1.0 codegen bug in -O2 by forcing -O1 for GHC.Show Simon Marlow **20060323134514 See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26824 ] [commit mysteriously missing parts of "runIOFastExit" patch Simon Marlow **20060321101535] [add runIOFastExit :: IO a -> IO a Simon Marlow **20060320124333 Similar to runIO, but calls stg_exit() directly to exit, rather than shutdownHaskellAndExit(). Needed for running GHCi in the test suite. ] [Fix a broken invariant Simon Marlow **20060316134151 Patch from #694, for the problem "empty is an identity for <> and $$" is currently broken by eg. isEmpty (empty<>empty)" ] [Add unsafeSTToIO :: ST s a -> IO a Simon Marlow **20060315160232 Implementation for Hugs is missing, but should be easy. We need this for the forthcoming nested data parallelism implementation. ] [Added 'alter' jeanphilippe.bernardy@gmail.com**20060315143539 Added 'alter :: (Maybe a -> Maybe a) -> k -> Map k a -> Map k a' to IntMap and Map This addresses ticket #665 ] [deprecate FunctorM in favour of Foldable and Traversable Ross Paterson **20060315092942 as discussed on the libraries list. ] [Simplify Eq, Ord, and Show instances for UArray Simon Marlow **20060313142701 The Eq, Ord, and Show instances of UArray were written out longhand with one instance per element type. It is possible to condense these into a single instance for each class, at the expense of using more extensions (non-std context on instance declaration). Suggestion by: Frederik Eaton ] [Oops typo in intSet notMember jeanphilippe.bernardy@gmail.com**20060311224713] [IntMap lookup now returns monad instead of Maybe. jeanphilippe.bernardy@gmail.com**20060311224502] [Added notMember to Data.IntSet and Data.IntMap jeanphilippe.bernardy@gmail.com**20060311085221] [add Data.Set.notMember and Data.Map.notMember John Meacham **20060309191806] [addToClockTime: handle picoseconds properly Simon Marlow **20060310114532 fixes #588 ] [make head/build rule apply to all types, not just Bool. John Meacham **20060303045753] [Avoid overflow when normalising clock times Ian Lynagh **20060210144638] [Years have 365 days, not 30*365 Ian Lynagh **20060210142853] [declare blkcmp() static Simon Marlow **20060223134317] [typo in comment in Foldable class Ross Paterson **20060209004901] [simplify fmap Ross Paterson **20060206095048] [update ref in comment Ross Paterson **20060206095139] [Give -foverlapping-instances to Data.Typeable simonpj@microsoft**20060206133439 For some time, GHC has made -fallow-overlapping-instances "sticky": any instance in a module compiled with -fallow-overlapping-instances can overlap when imported, regardless of whether the importing module allows overlap. (If there is an overlap, both instances must come from modules thus compiled.) Instances in Data.Typeable might well want to be overlapped, so this commit adds the flag to Data.Typeable (with an explanatory comment) ] [Add -fno-bang-patterns to modules using both bang and glasgow-exts simonpj@microsoft.com**20060203175759] [When splitting a bucket, keep the contents in the same order Simon Marlow **20060201130427 To retain the property that multiple inserts shadow each other (see ticket #661, test hash001) ] [add foldr/build optimisation for take and replicate Simon Marlow **20060126164603 This allows take to be deforested, and improves performance of replicate and replicateM/replicateM_. We have a separate problem that means expressions involving [n..m] aren't being completely optimised because eftIntFB isn't being inlined but otherwise the results look good. Sadly this has invalidated a number of the nofib benchmarks which were erroneously using take to duplicate work in a misguided attempt to lengthen their runtimes (ToDo). ] [Generate PrimopWrappers.hs with Haddock docs Simon Marlow **20060124131121 Patch originally from Dinko Tenev , modified to add log message by me. ] [[project @ 2006-01-19 14:47:15 by ross] ross**20060119144715 backport warning avoidance from Haddock ] [[project @ 2006-01-18 11:45:47 by malcolm] malcolm**20060118114547 Fix import of Ix for nhc98. ] [[project @ 2006-01-17 09:38:38 by ross] ross**20060117093838 add Ix instance for GeneralCategory. ] [TAG Initial conversion from CVS complete John Goerzen **20060112154126] Patch bundle hash: 322c786dc6d4a0fe14735794faad3a6a7985b829 From dons at galois.com Mon Jan 7 01:38:41 2008 From: dons at galois.com (Don Stewart) Date: Mon Jan 7 01:32:25 2008 Subject: Generalise type of forever In-Reply-To: <20080107063327.GA6983@scytale.galois.com> References: <20080107063327.GA6983@scytale.galois.com> Message-ID: <20080107063841.GB6983@scytale.galois.com> dons: > It's been pointed out by a couple of people that the type of forever > is overly constrained. We get a few more useful programs for free > if we change the type: > > [generalise type of 'forever' from returning m () to m a > Don Stewart **20080107062656] { > hunk ./Control/Monad.hs 42 > - , forever -- :: (Monad m) => m a -> m () > + , forever -- :: (Monad m) => m a -> m a > hunk ./Control/Monad.hs 190 > -forever :: (Monad m) => m a -> m () > +forever :: (Monad m) => m a -> m a > } And in fact, forever :: (Monad m) => m a -> m b is better still. :) -- Don From stefanor at cox.net Mon Jan 7 01:39:37 2008 From: stefanor at cox.net (Stefan O'Rear) Date: Mon Jan 7 01:33:23 2008 Subject: Generalise type of forever In-Reply-To: <20080107063327.GA6983@scytale.galois.com> References: <20080107063327.GA6983@scytale.galois.com> Message-ID: <20080107063937.GA5440@localhost.localdomain> On Sun, Jan 06, 2008 at 10:33:27PM -0800, Don Stewart wrote: > It's been pointed out by a couple of people that the type of forever > is overly constrained. We get a few more useful programs for free > if we change the type: > > [generalise type of 'forever' from returning m () to m a > Don Stewart **20080107062656] { > hunk ./Control/Monad.hs 42 > - , forever -- :: (Monad m) => m a -> m () > + , forever -- :: (Monad m) => m a -> m a > hunk ./Control/Monad.hs 190 > -forever :: (Monad m) => m a -> m () > +forever :: (Monad m) => m a -> m a > } > > In particular, fail breaks out nicely. > > > forever Nothing > Nothing > > Deadline: 12th January. > > -- Don Your new type is not more general, for it no longer satisfies e.g. "Maybe Int -> Maybe ()". I counter-propose using the principal type, m a -> m b. 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/20080106/fee50603/attachment.bin From iavor.diatchki at gmail.com Mon Jan 7 01:54:01 2008 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Mon Jan 7 01:47:44 2008 Subject: PROPOSAL: Some more 'Applicative' combinators In-Reply-To: <4781B685.7050500@serpentine.com> References: <5ab17e790801061335t59d53588s2c935067457bde0e@mail.gmail.com> <4781B685.7050500@serpentine.com> Message-ID: <5ab17e790801062254x41e52005n78723b5c73fa7b71@mail.gmail.com> Hello, On Jan 6, 2008 9:20 PM, Bryan O'Sullivan wrote: > While applicative functors are good for this task, it would be a shame > if the innocent reader of haddocks were to acquire the impression that > parsing was all they were for. :-) oh, come on! I was just giving an example of what these combinators may be used for. They are not any more related to parsing than say, 'many', 'some', or 'empty' and '(<|>)'---they provide just a few more useful control structures. > Why not make the task specificity clearer, with a separate > Control.Applicative.Parsing module? Now _this_ would definitely suggest that they are only good for parsing which would be misleading. -Iavor From Christian.Maeder at dfki.de Mon Jan 7 04:58:37 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Mon Jan 7 04:52:21 2008 Subject: [Fwd: Re: Maps, was Re: GHC source code improvement ideas] Message-ID: <4781F7CD.3080607@dfki.de> -------- Original Message -------- Subject: Re: Maps, was Re: GHC source code improvement ideas Date: Fri, 04 Jan 2008 14:38:22 -0800 From: Mike Hamburg To: Christian Maeder References: <477D987C.2090806@gmail.com> <477E3D69.5000307@gmail.com> <477E5301.8010700@dfki.de> On Fri, 2008-01-04 at 16:38 +0100, Christian Maeder wrote: > Simon Marlow wrote: > > Regarding Data.Map, I'd be interested in trying out AVL trees instead, > > to see if they have better performance, but then we'd have to import the > > code of course. > > Surely, we want the best maps possible for ghc and as public library > (and minimize maintenance). > > The problem is to agree on a suitable interface. I would suggest to take > (or only slightly change) Daan's interface (the current Data.Map) and > improve the underlying implementation possibly using (i.e. Adrian Hey's) > AVL trees. If anyone is off tweaking the Data.Map library, I have a simple request (which I sometimes end up implementing in hacked up versions of Data.Map). There should be some way to extract an implicitly defined interval from the map, i.e. interval :: (k -> v -> Ordering) -> Map k v -> Map k v or partitionMonotoneWithKey :: (k -> v -> Bool) -> Map k v -> (Map k v, Map k v) or similar. The important thing about these operations is that they can be made to run in O(log n) time if you have the tree structure of the map, and (so far as I know) can't if you don't. An example of when this is useful is if you have a Map (a,b) c, and wish to extract the submap for a particular a-value, or a range of a-values. Mike From valery.vv at gmail.com Mon Jan 7 04:59:57 2008 From: valery.vv at gmail.com (Valery V. Vorotyntsev) Date: Mon Jan 7 04:53:42 2008 Subject: can't build plugins-1.0 with ghc-6.9 Message-ID: Hi, (The message below contains bunch of "preformatted" sections. I hope it's still readable, otherwise, please, let me know.) My quest is to install lambdabot (for the sake of offline `@hoogle' and `@pl' commands), and the one depends on `plugins'. 1) plugins.cabal should be updated ---------------------------------- A patch to .cabal file[1] is needed to get rid of config-time warning[2] and resolve build-time errors[3]. [1] vvv:~/src/plugins-1.0$ diff -u plugins.cabal{.orig,} --- plugins.cabal.orig 2008-01-06 22:23:44.657177486 +0200 +++ plugins.cabal 2008-01-06 22:25:45.160728537 +0200 @@ -33,6 +33,6 @@ src/Language/Hi/hschooks.c includes: Linker.h extensions: CPP, ForeignFunctionInterface -Build-Depends: base, Cabal, haskell-src +Build-Depends: base, Cabal, haskell-src, array, containers, directory, random, process ghc-options: -Wall -O -fasm -funbox-strict-fields -fno-warn-missing-signatures -hs-source-dir: src +hs-source-dirs: src [2] vvv:~/src/plugins-1.0$ runhaskell Setup configure --prefix=$HOME --user Warning: The field "hs-source-dir" is deprecated, please use "hs-source-dirs" Configuring plugins-1.0... [...] [3] vvv:~/src/plugins-1.0$ runhaskell Setup build Preprocessing library plugins-1.0... Building plugins-1.0... src/Language/Hi/Binary.hs:90:7: Could not find module `Data.Array.Base': it is a member of package array-0.1, which is hidden 2) it doesn't build with Cabal-1.3.2 ------------------------------------ `InstalledPackageInfo' is a type alias in GHC's Cabal[4], not a data constructor; `plugins' library[5] gets confused[6]. [4] vvv:~/src$ diff -u cabal-1.2.2.0/Distribution/InstalledPackageInfo.hs ghc/libraries/Cabal/Distribution/InstalledPackageInfo.hs --- cabal-1.2.2.0/Distribution/InstalledPackageInfo.hs 2007-11-01 17:02:35.000000000 +0200 +++ ghc/libraries/Cabal/Distribution/InstalledPackageInfo.hs 2007-12-17 17:53:21.691532864 +0200 @@ -46,7 +46,7 @@ -- This module is meant to be local-only to Distribution... module Distribution.InstalledPackageInfo ( - InstalledPackageInfo(..), + InstalledPackageInfo_(..), InstalledPackageInfo, ParseResult(..), PError(..), PWarning, emptyInstalledPackageInfo, parseInstalledPackageInfo, @@ -72,8 +72,8 @@ -- ----------------------------------------------------------------------------- -- The InstalledPackageInfo type -data InstalledPackageInfo - = InstalledPackageInfo { +data InstalledPackageInfo_ m + = InstalledPackageInfo_ { -- these parts are exactly the same as PackageDescription package :: PackageIdentifier, license :: License, @@ -87,8 +87,8 @@ category :: String, -- these parts are required by an installed package only: exposed :: Bool, - exposedModules :: [String], - hiddenModules :: [String], + exposedModules :: [m], + hiddenModules :: [m], importDirs :: [FilePath], -- contain sources in case of Hugs libraryDirs :: [FilePath], hsLibraries :: [String], @@ -107,9 +107,11 @@ } deriving (Read, Show) -emptyInstalledPackageInfo :: InstalledPackageInfo +type InstalledPackageInfo = InstalledPackageInfo_ String + +emptyInstalledPackageInfo :: InstalledPackageInfo_ m emptyInstalledPackageInfo - = InstalledPackageInfo { + = InstalledPackageInfo_ { package = PackageIdentifier "" noVersion, license = AllRightsReserved, copyright = "", [5] vvv:~/src/plugins-1.0$ sed -n 64,66p src/System/Plugins/PackageAPI.hs updImportDirs f pk@(InstalledPackageInfo { importDirs = idirs }) = pk { importDirs = f idirs } updLibraryDirs f pk@(InstalledPackageInfo { libraryDirs = ldirs }) = [6] vvv:~/src/plugins-1.0$ runhaskell Setup build Preprocessing library plugins-1.0... Building plugins-1.0... [ 1 of 24] Compiling System.Plugins.Process ( src/System/Plugins/Process.hs, dist/build/System/Plugins/Process.o ) [ 2 of 24] Compiling System.Plugins.Parser ( src/System/Plugins/Parser.hs, dist/build/System/Plugins/Parser.o ) [ 3 of 24] Compiling System.Plugins.ParsePkgConfCabal ( src/System/Plugins/ParsePkgConfCabal.hs, dist/build/System/Plugins/ParsePkgConfCabal.o ) [ 4 of 24] Compiling System.Plugins.PackageAPI ( src/System/Plugins/PackageAPI.hs, dist/build/System/Plugins/PackageAPI.o ) src/System/Plugins/PackageAPI.hs:64:20: Not in scope: data constructor `InstalledPackageInfo' src/System/Plugins/PackageAPI.hs:66:21: Not in scope: data constructor `InstalledPackageInfo' I would like to hear your suggestions. Should I try harder[7] installing Cabal-1.2.2.0? Or is this a bug of GHC's Cabal? In this case I've just reported it. :) [7] vvv:~/src/cabal-1.2.2.0$ runhaskell Setup configure --prefix=$HOME --user Configuring Cabal-1.2.2.0... Setup: At least the following dependencies are missing: base <3, filepath -any vvv:~/src/cabal-1.2.2.0$ runhaskell Setup configure --prefix=$HOME --user -f small_base Configuring Cabal-1.2.2.0... Setup: At least the following dependencies are missing: base >=3, pretty -any, directory -any, old-time -any, process -any, containers -any, filepath -any vvv:~/src/cabal-1.2.2.0$ ghc-pkg list /home/vvv/lib/ghc-6.9.20080104/package.conf: Cabal-1.3.2, array-0.1, base-3.0, bytestring-0.9, containers-0.1, directory-1.0, filepath-1.1, (ghc-6.9.20080104), haskell98-1.0.1, hpc-0.5, old-locale-1.0, old-time-1.0, packedstring-0.1, pretty-1.0, process-1.0, random-1.0, readline-1.0.1, rts-1.0, template-haskell-2.2, unix-2.2 /home/vvv/.ghc/i386-linux-6.9.20080104/package.conf: X11-1.4.1, binary-0.4.1, haskell-src-1.0.1.1, mtl-1.1.0.0, network-2.1.0.0, parsec-2.1.0.0, xmonad-0.5, xmonad-contrib-0.5 Thanks a lot. Happy hacking! -- vvv From moonlite at dtek.chalmers.se Mon Jan 7 09:57:21 2008 From: moonlite at dtek.chalmers.se (Mattias Bengtsson) Date: Mon Jan 7 09:51:07 2008 Subject: Announcement: Typeful [x]html combinators -- pre-release 0 In-Reply-To: References: <2608b8a80712190031m61d29600tbea7eb6d0d51fd6@mail.gmail.com> Message-ID: <1199717841.6547.8.camel@mben-desktop> On Wed, 2007-12-19 at 15:06 +0000, Jon Fairbairn wrote: > "Yitzchak Gale" writes: > > What you are doing here is enforcing a DTD using > > the Haskell type system. Apart from your plans for > > HTML 4.01, perhaps a better generalization would > > be to generate typeful combinators that could > > validate at compile time for any given XML DTD. > > I think that would be the job of something like HaXml or > HXT, and there are plenty of good people working on them. > To clarify, what these types enforce is something stronger > than an XML DTD, more like the SGML DTD of html (and as I > write this I am inclining myself further towards making the > document tree types fit the common subset); it enforces the > restrictions that are only expressed in prose in the > xhtml1.0 standard. You could think of it as enforcing a > schema (that the w3c didn't provide). It seems that they did actually[1]. Making a program for generating ADT's and combinators from XML schemas to provide type safe XML is something i'd very much like to do someday. One thing i'm uncertain of is whether supporting namespaces would be a problem or not. It would be a shame to have a bunch of generated XML-standards in Haskell that can't be used together (ie. embedding MathML or SVG in XHTML). Mattias 1: http://www.w3.org/TR/xhtml1-schema/ From dons at galois.com Mon Jan 7 11:46:52 2008 From: dons at galois.com (Don Stewart) Date: Mon Jan 7 11:40:47 2008 Subject: can't build plugins-1.0 with ghc-6.9 In-Reply-To: References: Message-ID: <20080107164652.GB16760@scytale.galois.com> Please start with the hs-plugins repo on code.haskell.org, since it's already updated for ghc 6.8, http://code.haskell.org/~dons/code/hs-plugins/ valery.vv: > Hi, > > (The message below contains bunch of "preformatted" sections. > I hope it's still readable, otherwise, please, let me know.) > > My quest is to install lambdabot (for the sake of offline `@hoogle' > and `@pl' commands), and the one depends on `plugins'. > > 1) plugins.cabal should be updated > ---------------------------------- > > A patch to .cabal file[1] is needed to get rid of config-time > warning[2] and resolve build-time errors[3]. > > [1] > vvv:~/src/plugins-1.0$ diff -u plugins.cabal{.orig,} > --- plugins.cabal.orig 2008-01-06 22:23:44.657177486 +0200 > +++ plugins.cabal 2008-01-06 22:25:45.160728537 +0200 > @@ -33,6 +33,6 @@ > src/Language/Hi/hschooks.c > includes: Linker.h > extensions: CPP, ForeignFunctionInterface > -Build-Depends: base, Cabal, haskell-src > +Build-Depends: base, Cabal, haskell-src, array, containers, > directory, random, process > ghc-options: -Wall -O -fasm -funbox-strict-fields > -fno-warn-missing-signatures > -hs-source-dir: src > +hs-source-dirs: src > > [2] > vvv:~/src/plugins-1.0$ runhaskell Setup configure --prefix=$HOME --user > Warning: The field "hs-source-dir" is deprecated, please use "hs-source-dirs" > Configuring plugins-1.0... > [...] > > [3] > vvv:~/src/plugins-1.0$ runhaskell Setup build > Preprocessing library plugins-1.0... > Building plugins-1.0... > > src/Language/Hi/Binary.hs:90:7: > Could not find module `Data.Array.Base': > it is a member of package array-0.1, which is hidden > > 2) it doesn't build with Cabal-1.3.2 > ------------------------------------ > > `InstalledPackageInfo' is a type alias in GHC's Cabal[4], not a data > constructor; `plugins' library[5] gets confused[6]. > > [4] > vvv:~/src$ diff -u > cabal-1.2.2.0/Distribution/InstalledPackageInfo.hs > ghc/libraries/Cabal/Distribution/InstalledPackageInfo.hs > --- cabal-1.2.2.0/Distribution/InstalledPackageInfo.hs 2007-11-01 > 17:02:35.000000000 +0200 > +++ ghc/libraries/Cabal/Distribution/InstalledPackageInfo.hs > 2007-12-17 17:53:21.691532864 +0200 > @@ -46,7 +46,7 @@ > -- This module is meant to be local-only to Distribution... > > module Distribution.InstalledPackageInfo ( > - InstalledPackageInfo(..), > + InstalledPackageInfo_(..), InstalledPackageInfo, > ParseResult(..), PError(..), PWarning, > emptyInstalledPackageInfo, > parseInstalledPackageInfo, > @@ -72,8 +72,8 @@ > -- ----------------------------------------------------------------------------- > -- The InstalledPackageInfo type > > -data InstalledPackageInfo > - = InstalledPackageInfo { > +data InstalledPackageInfo_ m > + = InstalledPackageInfo_ { > -- these parts are exactly the same as PackageDescription > package :: PackageIdentifier, > license :: License, > @@ -87,8 +87,8 @@ > category :: String, > -- these parts are required by an installed package only: > exposed :: Bool, > - exposedModules :: [String], > - hiddenModules :: [String], > + exposedModules :: [m], > + hiddenModules :: [m], > importDirs :: [FilePath], -- contain sources in case of Hugs > libraryDirs :: [FilePath], > hsLibraries :: [String], > @@ -107,9 +107,11 @@ > } > deriving (Read, Show) > > -emptyInstalledPackageInfo :: InstalledPackageInfo > +type InstalledPackageInfo = InstalledPackageInfo_ String > + > +emptyInstalledPackageInfo :: InstalledPackageInfo_ m > emptyInstalledPackageInfo > - = InstalledPackageInfo { > + = InstalledPackageInfo_ { > package = PackageIdentifier "" noVersion, > license = AllRightsReserved, > copyright = "", > > [5] > vvv:~/src/plugins-1.0$ sed -n 64,66p src/System/Plugins/PackageAPI.hs > updImportDirs f pk@(InstalledPackageInfo { importDirs = idirs }) = > pk { importDirs = f idirs } > updLibraryDirs f pk@(InstalledPackageInfo { libraryDirs = ldirs }) = > > [6] > vvv:~/src/plugins-1.0$ runhaskell Setup build > Preprocessing library plugins-1.0... > Building plugins-1.0... > [ 1 of 24] Compiling System.Plugins.Process ( > src/System/Plugins/Process.hs, dist/build/System/Plugins/Process.o ) > [ 2 of 24] Compiling System.Plugins.Parser ( > src/System/Plugins/Parser.hs, dist/build/System/Plugins/Parser.o ) > [ 3 of 24] Compiling System.Plugins.ParsePkgConfCabal ( > src/System/Plugins/ParsePkgConfCabal.hs, > dist/build/System/Plugins/ParsePkgConfCabal.o ) > [ 4 of 24] Compiling System.Plugins.PackageAPI ( > src/System/Plugins/PackageAPI.hs, > dist/build/System/Plugins/PackageAPI.o ) > > src/System/Plugins/PackageAPI.hs:64:20: > Not in scope: data constructor `InstalledPackageInfo' > > src/System/Plugins/PackageAPI.hs:66:21: > Not in scope: data constructor `InstalledPackageInfo' > > I would like to hear your suggestions. > > Should I try harder[7] installing Cabal-1.2.2.0? > Or is this a bug of GHC's Cabal? In this case I've just reported it. :) > > [7] > vvv:~/src/cabal-1.2.2.0$ runhaskell Setup configure --prefix=$HOME --user > Configuring Cabal-1.2.2.0... > Setup: At least the following dependencies are missing: > base <3, filepath -any > vvv:~/src/cabal-1.2.2.0$ runhaskell Setup configure --prefix=$HOME > --user -f small_base > Configuring Cabal-1.2.2.0... > Setup: At least the following dependencies are missing: > base >=3, > pretty -any, > directory -any, > old-time -any, > process -any, > containers -any, > filepath -any > vvv:~/src/cabal-1.2.2.0$ ghc-pkg list > /home/vvv/lib/ghc-6.9.20080104/package.conf: > Cabal-1.3.2, array-0.1, base-3.0, bytestring-0.9, containers-0.1, > directory-1.0, filepath-1.1, (ghc-6.9.20080104), haskell98-1.0.1, > hpc-0.5, old-locale-1.0, old-time-1.0, packedstring-0.1, > pretty-1.0, process-1.0, random-1.0, readline-1.0.1, rts-1.0, > template-haskell-2.2, unix-2.2 > /home/vvv/.ghc/i386-linux-6.9.20080104/package.conf: > X11-1.4.1, binary-0.4.1, haskell-src-1.0.1.1, mtl-1.1.0.0, > network-2.1.0.0, parsec-2.1.0.0, xmonad-0.5, xmonad-contrib-0.5 > > Thanks a lot. > > Happy hacking! > > -- > vvv > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries From duncan.coutts at worc.ox.ac.uk Mon Jan 7 13:00:27 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Jan 7 12:54:09 2008 Subject: new language extensions In-Reply-To: <20080106175119.GB16859@momenergy.repetae.net> References: <1194300038.26140.205.camel@localhost> <1194471625.26140.332.camel@localhost> <20071108142755.GA10990@matrix.chaos.earth.li> <20080106175119.GB16859@momenergy.repetae.net> Message-ID: <20080107180027.8F4F69E048@webmail222.herald.ox.ac.uk> In message <20080106175119.GB16859@momenergy.repetae.net> Haskell Libraries , Duncan Coutts writes: > On Thu, Nov 08, 2007 at 02:27:55PM +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. Then Cabal would work with future GHCs, with new extensions as > > yet undreamt of, as well. > > Yes, I would like to see this too, I have not really done a lot of work > integrating jhc with cabal, but this 'baked in' extension type was > something of an issue. How so? It's easy to extend it, just send us a patch with the extras. > (jhc itself understands a subset of the cabal > file type and can build libraries based on them with jhc --build-hl). Honestly, I'd prefer to see better support in Cabal for jhc than have each Haskell implementation do a half-complete .cabal file processor. nhc98 has been doing this too and it'll only ever half work. As a Cabal patch reviewer I'm very happy to see patches to improve support for nhc98, jhc etc, and if the code is in Cabal then we can stop it from suffering bit rot so quickly. > There are a couple other places where a 'newtype String' made more sense > too if I recall. I don't mind so much if it's a string or an enum, but keeping a central register seems like a good thing to me and an enum enforces that. We could certainly make the parsing a bit more sensible so it doesn't fall over when it encounters an unknown extension. > Perhaps just a simple wiki page where we can "register" extension names > is in order as there are a few jhc understands that arn't in the cabal > extension type (nor should they be if this fix is completed). Or using the existing mechanism, you can darcs send a patch to Language.Haskell.Extension to "register" your extension names. I fail to see how a wiki page is better. Duncan From paul at cogito.org.uk Mon Jan 7 13:35:34 2008 From: paul at cogito.org.uk (Paul Johnson) Date: Mon Jan 7 13:29:19 2008 Subject: [Fwd: Re: Maps, was Re: GHC source code improvement ideas] In-Reply-To: <4781F7CD.3080607@dfki.de> References: <4781F7CD.3080607@dfki.de> Message-ID: <478270F6.70302@cogito.org.uk> Christian Maeder wrote: > If anyone is off tweaking the Data.Map library, I have a simple request > (which I sometimes end up implementing in hacked up versions of > Data.Map). There should be some way to extract an implicitly defined > interval from the map, i.e. > > interval :: (k -> v -> Ordering) -> Map k v -> Map k v > I'm not quite sure what you are asking for here. Why does the first argument take both a key and a value, and what is the Ordering saying? From your description I was expecting something more like: interval :: k -> k -> Map k v -> Map k v Are you saying that if the Ordering is "EQ" then the key is within the range? Take a look at my Ranged Sets library (on Hackage) for a complete treatment of the concept of ranges within an ordered type. I can imagine something like rangedSetMap :: RSet k -> Map k v -> Map k v where the resulting Map only contains the keys that are in the RSet. At present you would have to do that by iterating through the Map, but I can imagine a more efficient method. Alternatively the Boundary type defined in that library might be used: it splits an ordered type into values above and below a boundary. (Two Boundary values make a Range, and an ordered list of non-overlapping Ranges is an RSet). Paul. From valery.vv at gmail.com Mon Jan 7 15:51:28 2008 From: valery.vv at gmail.com (Valery V. Vorotyntsev) Date: Mon Jan 7 15:45:11 2008 Subject: can't build plugins-1.0 with ghc-6.9 In-Reply-To: <20080107164652.GB16760@scytale.galois.com> References: <20080107164652.GB16760@scytale.galois.com> Message-ID: On 1/7/08, Don Stewart wrote: > Please start with the hs-plugins repo on code.haskell.org, since it's > already updated for ghc 6.8, > > http://code.haskell.org/~dons/code/hs-plugins/ Missed shot. :) vvv:~/src/hs-plugins$ runhaskell Setup build Preprocessing library plugins-1.1... Building plugins-1.1... [ 1 of 16] Compiling System.Plugins.Process ( src/System/Plugins/Process.hs, dist/build/System/Plugins/Process.o ) [ 2 of 16] Compiling System.Plugins.Parser ( src/System/Plugins/Parser.hs, dist/build/System/Plugins/Parser.o ) [ 3 of 16] Compiling System.Plugins.ParsePkgConfCabal ( src/System/Plugins/ParsePkgConfCabal.hs, dist/build/System/Plugins/ParsePkgConfCabal.o ) [ 4 of 16] Compiling System.Plugins.PackageAPI ( src/System/Plugins/PackageAPI.hs, dist/build/System/Plugins/PackageAPI.o ) src/System/Plugins/PackageAPI.hs:64:20: Not in scope: data constructor `InstalledPackageInfo' src/System/Plugins/PackageAPI.hs:66:21: Not in scope: data constructor `InstalledPackageInfo' No problems with the .cabal file, though. -- vvv From haskell at list.mightyreason.com Mon Jan 7 16:24:52 2008 From: haskell at list.mightyreason.com (ChrisK) Date: Mon Jan 7 16:18:35 2008 Subject: ANN: Build fixed for regex-base,posix,compat,pcre Message-ID: <478298A4.2030507@list.mightyreason.com> ANNOUNCEMENT: Build fixed for regex-base, regex-posix, regex-compat, regex-pcre The changes are mainly to the Cabal build files to support ghc-6.8 and ghc-6.6 simultaneously. They definitely work with cabal version 1.2.3.0 (required for regex-pcre). The regex-base, regex-posix, and regex-compat packages also seem to work with cabal-1.2.2.0 (but not regex-pcre). The darcs repositories under http://darcs.haskell.org/packages/regex-unstable/ hold the new code. I have uploaded new versions of the most popular regex-* packages to hackage: Mon Jan 7 13:18:00 PST 2008 ChrisKuklewicz regex-pcre-0.94.1 Mon Jan 7 13:05:57 PST 2008 ChrisKuklewicz regex-posix-0.93.1 Mon Jan 7 13:04:49 PST 2008 ChrisKuklewicz regex-base-0.93.1 Mon Jan 7 06:50:54 PST 2008 ChrisKuklewicz regex-compat-0.91 I would like to thank everyone who sent me updated, and particularly Olivier Boudry who sent patches. These build fixes have only been tested with ghc-6.6.1 on Mac OS X 10.5.1 (powerpc) and with ghc-6.8.2 on Linux (x86). Happy New Year, Chris Kuklewicz From chad.scherrer at gmail.com Mon Jan 7 18:10:40 2008 From: chad.scherrer at gmail.com (Chad Scherrer) Date: Mon Jan 7 18:13:51 2008 Subject: typo in Data.Binary documentation Message-ID: The latest Data.Binary documentation says instance of Binary should have get . put == id But this doesn't typecheck! I'm guessing it's probably supposed to say decode . encode == id -Chad From dons at galois.com Mon Jan 7 18:26:55 2008 From: dons at galois.com (Don Stewart) Date: Mon Jan 7 18:20:38 2008 Subject: typo in Data.Binary documentation In-Reply-To: References: Message-ID: <20080107232655.GI17534@scytale.galois.com> chad.scherrer: > The latest Data.Binary documentation says instance of Binary should have > > get . put == id > > But this doesn't typecheck! I'm guessing it's probably supposed to say > > decode . encode == id Well spotted. Fixed in darcs. From dons at galois.com Mon Jan 7 19:53:14 2008 From: dons at galois.com (Don Stewart) Date: Mon Jan 7 19:47:00 2008 Subject: PROPOSAL: Some more 'Applicative' combinators In-Reply-To: <5ab17e790801062254x41e52005n78723b5c73fa7b71@mail.gmail.com> References: <5ab17e790801061335t59d53588s2c935067457bde0e@mail.gmail.com> <4781B685.7050500@serpentine.com> <5ab17e790801062254x41e52005n78723b5c73fa7b71@mail.gmail.com> Message-ID: <20080108005314.GP17534@scytale.galois.com> iavor.diatchki: > Hello, > > On Jan 6, 2008 9:20 PM, Bryan O'Sullivan wrote: > > While applicative functors are good for this task, it would be a shame > > if the innocent reader of haddocks were to acquire the impression that > > parsing was all they were for. > > :-) oh, come on! I was just giving an example of what these > combinators may be used for. They are not any more related to > parsing than say, 'many', 'some', or 'empty' and '(<|>)'---they > provide just a few more useful control structures. > > > Why not make the task specificity clearer, with a separate > > Control.Applicative.Parsing module? > > Now _this_ would definitely suggest that they are only good for > parsing which would be misleading. +1 for this proposal. Glue for combining parsers seems like a missing piece. Perhaps toss in an example in the docs? From stefan at cs.uu.nl Mon Jan 7 20:32:17 2008 From: stefan at cs.uu.nl (Stefan Holdermans) Date: Mon Jan 7 20:26:05 2008 Subject: PROPOSAL: Some more 'Applicative' combinators In-Reply-To: <5ab17e790801061335t59d53588s2c935067457bde0e@mail.gmail.com> References: <5ab17e790801061335t59d53588s2c935067457bde0e@mail.gmail.com> Message-ID: <8E555BE0-A198-44C7-9684-93D4DA6A953A@cs.uu.nl> Iavor wrote: > I propose that we add the following combinators to the > 'Control.Applicative' module: Here's a bunch, I've been using for quite some time now: infixl 5 , , <, > infixl 4 <$$>, <^>, <^, <^^>, , , <+> infixl 3 <||> infixl 2 `opt` (<$$>) :: (Applicative f) => f a -> (a -> b) -> f b v <$$> f = v <**> pure f (<^>) :: (Applicative f) => f (a -> b -> c) -> f b -> f (a -> c) l <^> r = flip <$> l <*> r (<^) :: (Applicative f) => f (a -> b -> c) -> f d -> f (b -> a -> c) l <^ r = flip <$> l <* r (<^^>) :: (Applicative f) => f b -> f (a -> b -> c) -> f (a -> c) l <^^> r = l <**> (flip <$> r) () :: (Applicative f) => (a -> b -> c) -> f b -> f (a -> c) f v = flip f <$> v ( (a -> b -> c) -> f d -> f (b -> a -> c) f ) :: (Applicative f) => f b -> (a -> b -> c) -> f (a -> c) v f = v <$$> flip f (<+>) :: (Applicative f) => f a -> f b -> f (a, b) l <+> r = (,) <$> l <*> r (<||>) :: (Alternative f) => f a -> f b -> f (Either a b) l <||> r = Left <$> l <|> Right <$> r () :: (Alternative f) => a -> f a -> f a x v = v <|> pure x (), opt :: (Alternative f) => f a -> a -> f a v x = v <|> pure x opt = () (<) :: (Alternative f) => f (a -> a) -> f a -> f a l < r = id l <*> r (>) :: (Alternative f) => f a -> f (a -> a) -> f a l > r = l <**> r id packed :: (Applicative f) => f a -> f b -> f c -> f c packed l r v = l *> v <* r choice :: (Alternative f) => [f a] -> f a choice = foldr (<|>) empty foldrMany :: (Alternative f) => (a -> b -> b) -> b -> f a -> f b foldrMany op e v = go where go = op <$> v <*> go `opt` e foldrSome :: (Alternative f) => (a -> b -> b) -> b -> f a -> f b foldrSome op e v = op <$> v <*> go where go = op <$> v <*> go `opt` e foldlMany :: (Alternative f) => (b -> a -> b) -> b -> f a -> f b foldlMany op e v = go <*> pure e where go = op v (.) <*> go `opt` id foldlSome :: (Alternative f) => (b -> a -> b) -> b -> f a -> f b foldlSome op e v = op e <$> v <**> go where go = op v (.) <*> go `opt` id foldrSepMany :: (Alternative f) => (a -> b -> b) -> b -> f c -> f a -> f b foldrSepMany op e u v = op <$> v <*> go `opt` e where go = op <$ u <*> v <*> go `opt` e foldrSepSome :: (Alternative f) => (a -> b -> b) -> b -> f c -> f a -> f b foldrSepSome op e u v = op <$> v <*> go where go = op <$ u <*> v <*> go `opt` e foldlSepMany :: (Alternative f) => (b -> a -> b) -> b -> f c -> f a -> f b foldlSepMany op e u v = op e <$> v <**> go `opt` e where go = op v (.) <*> go `opt` id foldlSepSome :: (Alternative f) => (b -> a -> b) -> b -> f c -> f a -> f b foldlSepSome op e u v = op e <$> v <**> go where go = op v (.) <*> go `opt` id sepMany, sepSome :: (Alternative f) => f b -> f a -> f [a] sepMany = foldrSepMany (:) [] sepSome = foldrSepSome (:) [] chainr :: (Alternative f) => f (a -> a -> a) -> f a -> f a chainr u v = v > go where go = u <^> v > go chainl :: (Alternative f) => f (a -> a -> a) -> f a -> f a chainl u v = v <**> go where go = (.) (u <^> v) <*> go `opt` id Cheers, Stefan -------------- next part -------------- A non-text attachment was scrubbed... Name: Idiom.hs Type: application/octet-stream Size: 4459 bytes Desc: not available Url : http://www.haskell.org/pipermail/libraries/attachments/20080107/73f4b929/Idiom-0001.obj -------------- next part -------------- From apfelmus at quantentunnel.de Tue Jan 8 04:43:49 2008 From: apfelmus at quantentunnel.de (apfelmus) Date: Tue Jan 8 04:37:44 2008 Subject: PROPOSAL: Some more 'Applicative' combinators In-Reply-To: <5ab17e790801062254x41e52005n78723b5c73fa7b71@mail.gmail.com> References: <5ab17e790801061335t59d53588s2c935067457bde0e@mail.gmail.com> <4781B685.7050500@serpentine.com> <5ab17e790801062254x41e52005n78723b5c73fa7b71@mail.gmail.com> Message-ID: Iavor Diatchki wrote: > Bryan O'Sullivan wrote: >> Why not make the task specificity clearer, with a separate >> Control.Applicative.Parsing module? +1 > Now _this_ would definitely suggest that they are only good for > parsing which would be misleading. Would it? I mean, I currently don't know a second use case for them. Preferably, the names like skipMany , endBy , sepBy etc. should still make sense in the new context. Regards, apfelmus From jon.fairbairn at cl.cam.ac.uk Tue Jan 8 05:31:28 2008 From: jon.fairbairn at cl.cam.ac.uk (Jon Fairbairn) Date: Tue Jan 8 05:25:17 2008 Subject: Announcement: Typeful [x]html combinators -- pre-release 0 References: <2608b8a80712190031m61d29600tbea7eb6d0d51fd6@mail.gmail.com> <1199717841.6547.8.camel@mben-desktop> Message-ID: Mattias Bengtsson writes: > On Wed, 2007-12-19 at 15:06 +0000, Jon Fairbairn wrote: >> I think that would be the job of something like HaXml or >> HXT, and there are plenty of good people working on them. >> To clarify, what these types enforce is something stronger >> than an XML DTD, more like the SGML DTD of html (and as I >> write this I am inclining myself further towards making the >> document tree types fit the common subset); it enforces the >> restrictions that are only expressed in prose in the >> xhtml1.0 standard. You could think of it as enforcing a >> schema (that the w3c didn't provide). > > It seems that they did actually[1]. Thanks for finding that (I do hate the way that the W3C issues proper formal definitions of things but makes the informal one the normative one); I can use it to check attribute types and so on. Does it enforce the nesting restrictions (described in app. B of the xhtml1 dtd)? Looking through it with little knowledge of schemas, I can't see that it does. > Making a program for generating ADT's and combinators from XML schemas > to provide type safe XML is something i'd very much like to do someday. It would be a good thing to do, though not something I'm thinking of just now (a bit too much for me at the moment). > One thing i'm uncertain of is whether supporting namespaces would be a > problem or not. It would be a shame to have a bunch of generated > XML-standards in Haskell that can't be used together (ie. embedding > MathML or SVG in XHTML). Yes. I'd like the document tree in the typeful HTMLs library to be compatible with such things, but again, I'm not up to doing the big concept stuff. -- J?n Fairbairn Jon.Fairbairn@cl.cam.ac.uk From moonlite at dtek.chalmers.se Tue Jan 8 06:14:36 2008 From: moonlite at dtek.chalmers.se (Mattias Bengtsson) Date: Tue Jan 8 06:08:20 2008 Subject: Announcement: Typeful [x]html combinators -- pre-release 0 In-Reply-To: References: <2608b8a80712190031m61d29600tbea7eb6d0d51fd6@mail.gmail.com> <1199717841.6547.8.camel@mben-desktop> Message-ID: <1199790876.6707.18.camel@mben-desktop> On Tue, 2008-01-08 at 10:31 +0000, Jon Fairbairn wrote: > Thanks for finding that (I do hate the way that the W3C > issues proper formal definitions of things but makes the > informal one the normative one); I can use it to check > attribute types and so on. Does it enforce the nesting > restrictions (described in app. B of the xhtml1 dtd)? > Looking through it with little knowledge of schemas, I can't > see that it does. Yes this is really frustrating. I think the schema is supposed to enforce nesting restrictions. At least that's how i interpret paragraph 1.3[1] in the Note. It doesn't seem to be able to enforce everything though (eg. the legend example in 1.3). > > Making a program for generating ADT's and combinators from XML schemas > > to provide type safe XML is something i'd very much like to do someday. > > It would be a good thing to do, though not something I'm > thinking of just now (a bit too much for me at the moment). Same here i think. It's on my TODO though. :) Mattias 1: http://www.w3.org/TR/xhtml1-schema/#why From Christian.Maeder at dfki.de Tue Jan 8 06:30:30 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Tue Jan 8 06:24:11 2008 Subject: [Fwd: Re: Maps] Message-ID: <47835ED6.3080709@dfki.de> -------- Original Message -------- Subject: Re: Maps Date: Tue, 08 Jan 2008 05:35:07 -0800 From: Mike Hamburg To: Christian Maeder CC: paul@cogito.org.uk References: <47832E64.3090008@dfki.de> So here's an approximation of my problem. I have a map of objects, possibly aggregated from different sources. They have (in a case of medium complexity) type (t,u) where the t represents the source and u represents the position within that source. They're derived from something like a Map t (Map u v), but it is convenient for other reasons to represent this as an actual Map (t,u) v. (It's possible that I'll end up hacking around this with some type class or another, but let's ignore that possibility for now.) I need to efficiently represent ranges of objects to be viewed or deleted from this map, in such a way that the map library can extract or delete them quickly. But I might have, say, only a t value, and no values of u available. On Tue, 2008-01-08 at 09:03 +0100, Christian Maeder wrote: > I'm not quite sure what you are asking for here. Why does the first > argument take both a key and a value, and what is the Ordering saying? > >From your description I was expecting something more like: > > interval :: k -> k -> Map k v -> Map k v > > Are you saying that if the Ordering is "EQ" then the key is within the > range? Yes. The "ordering" produced is a sort of disjunctive ordering: it's either LT all, or GT all, or EQ at least one element in the interval. I suppose my version should really have type (k -> Ordering) -> Map k v -> Map k v because the values shouldn't come into play unless they're monotonically dependent on the keys. > Take a look at my Ranged Sets library (on Hackage) for a complete > treatment of the concept of ranges within an ordered type. I can > imagine something like > > rangedSetMap :: RSet k -> Map k v -> Map k v Something like an RSet, with the following operations: union, singleton, Range -> RangeSet, ... upcast :: RangeSet t -> RangeSet (t,u) -- and similar for other product types intersection, difference :: Map k v -> RangeSet k -> Map k v > where the resulting Map only contains the keys that are in the RSet. At > present you would have to do that by iterating through the Map, but I > can imagine a more efficient method. Alternatively the Boundary type > defined in that library might be used: it splits an ordered type into > values above and below a boundary. (Two Boundary values make a Range, > and an ordered list of non-overlapping Ranges is an RSet). Yes. But I think what you need to efficiently implement this is some sort of implicit cut, of the form (k -> Something) -> Map k v -> (Map k v, Map k v). > Paul. Also, I'm sort of curious: in C/C++/Java/etc, you can produce a Dense type which has: instance (Eq, Ord, Bounded) Dense between :: Dense -> Dense -> Dense -- if a < b then a < between a b < b This is sort of a lie: between is not referentially transparent, in that two calls to (between a b) may produce results that aren't ==. Still, the efficiency is impressive: ==, >, <, etc are O(1) 'between' is O(log n) where n Dense's are currently live. You can actually make it O(1), but the constant is big, so people don't. total space usage is O(n) integers of 2(log n) bits each Is there any way to even approach this in Haskell? I mean, you can use [Int], but that's not nearly so fast... Mike From lemming at henning-thielemann.de Tue Jan 8 06:36:41 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Tue Jan 8 06:30:20 2008 Subject: typo in Foreign.Ptr.minusPtr documentation In-Reply-To: References: Message-ID: http://www.haskell.org/ghc/docs/latest/html/libraries/base/Foreign-Ptr.html#v%3AminusPtr The description "Computes the offset required to get from the first to the second argument." contradicts to the formula p2 == p1 `plusPtr` (p2 `minusPtr` p1) It should be "Computes the offset required to get from the second to the first argument." From tomasz.zielonka at gmail.com Tue Jan 8 08:15:10 2008 From: tomasz.zielonka at gmail.com (Tomasz Zielonka) Date: Tue Jan 8 07:08:53 2008 Subject: Announcement: Typeful [x]html combinators -- pre-release 0 In-Reply-To: References: Message-ID: <20080108131510.GA13897@lambda> On Tue, Dec 18, 2007 at 05:38:47PM +0000, Jon Fairbairn wrote: > ... or, "whoops! I've writtten another html combinator library." > > History: I was surprised to find that all the Haskell html > generating stuff I've tried allowed one to construct invalid > HTML. Did you take a look at Peter Thiemann's WASH/HTML? It contains a monadic combinator library that checks proper nesting of HTML tags at compile time. The library also has an unchecked version, and the checked version doesn't seem to be used too often, even by the author himself. Last time I checked it still lacked the obvious rule to allow putting BODY in HTML, and I had to define that instance myself. But this is only a small wart, and the library proved to be quite useful for me. > I'm announcing it here because I hope the audience is fairly > small but discerning, and I'm announcing it at all because > I've run out of steam for the moment. This is the first code > above the size of a nonce-programme that I've written since > I got ill years ago, so don't go too hard on me! I hope you won't consider my response hard ;-) Perhaps you could borrow some ideas from Peter's code, or vice versa. Best regards Tomasz From isaacdupree at charter.net Tue Jan 8 09:21:28 2008 From: isaacdupree at charter.net (Isaac Dupree) Date: Tue Jan 8 09:15:02 2008 Subject: [Fwd: Re: Maps] In-Reply-To: <47835ED6.3080709@dfki.de> References: <47835ED6.3080709@dfki.de> Message-ID: <478386E8.7020206@charter.net> >> interval :: k -> k -> Map k v -> Map k v > (k -> Ordering) -> Map k v -> Map k v > Yes. But I think what you need to efficiently implement this is some > sort of implicit cut, of the form (k -> Something) -> Map k v -> (Map k > v, Map k v). The reason you might not be able to provide the keys yourself is that you can't (efficiently or at all) decide the exact right cutoff value, but you can provide a function that tells whether a key is too high, or too low, or in-range? That makes sense to me. I've even had cases where I wished there was a lookup that didn't require me to convert the key I was trying to look up, into the same type. I guess it would be unsafe though, since then the Map can't guarantee that it's a monotonic function relative to the (compare :: k -> k -> Ordering) that it typically uses -Isaac From jon.fairbairn at cl.cam.ac.uk Tue Jan 8 09:43:08 2008 From: jon.fairbairn at cl.cam.ac.uk (Jon Fairbairn) Date: Tue Jan 8 09:36:56 2008 Subject: Announcement: Typeful [x]html combinators -- pre-release 0 References: <20080108131510.GA13897@lambda> Message-ID: Tomasz Zielonka writes: > On Tue, Dec 18, 2007 at 05:38:47PM +0000, Jon Fairbairn wrote: >> ... or, "whoops! I've writtten another html combinator library." >> >> History: I was surprised to find that all the Haskell html >> generating stuff I've tried allowed one to construct invalid >> HTML. > > Did you take a look at Peter Thiemann's WASH/HTML? I did. > It contains a monadic combinator library that checks > proper nesting of HTML tags at compile time. The library > also has an unchecked version, It's possible that I only tried the unchecked version: I just thought of an invalid example, read what documentation I could find and generated some invalid html. However, Thiemann's thesis says The current library implements neither inclusions nor exceptions. So I hope I might be forgiven if I overlooked a difference between the distribution and the thesis! Does the checked version now enforce appendix B and prevent appearing anywhere within and so on? >> I'm announcing it here because I hope the audience is fairly >> small but discerning, and I'm announcing it at all because >> I've run out of steam for the moment. This is the first code >> above the size of a nonce-programme that I've written since >> I got ill years ago, so don't go too hard on me! > > I hope you won't consider my response hard ;-) No; and if WASH /can/ now enforce all the restrictions but isn't generally used that way, I think that's a pity (and making it easier to find how to do this would be a big improvement). > Perhaps you could borrow some ideas from Peter's code, or vice versa. It turns out that the mechanism I've used to enforce the restrictions is almost the same as the one he mentions in the thesis as being too awkward, except that I don't in fact need 98 type parameters, just fourteen... and I disagree with his statement that moving to xhtml means that implementing the restrictions is unnecesary -- W3C says that the informal description is the normative definition, not the DTD. Another difference is that I haven't used any non-Haskell 98 constructs other than using Template Haskell to generate class declarations and instances (were one so inclined, one could get ghc to output the splices and [clean them up by hand to] produce an entirely H98 version). -- J?n Fairbairn Jon.Fairbairn@cl.cam.ac.uk From jon.fairbairn at cl.cam.ac.uk Tue Jan 8 11:32:26 2008 From: jon.fairbairn at cl.cam.ac.uk (Jon Fairbairn) Date: Tue Jan 8 11:26:13 2008 Subject: Announcement: Typeful [x]html combinators -- pre-release 0 References: <2608b8a80712190031m61d29600tbea7eb6d0d51fd6@mail.gmail.com> <1199717841.6547.8.camel@mben-desktop> <1199790876.6707.18.camel@mben-desktop> Message-ID: Mattias Bengtsson writes: > On Tue, 2008-01-08 at 10:31 +0000, Jon Fairbairn wrote: >> Thanks for finding that (I do hate the way that the W3C >> issues proper formal definitions of things but makes the >> informal one the normative one); [...] > > Yes this is really frustrating. Indeed! > I think the schema is supposed to enforce nesting restrictions. At least > that's how i interpret paragraph 1.3[1] in the Note. It doesn't seem to > be able to enforce everything though (eg. the legend example in 1.3). You may be right. The schema is not the easiest thing in the world to read (whoever said that it was strange how people who complained for years that lisp had too many brackets now endorse XML had it right), but I think the "content model for exclusions" parts cover this. -- J?n Fairbairn Jon.Fairbairn@cl.cam.ac.uk From apfelmus at quantentunnel.de Tue Jan 8 15:09:52 2008 From: apfelmus at quantentunnel.de (apfelmus) Date: Tue Jan 8 15:03:48 2008 Subject: [Fwd: Re: Maps] In-Reply-To: <47835ED6.3080709@dfki.de> References: <47835ED6.3080709@dfki.de> Message-ID: Christian Maeder wrote: > So here's an approximation of my problem. I have a map of objects, > possibly aggregated from different sources. They have (in a case of > medium complexity) type (t,u) where the t represents the source and u > represents the position within that source. > > I need to efficiently represent ranges of objects to be viewed or > deleted from this map, in such a way that the map library can extract or > delete them quickly. But I might have, say, only a t value, and no > values of u available. If you can specify unbounded ranges like None and All, (a < t < b, All) would do the trick (together with the usual ordering on pairs). You can probably retrofit them on any existing data type that expresses sets/intervals/ranges of values. data Universal r = None | Concrete r | All instance Ranged r => Ranged (Universal r) where range x y = ... union All _ = All ... > Also, I'm sort of curious: in C/C++/Java/etc, you can produce a Dense > type which has: > > instance (Eq, Ord, Bounded) Dense > between :: Dense -> Dense -> Dense -- if a < b then a < between a b < b > > This is sort of a lie: between is not referentially transparent, in that > two calls to (between a b) may produce results that aren't ==. > > Still, the efficiency is impressive: > ==, >, <, etc are O(1) > 'between' is O(log n) where n Dense's are currently live. You can > actually make it O(1), but the constant is big, so people don't. > total space usage is O(n) integers of 2(log n) bits each I assume the O(1) are O(log n) in "reality" but that n < 2^32 because they are machine word integers? > Is there any way to even approach this in Haskell? Well, the first thing to try is to just use a constructor for between : data Dense = First | Between Dense Dense | Last deriving (Eq) with some clever Ord instance. However, the specification is not complete, what should let half = between a b q1 = between a half q3 = between half b in compare (between q1 q3) half be? If it doesn't matter at all, you can probably use the Stern-Brocot tree i.e. between (a :/ b) (c :/ d) = (a + b) :/ (c + d) with the usual ordering on rational numbers. But you probably won't get the same performance with that: the number of Between constructors or the size in bit of the denominators/numerators grows linearly with the number of between operations. This is unavoidable since there are ~ 2^k values that can be represented with k applications of between . To get better performance, you have drop referential transparency and exploit that only a tiny fraction (namely n ) of these possible 2^k will ever come into existence. Regards, apfelmus From iavor.diatchki at gmail.com Tue Jan 8 18:11:05 2008 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Tue Jan 8 18:04:44 2008 Subject: PROPOSAL: Some more 'Applicative' combinators In-Reply-To: References: <5ab17e790801061335t59d53588s2c935067457bde0e@mail.gmail.com> <4781B685.7050500@serpentine.com> <5ab17e790801062254x41e52005n78723b5c73fa7b71@mail.gmail.com> Message-ID: <5ab17e790801081511p748dcdafo3dcbe4e92c892ebe@mail.gmail.com> Hello, On Jan 8, 2008 1:43 AM, apfelmus wrote: > Iavor Diatchki wrote: > > Bryan O'Sullivan wrote: > >> Why not make the task specificity clearer, with a separate > >> Control.Applicative.Parsing module? > > +1 > > > Now _this_ would definitely suggest that they are only good for > > parsing which would be misleading. > > Would it? I mean, I currently don't know a second use case for them. > Preferably, the names like skipMany , endBy , sepBy etc. should still > make sense in the new context. Yes it would. The name Control.Applicative.Parsing certainly suggests that. We should not overdo the granularity of the modules in the library. What would be the benefit of having a separate module? By the way, the combinators are all variations of 'many': 'skipMany' is just like 'many' but ignoring the results; 'endBy' performs a "cleanup" computation after each iteration; "sepBy" performs a "cleanup" operation between iterations. As I said before, these are just ordinary control structures. -Iavor From twanvl at gmail.com Tue Jan 8 18:58:54 2008 From: twanvl at gmail.com (Twan van Laarhoven) Date: Tue Jan 8 18:52:23 2008 Subject: Add 'subsequences' and 'permutations' to Data.List (ticket #1990), discussion period end In-Reply-To: <4767F0AE.8020006@gmail.com> References: <4767F0AE.8020006@gmail.com> Message-ID: <47840E3E.5020100@gmail.com> Twan van Laarhoven wrote: > Hello all, > > As Thomas Hartman noted in a recent cafe thread [1], haskell 1.3 > included the functions 'subsequences' and 'permutations'. I think these > functions are quite useful, and I don't know why they were ever removed. > This is a proposal to add these two functions to Data.List. The > implementation is taken directly from the Haskell 1.3 report [2]. > > Trac ticket: #1990 > Discussion period ends: January 7th (since there is a holiday comming up) The discussion period for this proposal is over. Everyone here seems to agree it is a good idea. The patch attached to the trac ticket contains the best versions discussed in this thread: - Wolfram(kahl@cas.mcmaster.ca)'s version of subsequences - my permutations8c Can someone with the power to do so apply this patch? Twan From apfelmus at quantentunnel.de Wed Jan 9 05:22:37 2008 From: apfelmus at quantentunnel.de (apfelmus) Date: Wed Jan 9 05:16:23 2008 Subject: PROPOSAL: Some more 'Applicative' combinators In-Reply-To: <5ab17e790801081511p748dcdafo3dcbe4e92c892ebe@mail.gmail.com> References: <5ab17e790801061335t59d53588s2c935067457bde0e@mail.gmail.com> <4781B685.7050500@serpentine.com> <5ab17e790801062254x41e52005n78723b5c73fa7b71@mail.gmail.com> <5ab17e790801081511p748dcdafo3dcbe4e92c892ebe@mail.gmail.com> Message-ID: Bryan O'Sullivan wrote: > Why not make the task specificity clearer, with a separate > Control.Applicative.Parsing module? Iavor Diatchki wrote: > What would be the benefit of having a separate module? Well, putting those combinators in Control.Applicative would suggest that applicative functors are for parsing only :) > By the way, the combinators are all variations of 'many': 'skipMany' > is just like 'many' but ignoring the results; 'endBy' performs a > "cleanup" computation after each iteration; "sepBy" performs a > "cleanup" operation between iterations. As I said before, these are > just ordinary control structures. What I want to say is that I doubt that many and friends are general purpose. Is there an example of an applicative functor that is not a parser but for which many , skipMany and so on make sense / are useful? For [] and Maybe, both many [1] many $ Just 1 just give a stack overflow. Regards, apfelmus From ahey at iee.org Wed Jan 9 05:27:16 2008 From: ahey at iee.org (Adrian Hey) Date: Wed Jan 9 05:20:54 2008 Subject: Tests in Cabal Message-ID: <4784A184.6080708@iee.org> Hello, I've been playing about with the option to add tests to packages and have modified the Setup.hs as follows.. import Distribution.Simple import MyPackage main :: IO () main = defaultMainWithHooks (simpleUserHooks {runTests = myTests}) myTests :: Args -> Bool -> PackageDescription -> LocalBuildInfo -> IO () myTests _ _ _ _ = Which I think is the right thing to do if I understand the docs. The first problem I come up against is that in order to do this practically all the modules from the package need compiling by runghc (even during the configure stage presumably). As I guess most people will be using runHaskell/runghc to do this it seems like this will all take quite a bit of time. In my case the process fails completely because the package library files need CPPing and is seems runghc doesn't do this (by default at least). Is this really the way tests are supposed to be included? It doesn't seem workable to me. I wonder if it would be better to just build the lib first (without tests) and then separately build one or more test executables? What does everyone else do about this? Thanks -- Adrian Hey From simonpj at microsoft.com Wed Jan 9 06:48:00 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Wed Jan 9 06:41:37 2008 Subject: typo in Foreign.Ptr.minusPtr documentation In-Reply-To: References: Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C30BA9B71315@EA-EXMSG-C334.europe.corp.microsoft.com> Thanks. I'll fix that. S | -----Original Message----- | From: libraries-bounces@haskell.org [mailto:libraries-bounces@haskell.org] On Behalf Of Henning Thielemann | Sent: 08 January 2008 11:37 | To: libraries@haskell.org | Subject: typo in Foreign.Ptr.minusPtr documentation | | | http://www.haskell.org/ghc/docs/latest/html/libraries/base/Foreign-Ptr.html#v%3AminusPtr | | The description "Computes the offset required to get from the first to | the second argument." contradicts to the formula | p2 == p1 `plusPtr` (p2 `minusPtr` p1) | | It should be "Computes the offset required to get from the second to | the first argument." | _______________________________________________ | Libraries mailing list | Libraries@haskell.org | http://www.haskell.org/mailman/listinfo/libraries From duncan.coutts at worc.ox.ac.uk Wed Jan 9 08:39:21 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Jan 9 08:34:15 2008 Subject: Tests in Cabal In-Reply-To: <4784A184.6080708@iee.org> References: <4784A184.6080708@iee.org> Message-ID: <1199885961.7279.125.camel@localhost> On Wed, 2008-01-09 at 10:27 +0000, Adrian Hey wrote: > Is this really the way tests are supposed to be included? > > It doesn't seem workable to me. I wonder if it would be better to just > build the lib first (without tests) and then separately build one or > more test executables? > > What does everyone else do about this? I've only seen one package that actually uses tests integrated into the Setup.hs. So it seems everyone just runs tests manually. This is a fairly large hole in the Cabal story at the moment imho. Part of the problem is that we don't support custom Setup.hs stuff very well, we encourage people to use the simple build system. But for tests, even if it used the simple build system we'd end up making it use the custom flavour just to run some tests. It's not very satisfactory. I wonder if we shouldn't move tests into their own file completely. The problem always with custom Setup.hs scripts is that they're the first point of entry, and if it does not compile then everything is stuffed and you don't get a good error message. Duncan From lemming at henning-thielemann.de Wed Jan 9 08:49:08 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed Jan 9 08:45:58 2008 Subject: Tests in Cabal In-Reply-To: <1199885961.7279.125.camel@localhost> References: <4784A184.6080708@iee.org> <1199885961.7279.125.camel@localhost> Message-ID: On Wed, 9 Jan 2008, Duncan Coutts wrote: > On Wed, 2008-01-09 at 10:27 +0000, Adrian Hey wrote: > > > Is this really the way tests are supposed to be included? > > > > It doesn't seem workable to me. I wonder if it would be better to just > > build the lib first (without tests) and then separately build one or > > more test executables? > > > > What does everyone else do about this? > > I've only seen one package that actually uses tests integrated into the > Setup.hs. So it seems everyone just runs tests manually. This is a > fairly large hole in the Cabal story at the moment imho. > > Part of the problem is that we don't support custom Setup.hs stuff very > well, we encourage people to use the simple build system. But for tests, > even if it used the simple build system we'd end up making it use the > custom flavour just to run some tests. It's not very satisfactory. > > I wonder if we shouldn't move tests into their own file completely. ... as it is planned for executables, right? I used the Cabal test mechanism once, but it was not portable between different versions of Cabal. Thus I added an Executable stanza to the Cabal file and run the resulting test binary by darcs. Of course I think that in the long run tests should be managed by Cabal somehow in order to let Hackage check uploaded packages against their test suites or in order to let compiler implementors check whether new compiler versions break existing code. From judah.jacobson at gmail.com Wed Jan 9 13:08:20 2008 From: judah.jacobson at gmail.com (Judah Jacobson) Date: Wed Jan 9 13:01:55 2008 Subject: Proposal: Add --with-libedit flag to the readline package Message-ID: <6d74b0d20801091008m2ae7ff07h9dd2b33b0c83c6cd@mail.gmail.com> It would be useful for the readline package to support compiling against the libedit library (which provides a subset of the readline APIs): - libedit is available by default on OS X. - since libedit is BSD-licensed, there are no problems statically linking ghc with it. (This may be useful on Windows.) I propose adding a --with-libedit flag to the readline autoconf script. Without that flag, the package will behave exactly as before, refusing to link against libedit. With that flag, the following behavior occurs: - GNUreadline.framework (OS X - only) is ignored, if present - We try to link with -lreadline, and don't fail if readline is actually libedit. - If it is libedit, we #ifdef out all of the functions not supported by libedit. (these are generally low-level APIs not needed by most applications, including ghci.) Otherwise, if we're linking against GNU readline, we support all the available APIs. Suggested deadline: Jan. 23, 2008. A patch is attached to the trac ticket: http://hackage.haskell.org/trac/ghc/ticket/2028 Thoughts? -Judah From kahl at cas.mcmaster.ca Wed Jan 9 13:11:34 2008 From: kahl at cas.mcmaster.ca (kahl@cas.mcmaster.ca) Date: Wed Jan 9 13:09:29 2008 Subject: Proposal: Add --with-libedit flag to the readline package In-Reply-To: <6d74b0d20801091008m2ae7ff07h9dd2b33b0c83c6cd@mail.gmail.com> (judah.jacobson@gmail.com) References: <6d74b0d20801091008m2ae7ff07h9dd2b33b0c83c6cd@mail.gmail.com> Message-ID: <20080109181134.22647.qmail@schroeder.cas.mcmaster.ca> Judah Jacobson" wrote: > > It would be useful for the readline package to support compiling > against the libedit library (which provides a subset of the readline > APIs): > > - libedit is available by default on OS X. > - since libedit is BSD-licensed, there are no problems statically > linking ghc with it. (This may be useful on Windows.) > > I propose adding a --with-libedit flag to the readline autoconf > script. Without that flag, the package will behave exactly as before, > refusing to link against libedit. With that flag, the following > behavior occurs: > > - GNUreadline.framework (OS X - only) is ignored, if present > - We try to link with -lreadline, and don't fail if readline is > actually libedit. > - If it is libedit, we #ifdef out all of the functions not supported > by libedit. (these are generally low-level APIs not needed by most > applications, including ghci.) Otherwise, if we're linking against GNU > readline, we support all the available APIs. In my opinion, a flag with these effects should be called ``--allow-libedit''. For the flag ``--with-libedit'' I would expect: - We try to link with -ledit first. - Only if that fails, we try whether we can get libedit via -lreadline. - If we cannot get libedit, we fail. This makes it easier to produce libedit-linked binaries on systems that do have libreadline. Wolfram From ketil+haskell at ii.uib.no Wed Jan 9 14:52:35 2008 From: ketil+haskell at ii.uib.no (Ketil Malde) Date: Wed Jan 9 14:46:20 2008 Subject: Announcement: Typeful [x]html combinators -- pre-release 0 In-Reply-To: <1199717841.6547.8.camel@mben-desktop> (Mattias Bengtsson's message of "Mon\, 07 Jan 2008 15\:57\:21 +0100") References: <2608b8a80712190031m61d29600tbea7eb6d0d51fd6@mail.gmail.com> <1199717841.6547.8.camel@mben-desktop> Message-ID: <87ejcq93p8.fsf@nmd9999.imr.no> Mattias Bengtsson writes: > Making a program for generating ADT's and combinators from XML schemas > to provide type safe XML is something i'd very much like to do someday. > One thing i'm uncertain of is whether supporting namespaces would be a > problem or not. It would be a shame to have a bunch of generated > XML-standards in Haskell that can't be used together (ie. embedding > MathML or SVG in XHTML). How /can/ one check validity of namespace-using XML? Do you have a separate DTD (or Schema, if you think DTDs are too easy to read) for each namespace? If so, how do you specify where foreign namespaces are legal? If the top-level DTD specifies -- and thus needs to know, in advance, the details about -- the sub-namespaces, then what's the point of namespaces at all? I'm confused. -k -- If I haven't seen further, it is by standing in the footprints of giants From moonlite at dtek.chalmers.se Wed Jan 9 18:49:29 2008 From: moonlite at dtek.chalmers.se (Mattias Bengtsson) Date: Wed Jan 9 18:43:17 2008 Subject: Announcement: Typeful [x]html combinators -- pre-release 0 In-Reply-To: <87ejcq93p8.fsf@nmd9999.imr.no> References: <2608b8a80712190031m61d29600tbea7eb6d0d51fd6@mail.gmail.com> <1199717841.6547.8.camel@mben-desktop> <87ejcq93p8.fsf@nmd9999.imr.no> Message-ID: <1199922570.21633.218.camel@localhost.localdomain> On Wed, 2008-01-09 at 20:52 +0100, Ketil Malde wrote: > How /can/ one check validity of namespace-using XML? Do you have a > separate DTD (or Schema, if you think DTDs are too easy to read) for > each namespace? I'm not 100% sure but i believe so yes. XML Schemas enforces more properties than a DTD and are hence of more value (to me at least). > If so, how do you specify where foreign namespaces > are legal? If the top-level DTD specifies -- and thus needs to know, > in advance, the details about -- the sub-namespaces, then what's the > point of namespaces at all? This is exactly what i'm also having trouble understanding. Need to read more! > I'm confused. So am i. :) Mattias -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://www.haskell.org/pipermail/libraries/attachments/20080110/ad04a8d0/attachment.bin From ketil+haskell at ii.uib.no Thu Jan 10 04:05:49 2008 From: ketil+haskell at ii.uib.no (Ketil Malde) Date: Thu Jan 10 03:59:32 2008 Subject: Announcement: Typeful [x]html combinators -- pre-release 0 In-Reply-To: <1199922570.21633.218.camel@localhost.localdomain> (Mattias Bengtsson's message of "Thu\, 10 Jan 2008 00\:49\:29 +0100") References: <2608b8a80712190031m61d29600tbea7eb6d0d51fd6@mail.gmail.com> <1199717841.6547.8.camel@mben-desktop> <87ejcq93p8.fsf@nmd9999.imr.no> <1199922570.21633.218.camel@localhost.localdomain> Message-ID: <87fxx66oeq.fsf@nmd9999.imr.no> Mattias Bengtsson writes: >> If so, how do you specify where foreign namespaces >> are legal? If the top-level DTD specifies -- and thus needs to know, >> in advance, the details about -- the sub-namespaces, then what's the >> point of namespaces at all? > This is exactly what i'm also having trouble understanding. Need to read > more! >> I'm confused. > So am i. :) Well - I just found some links. A schema can contain import statements, basically #include'ing other schemas: http://lists.xml.org/archives/xml-dev/200211/msg00880.html For DTD's, I think you'd have to write the DTD to use the prefix (I forget the proper name for it) and the local name - but I've lost the link that said so. So for both Schema and DTD validation, you'd need to know in advance all the tags you'd like to use, but Schema lets you more easily reuse 'chunks' of the document definition (or XML grammar). Stray thought: I'm currently working on a storage for various data types. Due to the variety, I'm considering XML rather than SQL, and it occurs to me that SQL relations are product types, while XML defines an algebraic data type. E.g., we can straightforwardly translate: => data ElementName = ElementName ChildName => data ElementName = ElementName Child1 Child2 => data ElementName = ElementName (Maybe Child) => data ElementName = ElementName [Child] => data ElementName = ElementName1 Child1 | ElementName2 Child2 Well - presumably, something like that is exactly what you do to produce verifiable XML, right? In my mind, the 'algebraic' data types have always been a practical thing, but I suppose there is a formal framework where both Haskell data types and XML are unified as examples of 'algebraically complete' systems? Basica stuff I guess, it just never occurred to me to combine the terms 'universal algebra' and 'XML' before. :-) -k -- If I haven't seen further, it is by standing in the footprints of giants From tomasz.zielonka at gmail.com Thu Jan 10 07:21:17 2008 From: tomasz.zielonka at gmail.com (Tomasz Zielonka) Date: Thu Jan 10 06:14:51 2008 Subject: Announcement: Typeful [x]html combinators -- pre-release 0 In-Reply-To: References: <20080108131510.GA13897@lambda> Message-ID: <20080110122117.GA4567@lambda> On Tue, Jan 08, 2008 at 02:43:08PM +0000, Jon Fairbairn wrote: > > It contains a monadic combinator library that checks > > proper nesting of HTML tags at compile time. The library > > also has an unchecked version, > > It's possible that I only tried the unchecked version: I > just thought of an invalid example, read what documentation > I could find and generated some invalid html. That's an easy trap to fall into, especially because the author seems to use only unchecked combinators in examples ;-) > However, > Thiemann's thesis says > > The current library implements neither inclusions nor > exceptions. > > So I hope I might be forgiven if I overlooked a difference > between the distribution and the thesis! Does the checked > version now enforce appendix B and prevent appearing > anywhere within and so on? I am not familiar with the HTML standards enough to understand everything you say here, but I've just checked that you can't put inside using the checked combinators. But I can't say if it checks everything your library checks. > Another difference is that I haven't used any non-Haskell 98 > constructs other than using Template Haskell to generate > class declarations and instances (were one so inclined, one > could get ghc to output the splices and [clean them up by > hand to] produce an entirely H98 version). I can't think of any non-haskell 98 extensions that were used in WASH/HTML, but I may be overlooking something. At least the interface of WASH.HTML.HTMLMonad98 looks quite standard. Best regards Tomasz From ahey at iee.org Thu Jan 10 06:24:42 2008 From: ahey at iee.org (Adrian Hey) Date: Thu Jan 10 06:18:17 2008 Subject: Tests in Cabal In-Reply-To: <1199885961.7279.125.camel@localhost> References: <4784A184.6080708@iee.org> <1199885961.7279.125.camel@localhost> Message-ID: <4786007A.5050201@iee.org> Duncan Coutts wrote: > On Wed, 2008-01-09 at 10:27 +0000, Adrian Hey wrote: > >> Is this really the way tests are supposed to be included? >> >> It doesn't seem workable to me. I wonder if it would be better to just >> build the lib first (without tests) and then separately build one or >> more test executables? >> >> What does everyone else do about this? > > I've only seen one package that actually uses tests integrated into the > Setup.hs. So it seems everyone just runs tests manually. This is a > fairly large hole in the Cabal story at the moment imho. > > Part of the problem is that we don't support custom Setup.hs stuff very > well, we encourage people to use the simple build system. But for tests, > even if it used the simple build system we'd end up making it use the > custom flavour just to run some tests. It's not very satisfactory. > > I wonder if we shouldn't move tests into their own file completely. The > problem always with custom Setup.hs scripts is that they're the first > point of entry, and if it does not compile then everything is stuffed > and you don't get a good error message. One thing I've been trying today is building the test program as a separate executable and then having Setup.hs run this.. import Distribution.Simple import Distribution.PackageDescription(PackageDescription) import Distribution.Simple.LocalBuildInfo(LocalBuildInfo) import System.Cmd(system) main :: IO () main = defaultMainWithHooks (simpleUserHooks {runTests = myTests}) myTests:: Args -> Bool -> PackageDescription -> LocalBuildInfo -> IO () myTests_ _ _ _ = system "myTestProgram" >> return () But I don't still don't seem to be able to build myTestProgram.hs because it depends on the lib package which has just been built but not yet registered. But I guess there might be some cabal file or ghc-options magic that would make this possible without ghc trying (and failing) to recompile the entire library. Can anyone explain how to do this? Thanks -- Adrian Hey From gale at sefer.org Thu Jan 10 07:17:41 2008 From: gale at sefer.org (Yitzchak Gale) Date: Thu Jan 10 07:11:15 2008 Subject: Announcement: Typeful [x]html combinators -- pre-release 0 In-Reply-To: <87fxx66oeq.fsf@nmd9999.imr.no> References: <2608b8a80712190031m61d29600tbea7eb6d0d51fd6@mail.gmail.com> <1199717841.6547.8.camel@mben-desktop> <87ejcq93p8.fsf@nmd9999.imr.no> <1199922570.21633.218.camel@localhost.localdomain> <87fxx66oeq.fsf@nmd9999.imr.no> Message-ID: <2608b8a80801100417u38fe7b6j90a71015af1119@mail.gmail.com> Ketil Malde wrote: >>> If so, how do you specify where foreign namespaces >>> are legal? If the top-level DTD specifies -- and thus needs to know, >>> in advance, the details about -- the sub-namespaces, then what's the >>> point of namespaces at all? > Well - I just found some links. A schema can contain import > statements, basically #include'ing other schemas: > http://lists.xml.org/archives/xml-dev/200211/msg00880.html > ...So for both Schema and DTD validation, you'd need to know in advance > all the tags you'd like to use, You can combine them using Schematron: http://www.schematron.com/overview.html It even allows you to mix validation languages, e.g., DTD, XML Schema, Relax NG, etc. -Yitz From simonmarhaskell at gmail.com Thu Jan 10 09:33:40 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Thu Jan 10 09:27:16 2008 Subject: Add 'subsequences' and 'permutations' to Data.List (ticket #1990), discussion period end In-Reply-To: <47840E3E.5020100@gmail.com> References: <4767F0AE.8020006@gmail.com> <47840E3E.5020100@gmail.com> Message-ID: <47862CC4.3080206@gmail.com> Twan van Laarhoven wrote: > Twan van Laarhoven wrote: >> Hello all, >> >> As Thomas Hartman noted in a recent cafe thread [1], haskell 1.3 >> included the functions 'subsequences' and 'permutations'. I think >> these functions are quite useful, and I don't know why they were ever >> removed. This is a proposal to add these two functions to Data.List. >> The implementation is taken directly from the Haskell 1.3 report [2]. >> >> Trac ticket: #1990 >> Discussion period ends: January 7th (since there is a holiday comming up) > > The discussion period for this proposal is over. Everyone here seems to > agree it is a good idea. > > The patch attached to the trac ticket contains the best versions > discussed in this thread: > - Wolfram(kahl@cas.mcmaster.ca)'s version of subsequences > - my permutations8c > > Can someone with the power to do so apply this patch? I've milestoned it for inclusion in GHC 6.10. Cheers, Simon From jon.fairbairn at cl.cam.ac.uk Thu Jan 10 14:01:23 2008 From: jon.fairbairn at cl.cam.ac.uk (Jon Fairbairn) Date: Thu Jan 10 13:55:12 2008 Subject: Announcement: Typeful [x]html combinators -- pre-release 0 References: <20080108131510.GA13897@lambda> <20080110122117.GA4567@lambda> Message-ID: Tomasz Zielonka writes: > On Tue, Jan 08, 2008 at 02:43:08PM +0000, Jon Fairbairn wrote: >> > It contains a monadic combinator library that checks >> > proper nesting of HTML tags at compile time. The library >> > also has an unchecked version, >> >> It's possible that I only tried the unchecked version: I >> just thought of an invalid example, read what documentation >> I could find and generated some invalid html. > > That's an easy trap to fall into, especially because the author seems to > use only unchecked combinators in examples ;-) That's a bit of a strange thing to do. Having gone to the trouble of setting things up so that it can check (some degree of) validity, why not use it? Isn't this what Haskell is about? Exploring WaSH isn't made easy by the documentation; if I try build_document (html (head (title (text "foo")) ## (body (h1 (text "foo"))))) -- essentially the first example from the pdf of the paper "A Typed Representation for HTML and XML documents in Haskell" -- I get :1:16: No instance for (AddTo HTML HTML) arising from use of `html' at :1:16-75 Possible fix: add an instance declaration for (AddTo HTML HTML) In the first argument of `build_document', namely `(html ((head (title (text "foo"))) ## (body (h1 (text "foo")))))' In the expression: build_document (html ((head (title (text "foo"))) ## (body (h1 (text "foo"))))) In the definition of `it': it = build_document (html ((head (title (text "foo"))) ## (body (h1 (text "foo"))))) and I don't know what's changed since the paper, or what I'm doing wrong -- how do I get it to output something? (This is with WASH.HTML.HTMLPrelude, but similar questions arise for WASH.HTML.HTMLMonad98) unELT $ html (body (h1 $ img empty)) (make DOCUMENT) outputs something, but it's not valid (no head), so that can't be right. >> Thiemann's thesis says Actually, I meant the abovementioned paper. >> The current library implements neither inclusions nor >> exceptions. >> >> So I hope I might be forgiven if I overlooked a difference >> between the distribution and the thesis! Does the checked >> version now enforce appendix B and prevent appearing >> anywhere within and so on? > > I am not familiar with the HTML standards enough to understand > everything you say here, I'd sort-of hope that a proper HTML library would relieve you of that responsibility! > but I've just checked that you can't put > inside using the checked combinators. But I can't say if it > checks everything your library checks. It doesn't: the issue is not directly in : *WASH.HTML.HTMLPrelude> :t a (a (text "foo")) :1:3: No instance for (AddTo A A) arising from use of `a' at :1:3-16 Possible fix: add an instance declaration for (AddTo A A) In the first argument of `a', namely `(a (text "foo"))' (it properly rejects that), but anywhere within : *WASH.HTML.HTMLPrelude> :t a (span (a (text "foo"))) a (span (a (text "foo"))) :: (AddTo s A) => ELT s -> ELT s which should also be rejected. Here's what happens with my version: Prelude Typeful.Text.HTMLs> :t a << a << string "foo" :1:5: No instance for (Is_A A_not_allowed_in_A) arising from use of `a' at :1:5 Possible fix: add an instance declaration for (Is_A A_not_allowed_in_A) In the first argument of `(<<)', namely `a' In the second argument of `(<<)', namely `a << (string "foo")' and Typeful.Text.HTMLs> :t a << span << a << string "foo" :1:13: No instance for (Is_A A_not_allowed_in_A) arising from use of `a' at :1:13 Possible fix: add an instance declaration for (Is_A A_not_allowed_in_A) In the first argument of `(<<)', namely `a' In the second argument of `(<<)', namely `a << (string "foo")' In the second argument of `(<<)', namely `span << (a << (string "foo"))' I'm not especially enamoured of the "<<" syntax; it's just what's used in the current html and xhtml libraries, so I did something similar. >> Another difference is that I haven't used any non-Haskell 98 >> constructs other than using Template Haskell to generate >> class declarations and instances (were one so inclined, one >> could get ghc to output the splices and [clean them up by >> hand to] produce an entirely H98 version). > > I can't think of any non-haskell 98 extensions that were used in > WASH/HTML, but I may be overlooking something. At least the interface of > WASH.HTML.HTMLMonad98 looks quite standard. count the number of arguments of the class WithHTML (or AddTo in the above)... ;-) -- J?n Fairbairn Jon.Fairbairn@cl.cam.ac.uk From fmartini at gmail.com Thu Jan 10 17:56:37 2008 From: fmartini at gmail.com (Felix Martini) Date: Thu Jan 10 17:50:08 2008 Subject: Proposal: new version of getModificationTime Message-ID: <6c0416190801101456s3810f470ud295d6d3003619f4@mail.gmail.com> Hello all, Function getModificationTime in System.Directory returns ClockTime. ClockTime is part of the old-time package. The (new) time package has UTCTime, so i propose a new version of getModificationTime that returns UTCTime instead. I am not sure what a good name for the new version would be, perhaps getModificationUTCTime? Regards, Felix From fmartini at gmail.com Fri Jan 11 09:29:25 2008 From: fmartini at gmail.com (Felix Martini) Date: Fri Jan 11 09:22:54 2008 Subject: Proposal: new version of getModificationTime In-Reply-To: <6c0416190801101456s3810f470ud295d6d3003619f4@mail.gmail.com> References: <6c0416190801101456s3810f470ud295d6d3003619f4@mail.gmail.com> Message-ID: <6c0416190801110629h5bc8b04ek897f92f80933bc8d@mail.gmail.com> One issue about my proposal is that directory and old-time are part of the boot packages and time is not. But if the time package is really set to replace old-time eventually, then it seems logical to make time a boot library as well. Should i create a proposal on trac for that? Regards, Felix From igloo at earth.li Fri Jan 11 10:56:03 2008 From: igloo at earth.li (Ian Lynagh) Date: Fri Jan 11 10:49:32 2008 Subject: Proposal: Add --with-libedit flag to the readline package In-Reply-To: <6d74b0d20801091008m2ae7ff07h9dd2b33b0c83c6cd@mail.gmail.com> References: <6d74b0d20801091008m2ae7ff07h9dd2b33b0c83c6cd@mail.gmail.com> Message-ID: <20080111155603.GA29204@matrix.chaos.earth.li> Hi Judah, On Wed, Jan 09, 2008 at 10:08:20AM -0800, Judah Jacobson wrote: > > - If it is libedit, we #ifdef out all of the functions not supported > by libedit. (these are generally low-level APIs not needed by most > applications, including ghci.) Otherwise, if we're linking against GNU > readline, we support all the available APIs. > > Thoughts? I agree with Thorkil's message to the bug report (although I think the library name should be libedit or editline - I'm a bit confused about the relationship of the two). If a Haskell library or program has a build-depends on readline, then it should get the same functions everywhere; otherwise dependencies are meaningless. If a program wants to support both libraries then it can do something like If flag(readline) Build-depends: readline CPP-flags: -DUSING_READLINE Else Build-depends: editline CPP-flags: -DUSING_EDITLINE Of course, a third library could do the above conditional dependency and provide an interface to the intersection of readline and editline's functionalities. Other programs can then use that third library. Thanks Ian From igloo at earth.li Fri Jan 11 11:41:27 2008 From: igloo at earth.li (Ian Lynagh) Date: Fri Jan 11 11:34:55 2008 Subject: Proposal: new version of getModificationTime In-Reply-To: <6c0416190801110629h5bc8b04ek897f92f80933bc8d@mail.gmail.com> References: <6c0416190801101456s3810f470ud295d6d3003619f4@mail.gmail.com> <6c0416190801110629h5bc8b04ek897f92f80933bc8d@mail.gmail.com> Message-ID: <20080111164127.GB29204@matrix.chaos.earth.li> On Fri, Jan 11, 2008 at 03:29:25PM +0100, Felix Martini wrote: > One issue about my proposal is that directory and old-time are part of > the boot packages and time is not. But if the time package is really > set to replace old-time eventually, then it seems logical to make time > a boot library as well. Should i create a proposal on trac for that? No, I think we should just keep it in mind while considering this proposal. If time is needed for booting ghc, then it will be made a bootlib. Thanks Ian From igloo at earth.li Fri Jan 11 11:44:19 2008 From: igloo at earth.li (Ian Lynagh) Date: Fri Jan 11 11:37:48 2008 Subject: Proposal: new version of getModificationTime In-Reply-To: <6c0416190801101456s3810f470ud295d6d3003619f4@mail.gmail.com> References: <6c0416190801101456s3810f470ud295d6d3003619f4@mail.gmail.com> Message-ID: <20080111164419.GC29204@matrix.chaos.earth.li> On Thu, Jan 10, 2008 at 11:56:37PM +0100, Felix Martini wrote: > Hello all, > > Function getModificationTime in System.Directory returns ClockTime. > ClockTime is part of the old-time package. The (new) time package has > UTCTime, so i propose a new version of getModificationTime that > returns UTCTime instead. I am not sure what a good name for the new > version would be, perhaps getModificationUTCTime? If we do add it with this name, then I think we should also add getModificationClockTime and mark getModificationTime as deprecated. Then we can change the type of getModificationTime at a later date. (by the way, note that Directory.getModificationTime is in Haskell 98) Thanks Ian From judah.jacobson at gmail.com Fri Jan 11 12:14:47 2008 From: judah.jacobson at gmail.com (Judah Jacobson) Date: Fri Jan 11 12:08:15 2008 Subject: Proposal: Add --with-libedit flag to the readline package In-Reply-To: <20080111155603.GA29204@matrix.chaos.earth.li> References: <6d74b0d20801091008m2ae7ff07h9dd2b33b0c83c6cd@mail.gmail.com> <20080111155603.GA29204@matrix.chaos.earth.li> Message-ID: <6d74b0d20801110914x73daf173u568b03342ee123d3@mail.gmail.com> On Jan 11, 2008 7:56 AM, Ian Lynagh wrote: > > Hi Judah, > > On Wed, Jan 09, 2008 at 10:08:20AM -0800, Judah Jacobson wrote: > > > > - If it is libedit, we #ifdef out all of the functions not supported > > by libedit. (these are generally low-level APIs not needed by most > > applications, including ghci.) Otherwise, if we're linking against GNU > > readline, we support all the available APIs. > > > > Thoughts? > > I agree with Thorkil's message to the bug report (although I think the > library name should be libedit or editline - I'm a bit confused about > the relationship of the two). > > If a Haskell library or program has a build-depends on readline, then it > should get the same functions everywhere; otherwise dependencies are > meaningless. OK, you both have convinced me. I'll get to work on an editline library. (From looking at the documentation such as "man editline", I think that is what it should be named.) I've applied for the project to be hosted on community.haskell.org. Basic features: (let me know if you think I'm wrong here) - Licensed under BSD3 (the readline package itself is licensed under GPL since it links against libreadline). - Link with -ledit (instead of -lreadline). - To start with, provide one module, System.Console.Editline.Readline. That module will be mostly a cut-and-paste of all the functions from System.Console.Readline which are supported by editline (version 5.1, as distributed on OS X 10.4). - In the future, we can provide System.Console.Editline which provides the non-readline APIs. -Judah From john at repetae.net Fri Jan 11 13:22:14 2008 From: john at repetae.net (John Meacham) Date: Fri Jan 11 13:15:44 2008 Subject: PROPOSAL: Some more 'Applicative' combinators In-Reply-To: <20080108005314.GP17534@scytale.galois.com> References: <5ab17e790801061335t59d53588s2c935067457bde0e@mail.gmail.com> <4781B685.7050500@serpentine.com> <5ab17e790801062254x41e52005n78723b5c73fa7b71@mail.gmail.com> <20080108005314.GP17534@scytale.galois.com> Message-ID: <20080111182214.GD3049@momenergy.repetae.net> On Mon, Jan 07, 2008 at 04:53:14PM -0800, Don Stewart wrote: > iavor.diatchki: > > Hello, > > > > On Jan 6, 2008 9:20 PM, Bryan O'Sullivan wrote: > > > While applicative functors are good for this task, it would be a shame > > > if the innocent reader of haddocks were to acquire the impression that > > > parsing was all they were for. > > > > :-) oh, come on! I was just giving an example of what these > > combinators may be used for. They are not any more related to > > parsing than say, 'many', 'some', or 'empty' and '(<|>)'---they > > provide just a few more useful control structures. > > > > > Why not make the task specificity clearer, with a separate > > > Control.Applicative.Parsing module? > > > > Now _this_ would definitely suggest that they are only good for > > parsing which would be misleading. > > +1 for this proposal. Glue for combining parsers seems like > a missing piece. Perhaps toss in an example in the docs? Actually, there is a major issue with the current 'many', 'some' etc functions in Applicative. They arn't actually useful for applicative but non-monadic parsers! in fact, they lead to infinite loops! This is quite disturbing as statically analyzed parsers were part of the motivation of splitting out applicative. The reason is that it 'hides' the self-referential nature of the function in the recursive call directly so any routine attempting to analyze the parser will go around in circles. I think the solution would be either to get rid of many, etc.. or make them members of the type class. It is not even clear to me that just because something is a member of 'Alternative' that it has a natural, meaningful notion of repetition, so perhaps they belong in their own class. John -- John Meacham - ?repetae.net?john? From judah.jacobson at gmail.com Fri Jan 11 19:19:55 2008 From: judah.jacobson at gmail.com (Judah Jacobson) Date: Fri Jan 11 19:13:22 2008 Subject: Copyright for readline/editline packages Message-ID: <6d74b0d20801111619o4a4ff48n829b81e6bea0a8fc@mail.gmail.com> Hi all, As mentioned before, I'm putting together an editline package which will provide a subset of the APIs from the readline package, but be BSD-compatible since it links against libedit. The licensing for the readline package itself is a little strange -- it's licensed under the GPL (because it links with libreadline), but there's no copyright holder information; and Readline.hsc from that package lists "Copyright: (c) unknown". I'd like to put the Haskell editline package under BSD3, but most of the code will be copied verbatim from the readline package. How should this be attributed/copyrighted? Thanks, -Judah From paul at cogito.org.uk Sat Jan 12 09:10:05 2008 From: paul at cogito.org.uk (Paul Johnson) Date: Sat Jan 12 09:03:34 2008 Subject: Copyright for readline/editline packages In-Reply-To: <6d74b0d20801111619o4a4ff48n829b81e6bea0a8fc@mail.gmail.com> References: <6d74b0d20801111619o4a4ff48n829b81e6bea0a8fc@mail.gmail.com> Message-ID: <4788CA3D.7030203@cogito.org.uk> Judah Jacobson wrote: > Hi all, > > As mentioned before, I'm putting together an editline package which > will provide a subset of the APIs from the readline package, but be > BSD-compatible since it links against libedit. > > The licensing for the readline package itself is a little strange -- > it's licensed under the GPL (because it links with libreadline), but > there's no copyright holder information; and Readline.hsc from that > package lists "Copyright: (c) unknown". > > I'd like to put the Haskell editline package under BSD3, but most of > the code will be copied verbatim from the readline package. How > should this be attributed/copyrighted Disclaimer: IANAL. Unfortunately you can't make copies without permission from the copyright holder, even if you can't trace them. So in this case you are not allowed to copy verbatim. However if, for technical or compatibility reasons there is only one possible way to write it (for instance the names and types of an API) then you can duplicate that. But you still can't copy the comments verbatim unless they are completely dictated by the code. Of course if we can track down the original author then you may be able to get some other permission from them. Paul. From naur at post11.tele.dk Sat Jan 12 09:37:04 2008 From: naur at post11.tele.dk (Thorkil Naur) Date: Sat Jan 12 09:31:35 2008 Subject: Copyright for readline/editline packages In-Reply-To: <20080112002000.YWCW22041.fep22.mail.dk@www.haskell.org> References: <20080112002000.YWCW22041.fep22.mail.dk@www.haskell.org> Message-ID: <200801121537.04851.naur@post11.tele.dk> Hello, Indeed an interesting question. Although I am no licensing expert, I guess that the intention of the GPL is that if you copy the Haskell readline code which is under the GPL and modify it, then the result will also be under the GPL. Independent development is a possibility, unless you can get hold of the copyright holder. Best regards Thorkil On Saturday 12 January 2008 01:19, Judah Jacobson wrote: > Hi all, > > As mentioned before, I'm putting together an editline package which > will provide a subset of the APIs from the readline package, but be > BSD-compatible since it links against libedit. > > The licensing for the readline package itself is a little strange -- > it's licensed under the GPL (because it links with libreadline), but > there's no copyright holder information; and Readline.hsc from that > package lists "Copyright: (c) unknown". > > I'd like to put the Haskell editline package under BSD3, but most of > the code will be copied verbatim from the readline package. How > should this be attributed/copyrighted? > > Thanks, > -Judah > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries > From isaacdupree at charter.net Sat Jan 12 11:33:36 2008 From: isaacdupree at charter.net (Isaac Dupree) Date: Sat Jan 12 11:27:07 2008 Subject: Copyright for readline/editline packages In-Reply-To: <200801121537.04851.naur@post11.tele.dk> References: <20080112002000.YWCW22041.fep22.mail.dk@www.haskell.org> <200801121537.04851.naur@post11.tele.dk> Message-ID: <4788EBE0.3070308@charter.net> Thorkil Naur wrote: > Hello, > > Indeed an interesting question. Although I am no licensing expert, I guess > that the intention of the GPL is that if you copy the Haskell readline code > which is under the GPL and modify it, then the result will also be under the > GPL. if the only copyright license granted for the Haskell-readline code is GPL (which sounds true), then it has to stay GPL. If BSD was also given as permission (it's always possible to give more permissions for the parts of something that you hold the copyright to), then, no worries, Haskell-editline can be BSD. In fact it sounds like (1) we believe the Haskell-readline code is just released under the GPL (2) we haven't even found concrete evidence that it was released with any Free license at all (although if it was released, it must be under a GPL-compatible license because it was made to link with GNU Readline, I think) The parts that cannot be written differently can be duplicated/copied anyway. I would say that attribution is a good thing (e.g. just "inspired by the Haskell-readline package" if you're making sure not to be a copyright-law "derivative work"). Finding the author would be good if we could though, because she/he/they would most likely give us BSD permissions (just guessing :-) ~Isaac From gale at sefer.org Sat Jan 12 12:17:26 2008 From: gale at sefer.org (Yitzchak Gale) Date: Sat Jan 12 12:10:52 2008 Subject: Proposal: Add --with-libedit flag to the readline package In-Reply-To: <6d74b0d20801110914x73daf173u568b03342ee123d3@mail.gmail.com> References: <6d74b0d20801091008m2ae7ff07h9dd2b33b0c83c6cd@mail.gmail.com> <20080111155603.GA29204@matrix.chaos.earth.li> <6d74b0d20801110914x73daf173u568b03342ee123d3@mail.gmail.com> Message-ID: <2608b8a80801120917v5d489bc3m21d345d0d85529b0@mail.gmail.com> Judah Jacobson wrote: > OK, you both have convinced me. I'll get to work on an editline > library. Excellent! > - To start with, provide one module, System.Console.Editline.Readline. > That module will be mostly a cut-and-paste of all the functions from > System.Console.Readline which are supported by editline (version 5.1, > as distributed on OS X 10.4). > - In the future, we can provide System.Console.Editline which provides > the non-readline APIs. I would prefer if you call it System.Console.Editline to begin with, even if it doesn't support the full API yet, so we can already start migrating our code. If you want, you can also include System.Console.Editline.Readline to provide some Readline-compatible wrappers for the new API where possible. That might help some people with backward compatibility. But for me that is a lower priority. Thanks, Yitz From judah.jacobson at gmail.com Sat Jan 12 14:11:04 2008 From: judah.jacobson at gmail.com (Judah Jacobson) Date: Sat Jan 12 14:04:29 2008 Subject: Copyright for readline/editline packages In-Reply-To: <4788EBE0.3070308@charter.net> References: <20080112002000.YWCW22041.fep22.mail.dk@www.haskell.org> <200801121537.04851.naur@post11.tele.dk> <4788EBE0.3070308@charter.net> Message-ID: <6d74b0d20801121111y36ab53acu4e2c5d8ecfdeb0ab@mail.gmail.com> On 1/12/08, Isaac Dupree wrote: > > if the only copyright license granted for the Haskell-readline code is > GPL (which sounds true), then it has to stay GPL. If BSD was also given > as permission (it's always possible to give more permissions for the > parts of something that you hold the copyright to), then, no worries, > Haskell-editline can be BSD. > > [snip] > > Finding the author would be good if we could though, because she/he/they > would most likely give us BSD permissions (just guessing :-) > > ~Isaac > Thanks all, that's pretty much what I expected. I'll try to track down the author and get BSD permissions from them. I'm having trouble accessing the history of the file hslibs/util/Readline.hsc (which was deleted before the cvs->darcs change). Can I access the pre-darcs cvs repo from somewhere? The documentation for ghc-6.4 says to use glass.cse.ogi.edu, but it looks like that server is no longer active. Also, from what I can tell, several people have made minor changes to that file (such as updating to the FFI standard or adding Haddock docs). How should I handle copyright attribution and getting permission with respect to contributors? Thanks, -Judah From judah.jacobson at gmail.com Sat Jan 12 15:00:37 2008 From: judah.jacobson at gmail.com (Judah Jacobson) Date: Sat Jan 12 14:54:03 2008 Subject: Copyright for readline/editline packages In-Reply-To: <6d74b0d20801121111y36ab53acu4e2c5d8ecfdeb0ab@mail.gmail.com> References: <20080112002000.YWCW22041.fep22.mail.dk@www.haskell.org> <200801121537.04851.naur@post11.tele.dk> <4788EBE0.3070308@charter.net> <6d74b0d20801121111y36ab53acu4e2c5d8ecfdeb0ab@mail.gmail.com> Message-ID: <6d74b0d20801121200u664c3ef1ka0f0e3ca830c7481@mail.gmail.com> On 1/12/08, Judah Jacobson wrote: > > I'm having trouble accessing the history of the file > hslibs/util/Readline.hsc (which was deleted before the cvs->darcs > change). Can I access the pre-darcs cvs repo from somewhere? The > documentation for ghc-6.4 says to use glass.cse.ogi.edu, but it looks > like that server is no longer active. Never mind, I found the repo on cvs.haskell.org. -Judah From isaacdupree at charter.net Sat Jan 12 15:45:06 2008 From: isaacdupree at charter.net (Isaac Dupree) Date: Sat Jan 12 15:38:34 2008 Subject: Copyright for readline/editline packages In-Reply-To: <6d74b0d20801121111y36ab53acu4e2c5d8ecfdeb0ab@mail.gmail.com> References: <20080112002000.YWCW22041.fep22.mail.dk@www.haskell.org> <200801121537.04851.naur@post11.tele.dk> <4788EBE0.3070308@charter.net> <6d74b0d20801121111y36ab53acu4e2c5d8ecfdeb0ab@mail.gmail.com> Message-ID: <478926D2.80700@charter.net> Judah Jacobson wrote: > Also, from what I can tell, several people have made minor changes to > that file (such as updating to the FFI standard or adding Haddock > docs). How should I handle copyright attribution and getting > permission with respect to contributors? completely mechanical changes or a single contributor contributing less than 15 lines of changes total is generally not significant for copyright.[1] The Haddock is more likely to be significant and you should probably find its author(s) too. ..although there's not very much readline docs (besides type-signatures) on http://www.haskell.org/ghc/docs/latest/html/libraries/index.html [1] http://www.gnu.org/prep/maintain/html_node/Legally-Significant.html ~Isaac From judah.jacobson at gmail.com Sat Jan 12 16:04:16 2008 From: judah.jacobson at gmail.com (Judah Jacobson) Date: Sat Jan 12 15:57:40 2008 Subject: Proposal: Add --with-libedit flag to the readline package In-Reply-To: <2608b8a80801120917v5d489bc3m21d345d0d85529b0@mail.gmail.com> References: <6d74b0d20801091008m2ae7ff07h9dd2b33b0c83c6cd@mail.gmail.com> <20080111155603.GA29204@matrix.chaos.earth.li> <6d74b0d20801110914x73daf173u568b03342ee123d3@mail.gmail.com> <2608b8a80801120917v5d489bc3m21d345d0d85529b0@mail.gmail.com> Message-ID: <6d74b0d20801121304o16e417c4lc781939429ad3f75@mail.gmail.com> On 1/12/08, Yitzchak Gale wrote: > Judah Jacobson wrote: > > OK, you both have convinced me. I'll get to work on an editline > > library. > > Excellent! > > > - To start with, provide one module, System.Console.Editline.Readline. > > That module will be mostly a cut-and-paste of all the functions from > > System.Console.Readline which are supported by editline (version 5.1, > > as distributed on OS X 10.4). > > - In the future, we can provide System.Console.Editline which provides > > the non-readline APIs. > > I would prefer if you call it System.Console.Editline to begin with, > even if it doesn't support the full API yet, so we can already > start migrating our code. > > If you want, you can also include System.Console.Editline.Readline > to provide some Readline-compatible wrappers for the new API > where possible. That might help some people with backward > compatibility. But for me that is a lower priority. I think you may have misunderstood me; let me clarify what I said above. The editline library itself provides two C interfaces: 1. , the native editline interface (http://www.hmug.org/man/3/editline.php) 2. , a subset of the APIs from GNU readline. These two interfaces do not overlap, as far as I can tell (although #2 is built on top of #1). I was proposing that they correspond to the modules 1. System.Console.Editline 2. System.Console.Editline.Readline For now, I'm only working on #2, since it'll be easier to integrate with ghci, and the code for the bindings will be nearly identical to System.Console.Readline from the readline package. But #1 would obviously be useful to have too, and we can add it at a later date. Does that address your concerns? Thanks, -Judah From gale at sefer.org Sat Jan 12 17:44:08 2008 From: gale at sefer.org (Yitzchak Gale) Date: Sat Jan 12 17:37:33 2008 Subject: Proposal: Add --with-libedit flag to the readline package In-Reply-To: <6d74b0d20801121304o16e417c4lc781939429ad3f75@mail.gmail.com> References: <6d74b0d20801091008m2ae7ff07h9dd2b33b0c83c6cd@mail.gmail.com> <20080111155603.GA29204@matrix.chaos.earth.li> <6d74b0d20801110914x73daf173u568b03342ee123d3@mail.gmail.com> <2608b8a80801120917v5d489bc3m21d345d0d85529b0@mail.gmail.com> <6d74b0d20801121304o16e417c4lc781939429ad3f75@mail.gmail.com> Message-ID: <2608b8a80801121444g131763cfwedb24578ca365d23@mail.gmail.com> Judah Jacobson wrote: > These two interfaces do not overlap, as far as I can tell... > 1. System.Console.Editline > 2. System.Console.Editline.Readline > For now, I'm only working on #2, since it'll be easier to integrate > with ghci Hmm, I see. I thought that there was some overlap. Well, in that case, the goals of native readline emulation for Mac OS X Tiger and editline support for all platforms do not overlap as much as I thought. Too bad. My point is that editline support for all platforms should be a much higher priority than removing the dependence on readline for one specific version of Mac OS X, in my opinion. So my personal preference - even as a Tiger user - would still be to work on #1 first, even if only on a core subset of features. That would make it possible to write interactive console applications in Haskell when GPL is not appropriate. Right now that is a problem on every platform. If not too hard, the next step would be to migrate GHCi to editline, allowing it to be used in a non-GPL environment on every platform. (Actually, since the ghc command has a -i option, I'm wondering why the BSD-style license on GHC is valid at all until we do this.) The third step would be System.Console.Editline.Readline, which would provide several smaller benefits - an easier migration path from Readline to Editline, an easier way for people who really want the Readline API to make their programs work on more platforms, and easier integration of Readline support on Tiger. Anyway, if you're most excited about the Tiger integration side of things, I'm all for it, go for it! Thanks, Yitz From judah.jacobson at gmail.com Sat Jan 12 19:40:35 2008 From: judah.jacobson at gmail.com (Judah Jacobson) Date: Sat Jan 12 19:33:59 2008 Subject: Proposal: Add --with-libedit flag to the readline package In-Reply-To: <2608b8a80801121444g131763cfwedb24578ca365d23@mail.gmail.com> References: <6d74b0d20801091008m2ae7ff07h9dd2b33b0c83c6cd@mail.gmail.com> <20080111155603.GA29204@matrix.chaos.earth.li> <6d74b0d20801110914x73daf173u568b03342ee123d3@mail.gmail.com> <2608b8a80801120917v5d489bc3m21d345d0d85529b0@mail.gmail.com> <6d74b0d20801121304o16e417c4lc781939429ad3f75@mail.gmail.com> <2608b8a80801121444g131763cfwedb24578ca365d23@mail.gmail.com> Message-ID: <6d74b0d20801121640t79fc82g21d98a4b02338dca@mail.gmail.com> On 1/12/08, Yitzchak Gale wrote: > Judah Jacobson wrote: > > These two interfaces do not overlap, as far as I can tell... > > 1. System.Console.Editline > > 2. System.Console.Editline.Readline > > For now, I'm only working on #2, since it'll be easier to integrate > > with ghci > > Hmm, I see. I thought that there was some overlap. > > Well, in that case, the goals of native readline emulation > for Mac OS X Tiger and editline support for all platforms do > not overlap as much as I thought. Too bad. > > My point is that editline support for all platforms should > be a much higher priority than removing the dependence on > readline for one specific version of Mac OS X, in my > opinion. I think that in an effort to clarify matters, I made them more muddled. :-) By "they don't overlap" I meant that neither header (histedit.h vs. readline.h) imports the other and that they can be used independently. But *both* headers are present on *all* distributions of editline, not just Apple's. Implementing #2 is sufficient to getting editline working on all platforms. Sorry for the confusion, -Judah From gale at sefer.org Sun Jan 13 05:00:55 2008 From: gale at sefer.org (Yitzchak Gale) Date: Sun Jan 13 04:54:21 2008 Subject: Proposal: Add --with-libedit flag to the readline package In-Reply-To: <6d74b0d20801121640t79fc82g21d98a4b02338dca@mail.gmail.com> References: <6d74b0d20801091008m2ae7ff07h9dd2b33b0c83c6cd@mail.gmail.com> <20080111155603.GA29204@matrix.chaos.earth.li> <6d74b0d20801110914x73daf173u568b03342ee123d3@mail.gmail.com> <2608b8a80801120917v5d489bc3m21d345d0d85529b0@mail.gmail.com> <6d74b0d20801121304o16e417c4lc781939429ad3f75@mail.gmail.com> <2608b8a80801121444g131763cfwedb24578ca365d23@mail.gmail.com> <6d74b0d20801121640t79fc82g21d98a4b02338dca@mail.gmail.com> Message-ID: <2608b8a80801130200p4a2de76arac6ace52993b309f@mail.gmail.com> Hi Judah, Judah Jacobson wrote: > By "they don't overlap" I meant that neither header (histedit.h vs. > readline.h) imports the other and that they can be used independently. > But *both* headers are present on *all* distributions of editline, > not just Apple's. Implementing #2 is sufficient to getting editline > working on all platforms. OK, thanks, but it was me who was not clear. You understand far better than I do how things work at the C API level. I am just trying to point out, as an end user, some additional benefits that your proposed project would provide. And in fact, those benefits are so great that they would far overshadow - for me, at least, and perhaps for many others - the benefits that originally motivated the project. So perhaps you would want to take that into consideration when setting priorities, though in the end of course it's up to you. I think the most important issue is to enable using the Editline API in Haskell on all platforms. That would plug a major hole in the usefulness of Haskell as a language to anyone who is not fully committed to the GPL license. While providing partial Readline API emulation via editline would indeed be helpful in some situations, its value pales in comparison to the value of providing the Editline API, in my opinion. Anyway, great idea. Good luck with this. I am looking forward hearing more. Thanks, Yitz From isaacdupree at charter.net Sun Jan 13 06:47:50 2008 From: isaacdupree at charter.net (Isaac Dupree) Date: Sun Jan 13 06:41:14 2008 Subject: Proposal: Add --with-libedit flag to the readline package In-Reply-To: <6d74b0d20801121640t79fc82g21d98a4b02338dca@mail.gmail.com> References: <6d74b0d20801091008m2ae7ff07h9dd2b33b0c83c6cd@mail.gmail.com> <20080111155603.GA29204@matrix.chaos.earth.li> <6d74b0d20801110914x73daf173u568b03342ee123d3@mail.gmail.com> <2608b8a80801120917v5d489bc3m21d345d0d85529b0@mail.gmail.com> <6d74b0d20801121304o16e417c4lc781939429ad3f75@mail.gmail.com> <2608b8a80801121444g131763cfwedb24578ca365d23@mail.gmail.com> <6d74b0d20801121640t79fc82g21d98a4b02338dca@mail.gmail.com> Message-ID: <4789FA66.5070506@charter.net> Judah Jacobson wrote: > I think that in an effort to clarify matters, I made them more muddled. :-) > > By "they don't overlap" I meant that neither header (histedit.h vs. > readline.h) imports the other and that they can be used independently. > But *both* headers are present on *all* distributions of editline, > not just Apple's. Implementing #2 is sufficient to getting editline > working on all platforms. interesting... how do all platforms, even ones with Readline installed in a traditional Unix filesystem layout, manage to distribute Editline also with readline/readline.h? Shouldn't there be a non-overlapping header name that exports the same compatibility interface? ~Isaac From judah.jacobson at gmail.com Sun Jan 13 21:59:17 2008 From: judah.jacobson at gmail.com (Judah Jacobson) Date: Sun Jan 13 21:52:39 2008 Subject: Proposal: Add --with-libedit flag to the readline package In-Reply-To: <4789FA66.5070506@charter.net> References: <6d74b0d20801091008m2ae7ff07h9dd2b33b0c83c6cd@mail.gmail.com> <20080111155603.GA29204@matrix.chaos.earth.li> <6d74b0d20801110914x73daf173u568b03342ee123d3@mail.gmail.com> <2608b8a80801120917v5d489bc3m21d345d0d85529b0@mail.gmail.com> <6d74b0d20801121304o16e417c4lc781939429ad3f75@mail.gmail.com> <2608b8a80801121444g131763cfwedb24578ca365d23@mail.gmail.com> <6d74b0d20801121640t79fc82g21d98a4b02338dca@mail.gmail.com> <4789FA66.5070506@charter.net> Message-ID: <6d74b0d20801131859qa5cf8f3r7be5423efa18ea63@mail.gmail.com> On 1/13/08, Isaac Dupree wrote: > Judah Jacobson wrote: > > I think that in an effort to clarify matters, I made them more muddled. :-) > > > > By "they don't overlap" I meant that neither header (histedit.h vs. > > readline.h) imports the other and that they can be used independently. > > But *both* headers are present on *all* distributions of editline, > > not just Apple's. Implementing #2 is sufficient to getting editline > > working on all platforms. > > interesting... how do all platforms, even ones with Readline installed > in a traditional Unix filesystem layout, manage to distribute Editline > also with readline/readline.h? Shouldn't there be a non-overlapping > header name that exports the same compatibility interface? That's a good question; now that I think about it, I'm not sure of the answer. The header might be renamed, e.g. to ; I'll look into it. Hopefully, even if the header is renamed, the editline package will be able to abstract that away in its autoconf script. Thanks, -Judah From judah.jacobson at gmail.com Sun Jan 13 22:11:33 2008 From: judah.jacobson at gmail.com (Judah Jacobson) Date: Sun Jan 13 22:04:54 2008 Subject: Proposal: Add --with-libedit flag to the readline package In-Reply-To: <2608b8a80801130200p4a2de76arac6ace52993b309f@mail.gmail.com> References: <6d74b0d20801091008m2ae7ff07h9dd2b33b0c83c6cd@mail.gmail.com> <20080111155603.GA29204@matrix.chaos.earth.li> <6d74b0d20801110914x73daf173u568b03342ee123d3@mail.gmail.com> <2608b8a80801120917v5d489bc3m21d345d0d85529b0@mail.gmail.com> <6d74b0d20801121304o16e417c4lc781939429ad3f75@mail.gmail.com> <2608b8a80801121444g131763cfwedb24578ca365d23@mail.gmail.com> <6d74b0d20801121640t79fc82g21d98a4b02338dca@mail.gmail.com> <2608b8a80801130200p4a2de76arac6ace52993b309f@mail.gmail.com> Message-ID: <6d74b0d20801131911k65351c34v224c11eaca823b65@mail.gmail.com> On 1/13/08, Yitzchak Gale wrote: > > OK, thanks, but it was me who was not clear. > > You understand far better than I do how things > work at the C API level. I am just trying to point out, > as an end user, some additional benefits that your > proposed project would provide. And in fact, those > benefits are so great that they would far overshadow - > for me, at least, and perhaps for many others - the > benefits that originally motivated the project. So > perhaps you would want to take that into consideration > when setting priorities, though in the end of course > it's up to you. > > I think the most important issue is to enable using > the Editline API in Haskell on all platforms. That > would plug a major hole in the usefulness of Haskell > as a language to anyone who is not fully committed > to the GPL license. > > While providing partial Readline API emulation via > editline would indeed be helpful in some situations, > its value pales in comparison to the value of providing > the Editline API, in my opinion. > > Anyway, great idea. Good luck with this. I am > looking forward hearing more. > > Thanks, > Yitz > All right, I understand you now. It should be pretty straightforward to export the basics of the editline API, at least, if not the advanced features. I'll try to include that in the initial release of the package. Best wishes, -Judah From valery.vv at gmail.com Mon Jan 14 10:41:20 2008 From: valery.vv at gmail.com (Valery V. Vorotyntsev) Date: Mon Jan 14 10:34:53 2008 Subject: can't build plugins-1.0 with ghc-6.9 In-Reply-To: <20080107164652.GB16760@scytale.galois.com> References: <20080107164652.GB16760@scytale.galois.com> Message-ID: > > valery.vv: > > > > [...] > > > > My quest is to install lambdabot (for the sake of offline `@hoogle' > > and `@pl' commands), and the one depends on `plugins'. > > > > [...] > > > > 2) it doesn't build with Cabal-1.3.2 > > ------------------------------------ > > > > [...] On 1/7/08, Don Stewart wrote: > Please start with the hs-plugins repo on code.haskell.org, since it's > already updated for ghc 6.8, > > http://code.haskell.org/~dons/code/hs-plugins/ Hi, I managed to install hs-plugins with ghc-6.9.20080104 (see attached .dpatch). Now I have two lambdabots to choose from. 1) Lambdabot from hackage: [http://hackage.haskell.org/cgi-bin/hackage-scripts/package/lambdabot-4.0] $ sed -n -e 7,8p -e 12,13p /home/vvv/src/lambdabot-4.0/lambdabot.cabal Name: lambdabot Version: 4.0 Maintainer: dons@cse.unsw.edu.au Build-Depends: base, unix, network, parsec, mtl, haskell-src, haskell98, readline, plugins>=1.0, fps>=0.7 2) Lambdabot from darcs [http://code.haskell.org/lambdabot]: $ sed -n -e 7,8p -e 12,15p /home/vvv/hsources/lambdabot/lambdabot.cabal Name: lambdabot Version: 4.0 Maintainer: dons@cse.unsw.edu.au Build-Depends: base, unix, network, parsec, mtl, haskell-src, readline, QuickCheck, arrows, regex-compat, regex-posix, zlib, binary>=0.2, plugins>=1.0, oeis Though the first one has fewer dependencies, it seems to be obsolete[1]. I'm going to install the one from darcs... 1. `fps' is the old name of `bytestring', am I right? [http://www.cse.unsw.edu.au/~dons/fps.html] Don, it looks wrong to have several lambdabot.cabal files with different dependencies sharing the same version number. And the one at HackageDB has [possibly] obsolete `fps' dependency. Thanks. -- vvv -------------- next part -------------- New patches: [make plugins build with ghc-6.9 (darcs version) "Valery V. Vorotyntsev" **20080114143447 + PackageAPI.hs (updImportDirs): `InstalledPackageInfo_' is the proper name + Load.hs: `PackageConfig' does not export `packageIdString', `Module' does + PackageAPI.hs, Load.hs: cleaned of trailing whitespace ] { hunk ./src/System/Plugins/Load.hs 4 --- +-- hunk ./src/System/Plugins/Load.hs 9 --- +-- hunk ./src/System/Plugins/Load.hs 14 --- +-- hunk ./src/System/Plugins/Load.hs 19 --- +-- hunk ./src/System/Plugins/Load.hs 34 - , pdynload + , pdynload hunk ./src/System/Plugins/Load.hs 72 -import Module (moduleName, moduleNameString) -import PackageConfig (packageIdString) +import Module (moduleName, moduleNameString, packageIdString) hunk ./src/System/Plugins/Load.hs 131 --- +-- hunk ./src/System/Plugins/Load.hs 166 - return $ case v of + return $ case v of hunk ./src/System/Plugins/Load.hs 186 -dynload :: Typeable a - => FilePath +dynload :: Typeable a + => FilePath hunk ./src/System/Plugins/Load.hs 219 -pdynload object incpaths pkgconfs ty sym = do +pdynload object incpaths pkgconfs ty sym = do hunk ./src/System/Plugins/Load.hs 227 - if null errors + if null errors hunk ./src/System/Plugins/Load.hs 251 - if null errors + if null errors hunk ./src/System/Plugins/Load.hs 272 - let nm = mkModid (basename tmpf) + let nm = mkModid (basename tmpf) hunk ./src/System/Plugins/Load.hs 294 -mkTest modnm plugin api ty sym = +mkTest modnm plugin api ty sym = hunk ./src/System/Plugins/Load.hs 309 - if ty == ty' + if ty == ty' hunk ./src/System/Plugins/Load.hs 313 - where + where hunk ./src/System/Plugins/Load.hs 330 -dynload2 :: Typeable a => - FilePath -> - FilePath -> +dynload2 :: Typeable a => + FilePath -> + FilePath -> hunk ./src/System/Plugins/Load.hs 334 - Symbol -> + Symbol -> hunk ./src/System/Plugins/Load.hs 384 - + hunk ./src/System/Plugins/Load.hs 390 - return $ case v of + return $ case v of hunk ./src/System/Plugins/Load.hs 471 --- +-- hunk ./src/System/Plugins/Load.hs 488 -loadObject p ky@(Object k) = loadObject' p ky k -loadObject p ky@(Package k) = loadObject' p ky k +loadObject p ky@(Object k) = loadObject' p ky k +loadObject p ky@(Package k) = loadObject' p ky k hunk ./src/System/Plugins/Load.hs 495 - | otherwise + | otherwise hunk ./src/System/Plugins/Load.hs 538 -unloadObj :: Module -> IO () +unloadObj :: Module -> IO () hunk ./src/System/Plugins/Load.hs 542 - when (removed) $ do r <- c_unloadObj c_p + when (removed) $ do r <- c_unloadObj c_p hunk ./src/System/Plugins/Load.hs 557 - if maybe_errmsg == nullPtr + if maybe_errmsg == nullPtr hunk ./src/System/Plugins/Load.hs 603 - r <- c_unloadObj c_p + r <- c_unloadObj c_p hunk ./src/System/Plugins/Load.hs 605 - rmModule (mkModid p) -- unrecord this module + rmModule (mkModid p) -- unrecord this module hunk ./src/System/Plugins/Load.hs 622 - + hunk ./src/System/Plugins/Load.hs 662 - let mods_ = map (\s -> (s, map (\c -> + let mods_ = map (\s -> (s, map (\c -> hunk ./src/System/Plugins/Load.hs 666 - let mods = concatMap (\p -> + let mods = concatMap (\p -> hunk ./src/System/Plugins/Load.hs 691 - when (not (null ps')) $ putStrLn "done" - putStr "Loading object" + when (not (null ps')) $ putStrLn "done" + putStr "Loading object" hunk ./src/System/Plugins/PackageAPI.hs 3 --- +-- hunk ./src/System/Plugins/PackageAPI.hs 8 --- +-- hunk ./src/System/Plugins/PackageAPI.hs 13 --- +-- hunk ./src/System/Plugins/PackageAPI.hs 36 - , updLibraryDirs + , updLibraryDirs hunk ./src/System/Plugins/PackageAPI.hs 48 -packageName :: PackageConfig -> PackageName +packageName :: PackageConfig -> PackageName hunk ./src/System/Plugins/PackageAPI.hs 64 -updImportDirs f pk@(InstalledPackageInfo { importDirs = idirs }) = +updImportDirs f pk@(InstalledPackageInfo_ { importDirs = idirs }) = hunk ./src/System/Plugins/PackageAPI.hs 66 -updLibraryDirs f pk@(InstalledPackageInfo { libraryDirs = ldirs }) = +updLibraryDirs f pk@(InstalledPackageInfo_ { libraryDirs = ldirs }) = hunk ./src/System/Plugins/PackageAPI.hs 74 -updImportDirs f pk@(Package {import_dirs = idirs}) +updImportDirs f pk@(Package {import_dirs = idirs}) hunk ./src/System/Plugins/PackageAPI.hs 77 -updLibraryDirs f pk@(Package {library_dirs = ldirs}) +updLibraryDirs f pk@(Package {library_dirs = ldirs}) } Context: [Cabal >= 1.2.3 Don Stewart **20071220022555] [TAG plugins 1.1 Don Stewart **20071216071026] Patch bundle hash: 53eceb5ae4bf510dddf9573adc1db28f35669774 From twanvl at gmail.com Mon Jan 14 11:41:08 2008 From: twanvl at gmail.com (Twan van Laarhoven) Date: Mon Jan 14 11:34:21 2008 Subject: Proposal: Add concatMapM function (#2042) Message-ID: <478B90A4.4090807@gmail.com> Hello library people, I have noticed that many projects include a 'concatMapM' function: concatMapM :: (Monad m) => (a -> m [b]) -> [a] -> m [b] I think this is useful in general, so let's add it to Control.Monad. Trac ticket: http://hackage.haskell.org/trac/ghc/ticket/2042 Deadline for discussion: 2 weeks from now, January 28 Twan From isaacdupree at charter.net Mon Jan 14 13:00:08 2008 From: isaacdupree at charter.net (Isaac Dupree) Date: Mon Jan 14 12:53:25 2008 Subject: Proposal: Add concatMapM function (#2042) In-Reply-To: <478B90A4.4090807@gmail.com> References: <478B90A4.4090807@gmail.com> Message-ID: <478BA328.9020000@charter.net> Twan van Laarhoven wrote: > Hello library people, > > > I have noticed that many projects include a 'concatMapM' function: > > concatMapM :: (Monad m) => (a -> m [b]) -> [a] -> m [b] > > I think this is useful in general, so let's add it to Control.Monad. Me too. (therefore I think it should be added.) ~Isaac From dons at galois.com Mon Jan 14 13:06:10 2008 From: dons at galois.com (Don Stewart) Date: Mon Jan 14 12:59:43 2008 Subject: Proposal: Add concatMapM function (#2042) In-Reply-To: <478BA328.9020000@charter.net> References: <478B90A4.4090807@gmail.com> <478BA328.9020000@charter.net> Message-ID: <20080114180610.GH23179@scytale.galois.com> isaacdupree: > Twan van Laarhoven wrote: > >Hello library people, > > > > > >I have noticed that many projects include a 'concatMapM' function: > > > > concatMapM :: (Monad m) => (a -> m [b]) -> [a] -> m [b] > > > >I think this is useful in general, so let's add it to Control.Monad. > > Me too. (therefore I think it should be added.) > (+1) seems reasonable. From ndmitchell at gmail.com Mon Jan 14 13:57:59 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Mon Jan 14 13:51:18 2008 Subject: Proposal: Add concatMapM function (#2042) In-Reply-To: <20080114180610.GH23179@scytale.galois.com> References: <478B90A4.4090807@gmail.com> <478BA328.9020000@charter.net> <20080114180610.GH23179@scytale.galois.com> Message-ID: <404396ef0801141057n63667b6bi113da40511904e91@mail.gmail.com> > > > concatMapM :: (Monad m) => (a -> m [b]) -> [a] -> m [b] (+1) - an obvious missing function. Thanks Neil From bulat.ziganshin at gmail.com Mon Jan 14 14:25:39 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Mon Jan 14 14:42:50 2008 Subject: Proposal: Add concatMapM function (#2042) In-Reply-To: <478B90A4.4090807@gmail.com> References: <478B90A4.4090807@gmail.com> Message-ID: <1462557752.20080114222539@gmail.com> Hello Twan, Monday, January 14, 2008, 7:41:08 PM, you wrote: > I have noticed that many projects include a 'concatMapM' function: > concatMapM :: (Monad m) => (a -> m [b]) -> [a] -> m [b] > I think this is useful in general, so let's add it to Control.Monad. the one thing that you miss - each time you add popular function to the base library, all programs that include this function becomes incompatible with next GHC version. i wonder whether anyone here has the experience of writing large programs and maintaining them through the years? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From dons at galois.com Mon Jan 14 14:51:24 2008 From: dons at galois.com (Don Stewart) Date: Mon Jan 14 14:44:47 2008 Subject: Proposal: Add concatMapM function (#2042) In-Reply-To: <1462557752.20080114222539@gmail.com> References: <478B90A4.4090807@gmail.com> <1462557752.20080114222539@gmail.com> Message-ID: <20080114195124.GB24043@scytale.galois.com> bulat.ziganshin: > Hello Twan, > > Monday, January 14, 2008, 7:41:08 PM, you wrote: > > > I have noticed that many projects include a 'concatMapM' function: > > > concatMapM :: (Monad m) => (a -> m [b]) -> [a] -> m [b] > > > I think this is useful in general, so let's add it to Control.Monad. > > the one thing that you miss - each time you add popular function to > the base library, all programs that include this function > becomes incompatible with next GHC version. i wonder whether anyone > here has the experience of writing large programs and maintaining them > through the years? There has to be some path to migrate code into base. Do you have any examples of applications that will break, if this is added? -- Don From lemming at henning-thielemann.de Mon Jan 14 15:00:53 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon Jan 14 14:54:13 2008 Subject: Proposal: Add concatMapM function (#2042) In-Reply-To: <20080114195124.GB24043@scytale.galois.com> References: <478B90A4.4090807@gmail.com> <1462557752.20080114222539@gmail.com> <20080114195124.GB24043@scytale.galois.com> Message-ID: On Mon, 14 Jan 2008, Don Stewart wrote: > bulat.ziganshin: > > Hello Twan, > > > > Monday, January 14, 2008, 7:41:08 PM, you wrote: > > > > > I have noticed that many projects include a 'concatMapM' function: > > > > > concatMapM :: (Monad m) => (a -> m [b]) -> [a] -> m [b] > > > > > I think this is useful in general, so let's add it to Control.Monad. > > > > the one thing that you miss - each time you add popular function to > > the base library, all programs that include this function > > becomes incompatible with next GHC version. i wonder whether anyone > > here has the experience of writing large programs and maintaining them > > through the years? I had to adapt programs for every new release of GHC. Quite annoying. These were caused by new standard instances or removed packages. However I usually import Control.Monad either by import Control.Monad (func) or import qualified Control.Monad as Monad Both variants are safe with respect to additions to Control.Monad. (This is also the reason why these two types of imports are the only ones in the Modula languages. - On the other hand they have built-in control structures and types, so they don't need a Prelude for that.) From gale at sefer.org Mon Jan 14 16:00:15 2008 From: gale at sefer.org (Yitzchak Gale) Date: Mon Jan 14 15:53:34 2008 Subject: Proposal: Add concatMapM function (#2042) In-Reply-To: <1462557752.20080114222539@gmail.com> References: <478B90A4.4090807@gmail.com> <1462557752.20080114222539@gmail.com> Message-ID: <2608b8a80801141300i39a2d064yea9376cce5b9b7c8@mail.gmail.com> > the one thing that you miss - each time you add popular function to > the base library, all programs that include this function > becomes incompatible with next GHC version. i wonder whether anyone > here has the experience of writing large programs and maintaining them > through the years? I import only the functions I need from libraries that I don't own myself to minimize that effect. That said, feature creep is definitely a problem. I think the GHC team will be the first to agree. But this particular function really is a natural. One point to consider - perhaps nowadays the type ought to be: concatMapM :: (Monad m, Traversable t) => (a -> m (t b)) -> t a -> m (t b) Regards, Yitz From apfelmus at quantentunnel.de Mon Jan 14 17:42:49 2008 From: apfelmus at quantentunnel.de (apfelmus) Date: Mon Jan 14 17:36:18 2008 Subject: Proposal: Add concatMapM function (#2042) In-Reply-To: <2608b8a80801141300i39a2d064yea9376cce5b9b7c8@mail.gmail.com> References: <478B90A4.4090807@gmail.com> <1462557752.20080114222539@gmail.com> <2608b8a80801141300i39a2d064yea9376cce5b9b7c8@mail.gmail.com> Message-ID: Yitzchak Gale wrote: > One point to consider - perhaps nowadays the type ought to > be: > > concatMapM :: (Monad m, Traversable t) => (a -> m (t b)) -> t a -> m (t b) I don't think that works in such generality since that would imply join :: Traversable t => t (t c) -> t c join = runIdentity . concatMapM return (set a = t c and b = c ). Regards, apfelmus From judah.jacobson at gmail.com Mon Jan 14 17:48:17 2008 From: judah.jacobson at gmail.com (Judah Jacobson) Date: Mon Jan 14 17:41:35 2008 Subject: Copyright for readline/editline packages In-Reply-To: <6d74b0d20801121111y36ab53acu4e2c5d8ecfdeb0ab@mail.gmail.com> References: <20080112002000.YWCW22041.fep22.mail.dk@www.haskell.org> <200801121537.04851.naur@post11.tele.dk> <4788EBE0.3070308@charter.net> <6d74b0d20801121111y36ab53acu4e2c5d8ecfdeb0ab@mail.gmail.com> Message-ID: <6d74b0d20801141448o6c7d1dcav6ccd9bf9fd10da29@mail.gmail.com> On Jan 12, 2008 11:11 AM, Judah Jacobson wrote: > On 1/12/08, Isaac Dupree wrote: > > > > if the only copyright license granted for the Haskell-readline code is > > GPL (which sounds true), then it has to stay GPL. If BSD was also given > > as permission (it's always possible to give more permissions for the > > parts of something that you hold the copyright to), then, no worries, > > Haskell-editline can be BSD. > > > > [snip] > > > > Finding the author would be good if we could though, because she/he/they > > would most likely give us BSD permissions (just guessing :-) > > > > ~Isaac > > > > Thanks all, that's pretty much what I expected. I'll try to track > down the author and get BSD permissions from them. An update: I determined that three people (Marcin Kowalczyk, Simon Marlow and Isaac Jones) were significant contributers to that file. All three have given their blessing towards licensing that code under BSD3. I hope to have a preliminary version of the editline package uploaded to hackage sometime later this week. Best, -Judah From ross at soi.city.ac.uk Mon Jan 14 17:53:29 2008 From: ross at soi.city.ac.uk (Ross Paterson) Date: Mon Jan 14 17:46:57 2008 Subject: Proposal: Add concatMapM function (#2042) In-Reply-To: <2608b8a80801141300i39a2d064yea9376cce5b9b7c8@mail.gmail.com> References: <478B90A4.4090807@gmail.com> <1462557752.20080114222539@gmail.com> <2608b8a80801141300i39a2d064yea9376cce5b9b7c8@mail.gmail.com> Message-ID: <20080114225329.GA8193@soi.city.ac.uk> On Mon, Jan 14, 2008 at 11:00:15PM +0200, Yitzchak Gale wrote: > One point to consider - perhaps nowadays the type ought to be: > > concatMapM :: (Monad m, Traversable t) => (a -> m (t b)) -> t a -> m (t b) Perhaps (using mapM from Data.Traversable): foldMapM :: (Monad m, Traversable f, Monoid v) => (a -> m v) -> f a -> m v foldMapM f = liftM fold . mapM f (with an Applicative conterpart too) But is this too small, and too orthogonal a combination, for the library? From gale at sefer.org Mon Jan 14 21:54:52 2008 From: gale at sefer.org (Yitzchak Gale) Date: Mon Jan 14 21:48:10 2008 Subject: Proposal: Add concatMapM function (#2042) In-Reply-To: References: <478B90A4.4090807@gmail.com> <1462557752.20080114222539@gmail.com> <2608b8a80801141300i39a2d064yea9376cce5b9b7c8@mail.gmail.com> Message-ID: <2608b8a80801141854l642f6186scaf576070e5addf6@mail.gmail.com> I wrote: >> perhaps nowadays the type ought to be: >> concatMapM :: (Monad m, Traversable t) => (a -> m (t b)) -> t a -> m (t b) apfelmus wrote: > I don't think that works in such generality since that would imply > join :: Traversable t => t (t c) -> t c > join = runIdentity . concatMapM return Since return for the Identity monad is essential the identity, shouldn't we always have mapM return = return for that monad? In that case, your formula is indeed always true: runIdentity . concatMapM return = runIdentity . liftM join . mapM return = runIdentity . liftM join . return = runIdentity . return . join = join Regards, Yitz From apfelmus at quantentunnel.de Tue Jan 15 04:27:21 2008 From: apfelmus at quantentunnel.de (apfelmus) Date: Tue Jan 15 04:20:50 2008 Subject: Proposal: Add concatMapM function (#2042) In-Reply-To: <2608b8a80801141854l642f6186scaf576070e5addf6@mail.gmail.com> References: <478B90A4.4090807@gmail.com> <1462557752.20080114222539@gmail.com> <2608b8a80801141300i39a2d064yea9376cce5b9b7c8@mail.gmail.com> <2608b8a80801141854l642f6186scaf576070e5addf6@mail.gmail.com> Message-ID: Yitzchak Gale wrote: >>> perhaps nowadays the type ought to be: >>> concatMapM :: (Monad m, Traversable t) => (a -> m (t b)) -> t a -> m (t b) > > apfelmus wrote: >> I don't think that works in such generality since that would imply >> join :: Traversable t => t (t c) -> t c >> join = runIdentity . concatMapM return > > Since return for the Identity monad is essential the identity, > shouldn't we always have > > mapM return = return > > for that monad? Yes, since mapM f = sequence . map f for all monads and sequence = id :: [Identity a] -> Identity [a] for the identity monad. > In that case, your formula is indeed > always true: > > runIdentity . concatMapM return > = runIdentity . liftM join . mapM return > = runIdentity . liftM join . return > = runIdentity . return . join > = join Indeed, assuming that concatMapM f = liftM join . mapM f of course. What I wanted to say is that given the existence of a function concatMapM of the aforementioned type, you can construct a function of the type Traversable t => t (t a) -> t a which basically means (modulo laws) that every Traversable would have to be a monad. Since this is not always the case (really?), such a concatMapM that works for all Traversable t does not exist. Regards, apfelmus From gale at sefer.org Tue Jan 15 07:05:37 2008 From: gale at sefer.org (Yitzchak Gale) Date: Tue Jan 15 06:58:54 2008 Subject: Proposal: Add concatMapM function (#2042) In-Reply-To: References: <478B90A4.4090807@gmail.com> <1462557752.20080114222539@gmail.com> <2608b8a80801141300i39a2d064yea9376cce5b9b7c8@mail.gmail.com> <2608b8a80801141854l642f6186scaf576070e5addf6@mail.gmail.com> Message-ID: <2608b8a80801150405q44a95365uc6057dbee0085265@mail.gmail.com> I wrote: >>>> perhaps nowadays the type ought to be: >>>> concatMapM :: (Monad m, Traversable t) => (a -> m (t b)) -> t a -> m (t b) apfelmus wrote: >>> I don't think that works in such generality since that would imply... > that every Traversable would have to be a monad. Ah, of course. Sorry, I wrote that in the wee hours of the morning. Now I also understand Ross Patterson's answer - that a Monoid structure could also be substituted for the Monad structure, because concat generalizes both to join and to mappend. > Since this is not always the case (really?) Right. Given a tree of trees, there are many ways to paste them together into a single tree, but all of those ways use the actual tree structure, not just the fact that I can traverse over trees. You can't paste them together - but you can traverse them. So I guess the corresponding concept for traversables is that are composable over monads: mapMapM :: (Traversable t, Traversable t', Monad m) => (b -> m c) -> (a -> m (t b)) -> t' a -> m (t' (t c)) mapMapM f g = (>>= mapM (mapM f)) . mapM g I don't immediately see any composability over applicatives. Am I missing something obvious? Thanks, Yitz From bulat.ziganshin at gmail.com Tue Jan 15 03:10:23 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Tue Jan 15 07:21:18 2008 Subject: Proposal: Add concatMapM function (#2042) In-Reply-To: <2608b8a80801141300i39a2d064yea9376cce5b9b7c8@mail.gmail.com> References: <478B90A4.4090807@gmail.com> <1462557752.20080114222539@gmail.com> <2608b8a80801141300i39a2d064yea9376cce5b9b7c8@mail.gmail.com> Message-ID: <1451377359.20080115111023@gmail.com> Hello Yitzchak, Tuesday, January 15, 2008, 12:00:15 AM, you wrote: > I import only the functions I need from libraries that I don't > own myself to minimize that effect. i think that the better way will be to put all these functions into extralibs bundled with ghc. this will allow me to control which concrete version of lib i import and therefore which set of functions i've used. i don't like idea of editing my module imports each time i use new functions > That said, feature creep is definitely a problem. I think > the GHC team will be the first to agree. But this particular > function really is a natural. yes. `forever` function was also so natural that my program becomes incompatible with ghc 6.8. it's really annoying! -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From gale at sefer.org Tue Jan 15 09:17:54 2008 From: gale at sefer.org (Yitzchak Gale) Date: Tue Jan 15 09:11:14 2008 Subject: Proposal: Add concatMapM function (#2042) In-Reply-To: <1451377359.20080115111023@gmail.com> References: <478B90A4.4090807@gmail.com> <1462557752.20080114222539@gmail.com> <2608b8a80801141300i39a2d064yea9376cce5b9b7c8@mail.gmail.com> <1451377359.20080115111023@gmail.com> Message-ID: <2608b8a80801150617m57f2e412hbfd83ef149eed633@mail.gmail.com> Hi Bulat, I wrote: >> I import only the functions I need from libraries that I don't >> own myself to minimize that effect. Bulat Ziganshin wrote: > i think that the better way will be to put all these functions into > extralibs bundled with ghc. this will allow me to control which > concrete version of lib i import and therefore which set of functions > i've used. Yes. But you still need to put the new functions in the right place in the module hierarchy. How do we do that? For each module included in the bootlibs, would you have also Path.To.Module.Extra? That would be annoying. And it wouldn't even solve the problem: if you use Extra even once, you would go back to the same situation. Or maybe this: have two parallel streams of package versions in Cabal, with one from each installed at any given time. If you compile with -package foo_extra_1.2, that replaces all of the modules in foo_bootlib or foo_extra_. But now you always need to have all versions of every package installed on your system at any time -- no, *two versions* of all versions of every package. Yuck. There has to be some reasonable mechanism of adding new features to the libraries, even if we try very hard to be very disciplined and use it only rarely. > i don't like idea of editing my module imports each time i > use new functions It is a little more work. And there is the lint problem. But I find it's worth it. Sometimes I'm lazy and just do import Library.Module without an import list. I'm almost always sorry later on. Regards, Yitz From ndmitchell at gmail.com Tue Jan 15 09:47:37 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Tue Jan 15 09:40:54 2008 Subject: Proposal: Add concatMapM function (#2042) In-Reply-To: <2608b8a80801150617m57f2e412hbfd83ef149eed633@mail.gmail.com> References: <478B90A4.4090807@gmail.com> <1462557752.20080114222539@gmail.com> <2608b8a80801141300i39a2d064yea9376cce5b9b7c8@mail.gmail.com> <1451377359.20080115111023@gmail.com> <2608b8a80801150617m57f2e412hbfd83ef149eed633@mail.gmail.com> Message-ID: <404396ef0801150647h364ad7e2i44da5c645d679516@mail.gmail.com> Hi > Yes. But you still need to put the new functions in the > right place in the module hierarchy. How do we do that? You create a package extras. You do import Control.Monad.Extras in your package, rather than import Control.Monad. The extra's package wraps up all the CPP magic required to keep track of the additions to the base libraries, so you end up using concatMapM from Control.Monad if it is in your libraries, you use one from extras if its not. Creating this package extras isn't a massive amount of work, and would completely solve this problem. Personally, I don't care enough to actually write such a package, but if it existed I might use it. > > i don't like idea of editing my module imports each time i > > use new functions > > It is a little more work. And there is the lint problem. > But I find it's worth it. > > Sometimes I'm lazy and just do import Library.Module > without an import list. I'm almost always sorry > later on. I never list functions I'm importing by name. If I ever am sorry later on, its usually for a few fractions of a millisecond at compile time (the advantage of using Hugs ;) ). Typically it can be fixed typically by deleting code, while always makes me smile. Thanks Neil From lemming at henning-thielemann.de Tue Jan 15 09:52:51 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Tue Jan 15 09:46:09 2008 Subject: Proposal: Add concatMapM function (#2042) In-Reply-To: <2608b8a80801150617m57f2e412hbfd83ef149eed633@mail.gmail.com> References: <478B90A4.4090807@gmail.com> <1462557752.20080114222539@gmail.com> <2608b8a80801141300i39a2d064yea9376cce5b9b7c8@mail.gmail.com> <1451377359.20080115111023@gmail.com> <2608b8a80801150617m57f2e412hbfd83ef149eed633@mail.gmail.com> Message-ID: On Tue, 15 Jan 2008, Yitzchak Gale wrote: > Hi Bulat, > > I wrote: > >> I import only the functions I need from libraries that I don't > >> own myself to minimize that effect. > > Bulat Ziganshin wrote: > > i think that the better way will be to put all these functions into > > extralibs bundled with ghc. this will allow me to control which > > concrete version of lib i import and therefore which set of functions > > i've used. > > Yes. But you still need to put the new functions in the > right place in the module hierarchy. How do we do that? > > For each module included in the bootlibs, would > you have also Path.To.Module.Extra? That would > be annoying. And it wouldn't even solve the problem: > if you use Extra even once, you would go back > to the same situation. I collected some points at http://www.haskell.org/haskellwiki/Import_modules_properly From lemming at henning-thielemann.de Tue Jan 15 10:01:02 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Tue Jan 15 09:55:07 2008 Subject: Proposal: Add concatMapM function (#2042) In-Reply-To: <404396ef0801150647h364ad7e2i44da5c645d679516@mail.gmail.com> References: <478B90A4.4090807@gmail.com> <1462557752.20080114222539@gmail.com> <2608b8a80801141300i39a2d064yea9376cce5b9b7c8@mail.gmail.com> <1451377359.20080115111023@gmail.com> <2608b8a80801150617m57f2e412hbfd83ef149eed633@mail.gmail.com> <404396ef0801150647h364ad7e2i44da5c645d679516@mail.gmail.com> Message-ID: On Tue, 15 Jan 2008, Neil Mitchell wrote: > > Yes. But you still need to put the new functions in the > > right place in the module hierarchy. How do we do that? > > You create a package extras. You do import Control.Monad.Extras in > your package, rather than import Control.Monad. The extra's package > wraps up all the CPP magic required to keep track of the additions to > the base libraries, so you end up using concatMapM from Control.Monad > if it is in your libraries, you use one from extras if its not. I don't like fixing bad style (import anonymously and unqualified) by even more bad style (CPP). The problem can nicely be solved by letting GHC emit warnings if you don't import carefully, and allow lazy importing style in Haskell Prime only as language extension. :-) From conor at strictlypositive.org Tue Jan 15 15:31:48 2008 From: conor at strictlypositive.org (Conor McBride) Date: Tue Jan 15 15:24:56 2008 Subject: Proposal: Add concatMapM function (#2042) In-Reply-To: <20080114225329.GA8193@soi.city.ac.uk> References: <478B90A4.4090807@gmail.com> <1462557752.20080114222539@gmail.com> <2608b8a80801141300i39a2d064yea9376cce5b9b7c8@mail.gmail.com> <20080114225329.GA8193@soi.city.ac.uk> Message-ID: Hi folks I think Ross has boiled it down pretty well... On 14 Jan 2008, at 22:53, Ross Paterson wrote: > Perhaps (using mapM from Data.Traversable): > > foldMapM :: (Monad m, Traversable f, Monoid v) => (a -> m v) -> f a > -> m v > foldMapM f = liftM fold . mapM f > > (with an Applicative conterpart too) (As with many numerous episodes, I guess the need for monadic versions of applicative operations is something we have to live with for the moment. There is nothing essentially monadic going on here.) ...but you can go a little further. concatMapM, foldMapM, etc, are just newtype isotopes of foldMap. Here's what I'd do: it's perhaps not 98y enough (MPTCs, fundeps) for all but a far-flung corner of the library. What do you think? Step 1. Introduce a general utility to support the newtype-adds-structure pattern > class Unpack p u | p -> u where > unpack :: p -> u and when you create a newtype, instantiate Unpack. For example > newtype AMonoid a x = AMonoid {aMonoid :: a x} > instance Unpack (AMonoid a x) (a x) where > unpack = aMonoid I don't like having to remember a zillion unpacking functions. If you want to be more explicit, eg, to push types in, add > un :: Unpack p u => (u -> p) -> p -> u > un _ = unpack so (un AMonoid) is another name for aMonoid. Step 2. Implement this crunchy little third-order gadget. > ala :: Unpack p' u' => > (u -> p) -> > ((a -> p) -> a' -> p') -> > (a -> u) -> a' -> u' > ala pack hitWith hammer = > unpack . hitWith (pack . hammer) The idea is that (ala pack hitWith) invokes the map-like operator hitWith, but exploiting the extra structure identified by the packer, typically a newtype constructor. These two greatly increase the value of higher-order operations like traverse, and correspondingly reduce the need to extend one's library with special cases of them. Without the Unpack MPTC, you could at least add > modulo :: (u -> p) -> (p' -> u') -> > ((a -> p) -> a' -> p') -> > (a -> u) -> a' -> u' > modulo fancy plain hitWith hammer = > plain . hitWith (fancy . hammer) which may be worth having a standard name for. Step 3. Expose the structure you need. Here, it's applicative lifting of monoids (you can add your own monadic version). > instance (Applicative a, Monoid x) => > Monoid (AMonoid a x) where > mempty = AMonoid (pure mempty) > mappend (AMonoid x) (AMonoid y) = > AMonoid (pure mappend <*> x <*> y) This is a generally useful way to be specific about a very common kind of derived monoid structure. And now we're home! > parpSplat :: > (Applicative parp, Foldable f, Monoid splat) => > (x -> parp splat) -> f x -> parp splat > parpSplat = ala AMonoid foldMap > -- modulo AMonoid aMonoid foldMap Haskell's classes are the best damn rhythm section in the industry: you hum it, they play it. > > But is this too small, and too orthogonal a combination, for the > library? IMHO, yes. All the best Conor From igloo at earth.li Tue Jan 15 22:04:03 2008 From: igloo at earth.li (Ian Lynagh) Date: Tue Jan 15 21:57:19 2008 Subject: darcs patch: Data.List.sort: force elements from start to end. In-Reply-To: <1195640991.11655@zombie> References: <1195640991.11655@zombie> Message-ID: <20080116030403.GA4097@matrix.chaos.earth.li> On Wed, Nov 21, 2007 at 11:29:51AM +0100, Bertram Felgenhauer wrote: > > Wed Nov 21 11:14:58 CET 2007 Bertram Felgenhauer > * Data.List.sort: force elements from start to end. > this prevents a stack overflow on sort (take 10^6 [1..]) Applied, thanks! Sorry for the delay. Thanks Ian From ross at soi.city.ac.uk Wed Jan 16 05:29:53 2008 From: ross at soi.city.ac.uk (Ross Paterson) Date: Wed Jan 16 05:23:10 2008 Subject: Proposal: Add concatMapM function (#2042) In-Reply-To: References: <478B90A4.4090807@gmail.com> <1462557752.20080114222539@gmail.com> <2608b8a80801141300i39a2d064yea9376cce5b9b7c8@mail.gmail.com> <20080114225329.GA8193@soi.city.ac.uk> Message-ID: <20080116102953.GA3642@soi.city.ac.uk> On Tue, Jan 15, 2008 at 08:31:48PM +0000, Conor McBride wrote: > And now we're home! > > > parpSplat :: > > (Applicative parp, Foldable f, Monoid splat) => > > (x -> parp splat) -> f x -> parp splat > > parpSplat = ala AMonoid foldMap > > -- modulo AMonoid aMonoid foldMap Unfolding these definitions, a shorter (but less scenic) route to this particular destination is: foldMapM :: (Monad m, Foldable t, Monoid v) => (a -> m v) -> t a -> m v foldMapM f = Data.Foldable.foldr mappend_f (return mempty) where mappend_f x y = liftM2 mappend (f x) y foldMapA :: (Applicative f, Foldable t, Monoid v) => (a -> f v) -> t a -> f v foldMapA f = Data.Foldable.foldr mappend_f (pure mempty) where mappend_f x y = mappend <$> f x <*> y From judah.jacobson at gmail.com Wed Jan 16 16:05:12 2008 From: judah.jacobson at gmail.com (Judah Jacobson) Date: Wed Jan 16 15:58:40 2008 Subject: Integrating editline with ghc Message-ID: <6d74b0d20801161305na9e0732m2a6bae7098ec531d@mail.gmail.com> Hi all, I have managed to build ghc using the initial release of the editline package: Hackage link: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/editline-0.1 Haddock: http://code.haskell.org/editline/dist/doc/html/editline/ As I've mentioned before, there are two independent modules: - System.Console.Editline is a very basic (and experimental) interface to the native editline APIs. - System.Console.Editline.Readline contains the readline APIs provided by the editline library (mostly a cut/paste of System.Console.Readline). Currently I'm using just the latter as a drop-in replacement for System.Console.Readline in ghci. I have added a --with-editline flag to ghc's configure script, which has no effect if it's not specified, and otherwise does the following: - Throw an error (at configure time) if editline isn't present (as $hardtop/libraries/editline) - Use the editline package instead of readline when building ghc stage 2 - Use CPP to make InteractiveUI.hs (the main ghci loop) import System.Console.Editline.Readline instead of System.Console.Readline. Does that sound like the right way to handle this? If so, I'll send a darcs patch. Also, should editline be made a boot-package or an extra-package (or neither)? Thanks, -Judah From isaacdupree at charter.net Wed Jan 16 17:57:41 2008 From: isaacdupree at charter.net (Isaac Dupree) Date: Wed Jan 16 17:50:56 2008 Subject: darcs patch: bugfix: allow multi-word token-type usin... (and 2 more) Message-ID: <478E8BE5.2000509@charter.net> Proposal: put Happy and Alex discussion/patches/etc under the libraries@haskell.org domain, even though they're not technically libraries. (their purpose is very similar to Parsec's, for example, which is a library; and GHC depends on them, though from the end-user's point of view it's not quite as strong a dependency as the boot-libs) This patch is bugfixes for Happy that I discovered when trying to make GHC's code more portable (so I was testing using happy without -agc for the first time) (I sent this first to cvs-ghc@haskell.org but I figured I should really ask the community anyway). (I have a more controversial topic/patch to propose for Alex and Happy later...) ~Isaac Thu Dec 27 07:57:38 EST 2007 Isaac Dupree * bugfix: allow multi-word token-type using parentheses everywhere needed Thu Dec 27 11:54:46 EST 2007 Isaac Dupree * refactor HappyReduction-generating code (no semantic change) Thu Dec 27 12:04:54 EST 2007 Isaac Dupree * self-expand HappyReduction for more Haskell98 compliance It's not too bad at all since it's only duplicated in two places. Happy without -agc is most likely to be used by the compilers other than GHC anyway. Should I really put those comments into the output file, or is it better just to remove the references to the old type-synonym? -------------- next part -------------- To: cvs-ghc@haskell.org From: Isaac Dupree Subject: darcs patch: bugfix: allow multi-word token-type usin... (and 2 more) X-Mail-Originator: Darcs Version Control System X-Darcs-Version: 1.0.9 (release) DarcsURL: http://darcs.haskell.org/happy MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=_" --=_ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Thu Dec 27 07:57:38 EST 2007 Isaac Dupree * bugfix: allow multi-word token-type using parentheses everywhere needed Thu Dec 27 11:54:46 EST 2007 Isaac Dupree * refactor HappyReduction-generating code (no semantic change) Thu Dec 27 12:04:54 EST 2007 Isaac Dupree * self-expand HappyReduction for more Haskell98 compliance It's not too bad at all since it's only duplicated in two places. Happy without -agc is most likely to be used by the compilers other than GHC anyway. Should I really put those comments into the output file, or is it better just to remove the references to the old type-synonym? --=_ Content-Type: text/x-darcs-patch; name="bugfix_-allow-multi_word-token_type-using-parentheses-everywhere-needed.dpatch" Content-Transfer-Encoding: quoted-printable Content-Description: A darcs patch for your repository! New patches: [bugfix: allow multi-word token-type using parentheses everywhere needed Isaac Dupree **20071227125738] { hunk ./src/ProduceCode.lhs 85 +> token =3D brack token_type hunk ./src/ProduceCode.lhs 148 -> . str "happyInTok :: " . str token_type . str " -> " . bhappy_item +> . str "happyInTok :: " . token . str " -> " . bhappy_item hunk ./src/ProduceCode.lhs 151 -> . str "happyOutTok :: " . bhappy_item . str " -> " . str token_type +> . str "happyOutTok :: " . bhappy_item . str " -> " . token hunk ./src/ProduceCode.lhs 177 -> . str "\n\t=3D HappyTerminal " . str token_type +> . str "\n\t=3D HappyTerminal " . token hunk ./src/ProduceCode.lhs 232 -> token =3D brack token_type hunk ./src/ProduceCode.lhs 707 -> . str token_type +> . token hunk ./src/ProduceCode.lhs 720 -> . str token_type . str " -> " = +> . token . str " -> " = } [refactor HappyReduction-generating code (no semantic change) Isaac Dupree **20071227165446] { hunk ./src/ProduceCode.lhs 201 -> str "type HappyReduction m =3D \n\t" -> . str " " -> . intMaybeHash -> . str " \n\t-> " . token -> . str "\n\t-> HappyState " -> . token -> . str " (HappyStk HappyAbsSyn -> " . tokens . result -> . str ")\n\t" -> . str "-> [HappyState " -> . token -> . str " (HappyStk HappyAbsSyn -> " . tokens . result -> . str ")] \n\t-> HappyStk HappyAbsSyn \n\t-> " -> . tokens -> . result -> . str "\n\n" +> happyReductionDefinition . str "\n\n" hunk ./src/ProduceCode.lhs 206 -> . intMaybeHash -> . str " -> HappyReduction (" . str monad_tycon . str ")\n\n" +> . intMaybeHash . str " -> " . happyReductionValue . str "\n\n" hunk ./src/ProduceCode.lhs 211 -> . str " :: " . str monad_context . str " =3D> HappyReduction (" . st= r monad_tycon . str ")\n\n" = +> . str " :: " . str monad_context . str " =3D> " +> . happyReductionValue . str "\n\n" hunk ./src/ProduceCode.lhs 222 -> result =3D (str "m HappyAbsSyn") +> happyReductionDefinition =3D +> str "type HappyReduction m =3D " +> . happyReduction (str "m") +> happyReductionValue =3D +> str "HappyReduction " +> . brack monad_tycon +> happyReduction m =3D +> str "\n\t " +> . intMaybeHash +> . str " \n\t-> " . token +> . str "\n\t-> HappyState " +> . token +> . str " (HappyStk HappyAbsSyn -> " . tokens . result +> . str ")\n\t" +> . str "-> [HappyState " +> . token +> . str " (HappyStk HappyAbsSyn -> " . tokens . result +> . str ")] \n\t-> HappyStk HappyAbsSyn \n\t-> " +> . tokens +> . result +> where result =3D m . str " HappyAbsSyn" } [self-expand HappyReduction for more Haskell98 compliance Isaac Dupree **20071227170454 It's not too bad at all since it's only duplicated in two places. Happy without -agc is most likely to be used by the compilers other than GHC anyway. Should I really put those comments into the output file, or is it better just to remove the references to the old type-synonym? ] { hunk ./src/ProduceCode.lhs 223 -> str "type HappyReduction m =3D " +> str "{- to allow type-synonyms as our monads (likely\n" +> . str " - with explicitly-specified bind and return)\n" +> . str " - in Haskell98, it seems that with\n" +> . str " - /type M a =3D .../, then /(HappyReduction M)/\n" +> . str " - is not allowed. But Happy is a\n" +> . str " - code-generator that can just substitute it.\n" +> . str "type HappyReduction m =3D " hunk ./src/ProduceCode.lhs 231 +> . str "\n-}" hunk ./src/ProduceCode.lhs 233 -> str "HappyReduction " +> str "({-" +> . str "HappyReduction " hunk ./src/ProduceCode.lhs 236 +> . str " =3D -}" +> . happyReduction (brack monad_tycon) +> . str ")" } Context: [update following recent Cabal changes Simon Marlow **20071026150947] = [TAG 1.17 RELEASE Simon Marlow **20071023145501] = Patch bundle hash: 7b85a9d0b16a315f2996831afcf214299b4bd4cb --=_-- . From twanvl at gmail.com Wed Jan 16 18:00:37 2008 From: twanvl at gmail.com (Twan van Laarhoven) Date: Wed Jan 16 17:53:50 2008 Subject: Proposal: Add split and splitWith (trac #2048) Message-ID: <478E8C95.7020500@gmail.com> Hello Haskellers, An often requested function is 'split', to split a list into parts delimited by some separator. ByteString has the functions split and splitWith for this purpose. I propose we add equivalents to Data.List: > split :: Eq a => a -> [a] -> [[a]] > split x = splitWith (x==) > > splitWith :: (a -> Bool) -> [a] -> [[a]] > splitWith p xs = ys : case zs of > [] -> [] > _:ws -> splitWith p ws > where (ys,zs) = break p xs trac: http://hackage.haskell.org/trac/ghc/ticket/2048 deadline: two weeks from now, January 30 Twan From ndmitchell at gmail.com Wed Jan 16 18:29:51 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Wed Jan 16 18:23:02 2008 Subject: Proposal: Add split and splitWith (trac #2048) In-Reply-To: <478E8C95.7020500@gmail.com> References: <478E8C95.7020500@gmail.com> Message-ID: <404396ef0801161529q2ec35f7ehd7bbd850b9427e5e@mail.gmail.com> Hi > An often requested function is 'split', to split a list into parts delimited by > some separator. ByteString has the functions split and splitWith for this > purpose. I propose we add equivalents to Data.List: > > > split :: Eq a => a -> [a] -> [[a]] > > split x = splitWith (x==) > > > > splitWith :: (a -> Bool) -> [a] -> [[a]] > > splitWith p xs = ys : case zs of > > [] -> [] > > _:ws -> splitWith p ws > > where (ys,zs) = break p xs > > trac: http://hackage.haskell.org/trac/ghc/ticket/2048 > deadline: two weeks from now, January 30 (+10) Agreement. This is long overdue! Thanks Neil From dons at galois.com Wed Jan 16 18:32:46 2008 From: dons at galois.com (Don Stewart) Date: Wed Jan 16 18:26:05 2008 Subject: Proposal: Add split and splitWith (trac #2048) In-Reply-To: <404396ef0801161529q2ec35f7ehd7bbd850b9427e5e@mail.gmail.com> References: <478E8C95.7020500@gmail.com> <404396ef0801161529q2ec35f7ehd7bbd850b9427e5e@mail.gmail.com> Message-ID: <20080116233246.GJ4629@scytale.galois.com> ndmitchell: > Hi > > > An often requested function is 'split', to split a list into parts delimited by > > some separator. ByteString has the functions split and splitWith for this > > purpose. I propose we add equivalents to Data.List: > > > > > split :: Eq a => a -> [a] -> [[a]] > > > split x = splitWith (x==) > > > > > > splitWith :: (a -> Bool) -> [a] -> [[a]] > > > splitWith p xs = ys : case zs of > > > [] -> [] > > > _:ws -> splitWith p ws > > > where (ys,zs) = break p xs > > > > trac: http://hackage.haskell.org/trac/ghc/ticket/2048 > > deadline: two weeks from now, January 30 > > (+10) Agreement. This is long overdue! I'd like some QuickCheck properties, so we can avoid the unlines . lines /= id fiasco. Given that, I'd support this too. -- Don From twanvl at gmail.com Wed Jan 16 18:50:39 2008 From: twanvl at gmail.com (Twan van Laarhoven) Date: Wed Jan 16 18:43:50 2008 Subject: Proposal: Add split and splitWith (trac #2048) In-Reply-To: <20080116233246.GJ4629@scytale.galois.com> References: <478E8C95.7020500@gmail.com> <404396ef0801161529q2ec35f7ehd7bbd850b9427e5e@mail.gmail.com> <20080116233246.GJ4629@scytale.galois.com> Message-ID: <478E984F.2030609@gmail.com> Don Stewart wrote: > I'd like some QuickCheck properties, so we can avoid the unlines . lines /= id > fiasco. Given that, I'd support this too. What is a good place to put those? I just ran some obvious tests from ghci: > test (\x y -> intercalate [x::Int] (split x y) == y) ] OK, passed 100 tests. > test (\p xs -> all (not . any p) (splitWith p xs :: [[Int]])) ] OK, passed 100 tests. for the unbeliever: > test (\x y -> splitWith (==x) y == split (x::Int) y) ] OK, passed 100 tests. to show lazyness: > split 'a' $ concat $ repeat "abcdefgh" ] ["","bcdefgh","bcdefgh","bcdefgh",... > split 'z' $ concat $ repeat "abcdefgh" ] ["abcdefghabcdefghabcdefghabcdefgh... Fiasco avoided :) Twan From igloo at earth.li Wed Jan 16 19:00:25 2008 From: igloo at earth.li (Ian Lynagh) Date: Wed Jan 16 18:53:38 2008 Subject: Proposal: Add split and splitWith (trac #2048) In-Reply-To: <478E8C95.7020500@gmail.com> References: <478E8C95.7020500@gmail.com> Message-ID: <20080117000025.GA27886@matrix.chaos.earth.li> Hi Twan, On Thu, Jan 17, 2008 at 12:00:37AM +0100, Twan van Laarhoven wrote: > > An often requested function is 'split', to split a list into parts > delimited by some separator. ByteString has the functions split and > splitWith for this purpose. I propose we add equivalents to Data.List: > > > split :: Eq a => a -> [a] -> [[a]] > > split x = splitWith (x==) > > > > splitWith :: (a -> Bool) -> [a] -> [[a]] > > splitWith p xs = ys : case zs of > > [] -> [] > > _:ws -> splitWith p ws > > where (ys,zs) = break p xs One or the other should be changed so that these agree: *Main> split 'a' "" [""] *Main> Data.ByteString.Char8.split 'a' (Data.ByteString.Char8.pack "") Loading package array-0.1.0.0 ... linking ... done. Loading package bytestring-0.9.0.1 ... linking ... done. [] although I couldn't say which is "right" OTTOMH... Thanks Ian From twanvl at gmail.com Wed Jan 16 19:10:36 2008 From: twanvl at gmail.com (Twan van Laarhoven) Date: Wed Jan 16 19:03:48 2008 Subject: Proposal: Add split and splitWith (trac #2048) In-Reply-To: <20080117000025.GA27886@matrix.chaos.earth.li> References: <478E8C95.7020500@gmail.com> <20080117000025.GA27886@matrix.chaos.earth.li> Message-ID: <478E9CFC.5080607@gmail.com> Ian Lynagh wrote: > One or the other should be changed so that these agree: > > *Main> split 'a' "" > [""] > *Main> Data.ByteString.Char8.split 'a' (Data.ByteString.Char8.pack "") > Loading package array-0.1.0.0 ... linking ... done. > Loading package bytestring-0.9.0.1 ... linking ... done. > [] > > although I couldn't say which is "right" OTTOMH... I hadn't noticed. In my opinion the Data.List version is more consistent, > split 'a' "xx" == ["xx"] > split 'a' "x" == ["x"] > split 'a' "" == [""] and > split 'a' "aa" == ["","",""] > split 'a' "a" == ["",""] > split 'a' "" == [""] Versus: > B.split 'a' "xx" == ["xx"] > B.split 'a' "x" == ["x"] > B.split 'a' "" == [] > B.split 'a' "aa" == ["","",""] > B.split 'a' "a" == ["",""] > B.split 'a' "" == [] Twan From ndmitchell at gmail.com Wed Jan 16 19:32:24 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Wed Jan 16 19:25:35 2008 Subject: Proposal: Add split and splitWith (trac #2048) In-Reply-To: <478E9CFC.5080607@gmail.com> References: <478E8C95.7020500@gmail.com> <20080117000025.GA27886@matrix.chaos.earth.li> <478E9CFC.5080607@gmail.com> Message-ID: <404396ef0801161632s6d54164aw494df189f6549b0d@mail.gmail.com> Hi > > One or the other should be changed so that these agree: > > > > *Main> split 'a' "" > > [""] > > *Main> Data.ByteString.Char8.split 'a' (Data.ByteString.Char8.pack "") > > Loading package array-0.1.0.0 ... linking ... done. > > Loading package bytestring-0.9.0.1 ... linking ... done. > > [] > > > > although I couldn't say which is "right" OTTOMH... > > I hadn't noticed. In my opinion the Data.List version is more consistent, You can show you can build it up from an inductive argument, yes. But the Data.ByteString version probably matches what I'd expect to happen much more - just a gut feeling. Thanks Neil From dons at galois.com Wed Jan 16 19:37:55 2008 From: dons at galois.com (Don Stewart) Date: Wed Jan 16 19:31:21 2008 Subject: Proposal: Add split and splitWith (trac #2048) In-Reply-To: <404396ef0801161632s6d54164aw494df189f6549b0d@mail.gmail.com> References: <478E8C95.7020500@gmail.com> <20080117000025.GA27886@matrix.chaos.earth.li> <478E9CFC.5080607@gmail.com> <404396ef0801161632s6d54164aw494df189f6549b0d@mail.gmail.com> Message-ID: <20080117003755.GM4629@scytale.galois.com> ndmitchell: > Hi > > > > One or the other should be changed so that these agree: > > > > > > *Main> split 'a' "" > > > [""] > > > *Main> Data.ByteString.Char8.split 'a' (Data.ByteString.Char8.pack "") > > > Loading package array-0.1.0.0 ... linking ... done. > > > Loading package bytestring-0.9.0.1 ... linking ... done. > > > [] > > > > > > although I couldn't say which is "right" OTTOMH... > > > > I hadn't noticed. In my opinion the Data.List version is more consistent, > > You can show you can build it up from an inductive argument, yes. But > the Data.ByteString version probably matches what I'd expect to happen > much more - just a gut feeling. > It's been a long time since I looked at bytestring's split, and it was never meant to be the last word on how to do this. Here are some of the properties it has, prop_splitsplitWith c xs = split c xs == splitWith (== c) xs prop_joinsplit c xs = intercalate [c] (split c xs) == xs Note here the funniness of lines, complicates the properties: prop_linessplit xs = lines xs == split '\n' xs ++ (if last xs == '\n' then [empty] else []) What properties relating to current List functoins does this split have? (I don't want to block the inclusion, just want to get a sense of how it fits into the existing code). -- Don From chak at cse.unsw.edu.au Wed Jan 16 23:54:51 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Wed Jan 16 23:48:06 2008 Subject: Integrating editline with ghc In-Reply-To: <6d74b0d20801161305na9e0732m2a6bae7098ec531d@mail.gmail.com> References: <6d74b0d20801161305na9e0732m2a6bae7098ec531d@mail.gmail.com> Message-ID: Judah Jacobson: > Hackage link: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/editline-0.1 > Haddock: http://code.haskell.org/editline/dist/doc/html/editline/ > > As I've mentioned before, there are two independent modules: > - System.Console.Editline is a very basic (and experimental) interface > to the native editline APIs. > - System.Console.Editline.Readline contains the readline APIs provided > by the editline library (mostly a cut/paste of > System.Console.Readline). > > Currently I'm using just the latter as a drop-in replacement for > System.Console.Readline in ghci. I have added a --with-editline flag > to ghc's configure script, which has no effect if it's not specified, > and otherwise does the following: > > - Throw an error (at configure time) if editline isn't present (as > $hardtop/libraries/editline) > - Use the editline package instead of readline when building ghc > stage 2 > - Use CPP to make InteractiveUI.hs (the main ghci loop) import > System.Console.Editline.Readline instead of System.Console.Readline. > > Does that sound like the right way to handle this? If so, I'll send a > darcs patch. Sounds good to me. > Also, should editline be made a boot-package or an extra-package (or > neither)? Given that we like this to be the default on some platforms, I believe it belongs into boot-packages (just like readline). Manuel From naur at post11.tele.dk Thu Jan 17 00:03:12 2008 From: naur at post11.tele.dk (Thorkil Naur) Date: Wed Jan 16 23:57:37 2008 Subject: Integrating editline with ghc In-Reply-To: <20080116210542.FMQB5833.fep27.mail.dk@www.haskell.org> References: <20080116210542.FMQB5833.fep27.mail.dk@www.haskell.org> Message-ID: <200801170603.13317.naur@post11.tele.dk> Hello, On Wednesday 16 January 2008 22:05, Judah Jacobson wrote: > Hi all, > > I have managed to build ghc using the initial release of the editline package: > > Hackage link: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/editline-0.1 > Haddock: http://code.haskell.org/editline/dist/doc/html/editline/ > > As I've mentioned before, there are two independent modules: > - System.Console.Editline is a very basic (and experimental) interface > to the native editline APIs. > - System.Console.Editline.Readline contains the readline APIs provided > by the editline library (mostly a cut/paste of > System.Console.Readline). Excellent! > > Currently I'm using just the latter as a drop-in replacement for > System.Console.Readline in ghci. I have added a --with-editline flag > to ghc's configure script, which has no effect if it's not specified, > and otherwise does the following: > > - Throw an error (at configure time) if editline isn't present (as > $hardtop/libraries/editline) That's the way. > - Use the editline package instead of readline when building ghc stage 2 > - Use CPP to make InteractiveUI.hs (the main ghci loop) import > System.Console.Editline.Readline instead of System.Console.Readline. > > Does that sound like the right way to handle this? If so, I'll send a > darcs patch. An alternative that would make the GHC configure script more symmetric with respect to command line editor would be to have --with-line-editor=editline, --with-line-editor=readline and also, perhaps, --with-line-editor=none (or even --with-line-editor=). All of these with, hopefully, obvious meanings. On top of this, one could have --with-edit-line=automatic with some automatic selection taking place. And the default? I'm sure that my favorite --with-line-editor=none will not be considered practical, so I will leave this most difficult choice to others. > > Also, should editline be made a boot-package or an extra-package (or neither)? > > Thanks, > -Judah > ... Thanks a lot again. Best regards Thorkil From lemming at henning-thielemann.de Thu Jan 17 01:43:08 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Thu Jan 17 01:36:19 2008 Subject: Proposal: Add split and splitWith (trac #2048) In-Reply-To: <478E8C95.7020500@gmail.com> References: <478E8C95.7020500@gmail.com> Message-ID: On Thu, 17 Jan 2008, Twan van Laarhoven wrote: > Hello Haskellers, > > An often requested function is 'split', to split a list into parts delimited by > some separator. ByteString has the functions split and splitWith for this > purpose. I propose we add equivalents to Data.List: > > > split :: Eq a => a -> [a] -> [[a]] > > split x = splitWith (x==) > > > > splitWith :: (a -> Bool) -> [a] -> [[a]] > > splitWith p xs = ys : case zs of > > [] -> [] > > _:ws -> splitWith p ws > > where (ys,zs) = break p xs > > trac: http://hackage.haskell.org/trac/ghc/ticket/2048 > deadline: two weeks from now, January 30 The type could be more specific. We know that the result list is always non-empty, and that the first element of each sub-list matches 'p', except the leading sub-list. Ideally we had a list type for elements of alternating type, like this one: http://darcs.haskell.org/event-list/src/Data/AlternatingList/List/Uniform.hs Then we could use the signature: splitWith :: (a -> Bool) -> [a] -> AlternatingList.T [a] a We can simulate this type by: splitWith :: (a -> Bool) -> [a] -> ([a], [(a, [a])]) From lemming at henning-thielemann.de Thu Jan 17 01:45:41 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Thu Jan 17 01:38:51 2008 Subject: Proposal: Add split and splitWith (trac #2048) In-Reply-To: References: <478E8C95.7020500@gmail.com> Message-ID: On Thu, 17 Jan 2008, Henning Thielemann wrote: > On Thu, 17 Jan 2008, Twan van Laarhoven wrote: > > > Hello Haskellers, > > > > An often requested function is 'split', to split a list into parts delimited by > > some separator. ByteString has the functions split and splitWith for this > > purpose. I propose we add equivalents to Data.List: > > > > > split :: Eq a => a -> [a] -> [[a]] > > > split x = splitWith (x==) > > > > > > splitWith :: (a -> Bool) -> [a] -> [[a]] > > > splitWith p xs = ys : case zs of > > > [] -> [] > > > _:ws -> splitWith p ws > > > where (ys,zs) = break p xs > > > > trac: http://hackage.haskell.org/trac/ghc/ticket/2048 > > deadline: two weeks from now, January 30 > > The type could be more specific. We know that the result list is always > non-empty, and that the first element of each sub-list matches 'p', except > the leading sub-list. Ideally we had a list type for elements of > alternating type, like this one: > http://darcs.haskell.org/event-list/src/Data/AlternatingList/List/Uniform.hs > Then we could use the signature: > splitWith :: (a -> Bool) -> [a] -> AlternatingList.T [a] a > > We can simulate this type by: > splitWith :: (a -> Bool) -> [a] -> ([a], [(a, [a])]) Ah, I see that your function filters out the elements, that match 'p'. This simplifies the resulting list type ... From lemming at henning-thielemann.de Thu Jan 17 01:53:00 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Thu Jan 17 01:46:11 2008 Subject: Proposal: Add split and splitWith (trac #2048) In-Reply-To: <20080117000025.GA27886@matrix.chaos.earth.li> References: <478E8C95.7020500@gmail.com> <20080117000025.GA27886@matrix.chaos.earth.li> Message-ID: On Thu, 17 Jan 2008, Ian Lynagh wrote: > On Thu, Jan 17, 2008 at 12:00:37AM +0100, Twan van Laarhoven wrote: > > > > An often requested function is 'split', to split a list into parts > > delimited by some separator. ByteString has the functions split and > > splitWith for this purpose. I propose we add equivalents to Data.List: > > > > > split :: Eq a => a -> [a] -> [[a]] > > > split x = splitWith (x==) > > > > > > splitWith :: (a -> Bool) -> [a] -> [[a]] > > > splitWith p xs = ys : case zs of > > > [] -> [] > > > _:ws -> splitWith p ws > > > where (ys,zs) = break p xs > > One or the other should be changed so that these agree: > > *Main> split 'a' "" > [""] > *Main> Data.ByteString.Char8.split 'a' (Data.ByteString.Char8.pack "") > Loading package array-0.1.0.0 ... linking ... done. > Loading package bytestring-0.9.0.1 ... linking ... done. > [] > > although I couldn't say which is "right" OTTOMH... List's split is more consistent. It always returns a non-empty list. The number of sub-lists is the number of matching elements plus 1. From lemming at henning-thielemann.de Thu Jan 17 01:54:24 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Thu Jan 17 01:47:34 2008 Subject: Proposal: Add split and splitWith (trac #2048) In-Reply-To: References: <478E8C95.7020500@gmail.com> <20080117000025.GA27886@matrix.chaos.earth.li> Message-ID: On Thu, 17 Jan 2008, Henning Thielemann wrote: > On Thu, 17 Jan 2008, Ian Lynagh wrote: > > > One or the other should be changed so that these agree: > > > > *Main> split 'a' "" > > [""] > > *Main> Data.ByteString.Char8.split 'a' (Data.ByteString.Char8.pack "") > > Loading package array-0.1.0.0 ... linking ... done. > > Loading package bytestring-0.9.0.1 ... linking ... done. > > [] > > > > although I couldn't say which is "right" OTTOMH... > > List's split is more consistent. It always returns a non-empty list. The > number of sub-lists is the number of matching elements plus 1. For QuickCheck: 1 + length (filter p xs) == length (split p xs) From Christian.Maeder at dfki.de Thu Jan 17 04:19:52 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Thu Jan 17 04:13:06 2008 Subject: Integrating editline with ghc In-Reply-To: <6d74b0d20801161305na9e0732m2a6bae7098ec531d@mail.gmail.com> References: <6d74b0d20801161305na9e0732m2a6bae7098ec531d@mail.gmail.com> Message-ID: <478F1DB8.1080807@dfki.de> Judah Jacobson wrote: > - System.Console.Editline.Readline contains the readline APIs provided > by the editline library (mostly a cut/paste of > System.Console.Readline). I would like to see a restructuring of the old readline package: 1. a _new_ readline package that only contains the interface that can be implemented using libeditline _or_ libreadline. If this package is call "readline" (with a new version number) most libraries i.e. like Shellac would not need modifications. 2. Two further packages for extension of editline and those functions of readline that are not part of "1". Maybe call these packages editline-ext and readline-ext The extended packages "2" could go under extra libs or hackageDB, while "1" remains a boot package for ghc that can link to editline on macs and readline under linux, but has the same interface and package name! Cheers Christian From simons at cryp.to Thu Jan 17 04:56:28 2008 From: simons at cryp.to (Peter Simons) Date: Thu Jan 17 04:49:57 2008 Subject: Announcing: HsDNS Version 1.1 Available For Download Message-ID: <871w8g6aib.fsf@write-only.cryp.to> Hi, HsDNS provides an asynchronous DNS resolver on top of the GNU ADNS library. Not all options are supported, but A, MX, and PTR lookups work nicely. Courtesy of Lutz Donnerhacke , the new 1.1 release adds support for retrieving generic RR types, CNAMEs, and for NSEC zone walking. The library's homepage is at . Using "darcs get", the source code can be downloaded from the very same location. A Cabal release archive is also available at: http://cryp.to/hsdns/hsdns-1.1.tar.gz The software is released under the terms of the GNU Lesser General Public License. Best regards, Peter From duncan.coutts at worc.ox.ac.uk Thu Jan 17 05:36:19 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Jan 17 05:32:49 2008 Subject: Announcing: HsDNS Version 1.1 Available For Download In-Reply-To: <871w8g6aib.fsf@write-only.cryp.to> References: <871w8g6aib.fsf@write-only.cryp.to> Message-ID: <1200566179.5639.173.camel@localhost> On Thu, 2008-01-17 at 10:56 +0100, Peter Simons wrote: > Hi, > > HsDNS provides an asynchronous DNS resolver on top of the GNU ADNS > library. Not all options are supported, but A, MX, and PTR lookups > work nicely. Courtesy of Lutz Donnerhacke , the new > 1.1 release adds support for retrieving generic RR types, CNAMEs, and > for NSEC zone walking. > > The library's homepage is at . Using "darcs > get", the source code can be downloaded from the very same location. A > Cabal release archive is also available at: > > http://cryp.to/hsdns/hsdns-1.1.tar.gz > > The software is released under the terms of the GNU Lesser General > Public License. Great. Will we see this on hackage? The current hackage version is 1.0: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hsdns-1.0 Duncan From Malcolm.Wallace at cs.york.ac.uk Thu Jan 17 05:47:33 2008 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Thu Jan 17 05:41:50 2008 Subject: Integrating editline with ghc In-Reply-To: <478F1DB8.1080807@dfki.de> References: <6d74b0d20801161305na9e0732m2a6bae7098ec531d@mail.gmail.com> <478F1DB8.1080807@dfki.de> Message-ID: <20080117104733.47ea65ad.Malcolm.Wallace@cs.york.ac.uk> Christian Maeder wrote: > 1. a _new_ readline package that only contains the interface that can > be implemented using libeditline _or_ libreadline. If this package is > call "readline" (with a new version number) most libraries i.e. like > Shellac would not need modifications. I totally agree. Backwards compatibility for all the programs out there that already use the readline package (but really don't care whether it is actually readline or editline) is vital. I would hate to see all client code forced to use CPP macros and cabal magic to select the right package and module imports. We can avoid such a retrograde step by explicitly making 'readline' the backend-agnostic package, which re-exports functionality from either the real readline or editline, depending on which is available. Regards, Malcolm From simons at cryp.to Thu Jan 17 06:15:30 2008 From: simons at cryp.to (Peter Simons) Date: Thu Jan 17 06:08:52 2008 Subject: Announcing: HsDNS Version 1.1 Available For Download References: <871w8g6aib.fsf@write-only.cryp.to> <1200566179.5639.173.camel@localhost> Message-ID: <87ir1s4sa5.fsf@write-only.cryp.to> Duncan Coutts writes: > Will we see this on hackage? > > The current hackage version is 1.0: > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hsdns-1.0 Unfortunately, I cannot update the entry at the moment because I don't remember my Hackage login and password; and the machine on which that information is stored is temporarily unavailable. I'll do the update as soon as possible, though. Thank you for reminding me. Best regards, Peter From gale at sefer.org Thu Jan 17 07:48:43 2008 From: gale at sefer.org (Yitzchak Gale) Date: Thu Jan 17 07:41:54 2008 Subject: Integrating editline with ghc In-Reply-To: <20080117104733.47ea65ad.Malcolm.Wallace@cs.york.ac.uk> References: <6d74b0d20801161305na9e0732m2a6bae7098ec531d@mail.gmail.com> <478F1DB8.1080807@dfki.de> <20080117104733.47ea65ad.Malcolm.Wallace@cs.york.ac.uk> Message-ID: <2608b8a80801170448n9828cbfof6fb83cfa8f1e840@mail.gmail.com> Christian Maeder wrote: > 1. a _new_ readline package that only contains the interface that can > be implemented using libeditline _or_ libreadline. +1 > If this package is called "readline" (with a new version number) > most libraries i.e. like Shellac would not need modifications. Well, we do have to take some care. This new package cannot depend on either of the two implementation packages. So when you upgrade, your programs will stop compiling until you manually install one of the two. People who are not aware of what is going on will be perplexed. Perhaps the upgrade path would be smoother if we end-of-life the readline package, and replace it with readline-iface plus the two implementation packages. The last version of readline would be emtpy, with dependencies on readline-iface and readline-readline, and a comment that it can be safely removed once installed. That is the strategy commonly used for this situation by other package systems, like Debian. What do you think? -Yitz From gale at sefer.org Thu Jan 17 08:08:12 2008 From: gale at sefer.org (Yitzchak Gale) Date: Thu Jan 17 08:01:22 2008 Subject: Integrating editline with ghc In-Reply-To: <478F1DB8.1080807@dfki.de> References: <6d74b0d20801161305na9e0732m2a6bae7098ec531d@mail.gmail.com> <478F1DB8.1080807@dfki.de> Message-ID: <2608b8a80801170508o3960c268o720a20350d433907@mail.gmail.com> Christian Maeder wrote: > The extended packages "2" could go under extra libs or hackageDB, while > "1" remains a boot package for ghc that can link to editline on macs > and readline under linux, but has the same interface and package name! I would hope that ghc will link to editline-ext on all platforms. That gives ghc the functionality it needs without getting into legal trouble with the license. Then those who want the full readline interface can install readline-ext, and those who want the full editline interface can install editline. -Yitz From isaacdupree at charter.net Thu Jan 17 08:27:20 2008 From: isaacdupree at charter.net (Isaac Dupree) Date: Thu Jan 17 08:20:29 2008 Subject: Integrating editline with ghc In-Reply-To: <2608b8a80801170508o3960c268o720a20350d433907@mail.gmail.com> References: <6d74b0d20801161305na9e0732m2a6bae7098ec531d@mail.gmail.com> <478F1DB8.1080807@dfki.de> <2608b8a80801170508o3960c268o720a20350d433907@mail.gmail.com> Message-ID: <478F57B8.8060806@charter.net> Yitzchak Gale wrote: > Christian Maeder wrote: >> The extended packages "2" could go under extra libs or hackageDB, while >> "1" remains a boot package for ghc that can link to editline on macs >> and readline under linux, but has the same interface and package name! > > I would hope that ghc will link to editline-ext on all platforms. > That gives ghc the functionality it needs without getting > into legal trouble with the license. Then those who want the full > readline interface can install readline-ext, and those who > want the full editline interface can install editline. GHC is in no legal trouble whatsoever... only if proprietary Haskell code uses the readline library and doesn't switch to using the editline backend. On Linux here I have readline installed and not editline currently, so it seems silly to require installing editline by default ("default" meaning "if I don't want to, I have to figure out the right configure flag to give to allow readline to be used"). It makes sense to use editline by default for Mac and Windows builds though, where readline isn't native, I guess. Statically linking to editline for binary builds would be alright (not exporting any readline to ghc-compiled programs by default?). How is "Search for editline first; if not found, try to use readline"? ~Isaac From ahey at iee.org Thu Jan 17 08:51:22 2008 From: ahey at iee.org (Adrian Hey) Date: Thu Jan 17 08:44:47 2008 Subject: GHC options in Cabal Message-ID: <478F5D5A.9070400@iee.org> Hello, Looking at the latest Cabal docs, I see that in addition to ghc-options, there are also ghc-prof-options and ghc-shared-options. What isn't clear to me though from the docs is that are the latter two in addition to the first, or are they a substitute for the first (for profiling/shared). IOW, if I already have.. ghc-options: -O2 will the O2 also be applied to profiling build (say)? Or do I need an extra explicit.. ghc-prof-options: -O2 Thanks -- Adrian Hey From Christian.Maeder at dfki.de Thu Jan 17 09:00:48 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Thu Jan 17 08:54:00 2008 Subject: Integrating editline with ghc In-Reply-To: <2608b8a80801170508o3960c268o720a20350d433907@mail.gmail.com> References: <6d74b0d20801161305na9e0732m2a6bae7098ec531d@mail.gmail.com> <478F1DB8.1080807@dfki.de> <2608b8a80801170508o3960c268o720a20350d433907@mail.gmail.com> Message-ID: <478F5F90.1030804@dfki.de> Yitzchak Gale wrote: > Christian Maeder wrote: >> The extended packages "2" could go under extra libs or hackageDB, while >> "1" remains a boot package for ghc that can link to editline on macs >> and readline under linux, but has the same interface and package name! > > I would hope that ghc will link to editline-ext on all platforms. > That gives ghc the functionality it needs without getting > into legal trouble with the license. Then those who want the full > readline interface can install readline-ext, and those who > want the full editline interface can install editline. Just to clarify: ghc will link to "libedit" if it is available on your platform, but the Haskell package will still have the name "readline" and give ghc all the functionality it needs (without licence problems). Only the current readline Haskell package needs "libreadline" and supplies more functionality than needed by ghc. This extra-functionality should go into a new Haskell package readline-ext (that will only be rarely needed). The haskell package "editline-ext" is just an add-on that _requires_ "libedit" (an is only needed for special future developments). Also editline-ext should only be used rarely, because some installation will still only have "libreadline". The new haskell package "readline" will only contain the common functionality of libedit and libreadline! The new haskell package "readline" should not be renamed in order to achieve best backward compatibility in most cases. Renaming it (i.e. to "editline") would not change the possibility to either link to libedit _or_ libreadline (but would require to change all packages that currently use readline) Christian From isaacdupree at charter.net Thu Jan 17 09:41:18 2008 From: isaacdupree at charter.net (Isaac Dupree) Date: Thu Jan 17 09:34:25 2008 Subject: darcs patch: make Alex only occupy {alex,Alex,ALEX}* names (still assuming Prelude) Message-ID: <478F690E.3030704@charter.net> Happy and Alex add imports to the file they contain: Char (ord), Array (if given `-a` flag, for example -- it's not reliable), etc. Adding an import can cause errors; for example, importing unboxed arithmetic from GHC.Exts caused an error when I imported a differently-defined set of functions named the same way; I so far locally added a 'hiding' clause to work around that, to work around those errors: in ghc/compiler/parser/Lexer.x import FastTypes hiding ((+#),(>=#),(==#)) Removing an import can cause errors: for example, one .x (or was it .y?) module in GHC's code used Array without importing it, and another used ord without importing it (these were fixed in GHC head and 6.8 branch). Therefore I propose that, though it may break code in the short term, Happy and Alex should only import things qualified as AlexSomething. It didn't make things too ugly; they still rely on sufficient basic Prelude stuff being imported without qualification by the module that uses Happy/Alex, but that seems the best arrangement to me anyway. (for example, if a module wants to redefine (&&) in a compatible way -- this has been done with type-classes, Alex will at least try to use that instead of importing (&&) unqualified from the Prelude and getting an ambiguity error) This patch does that for Alex, and I've been using it to compile GHC; a similar patch would be a similar amount of work to make for Happy. Thoughts? Does this seem like a good idea? Thu Dec 27 13:57:22 EST 2007 Isaac Dupree * make Alex only occupy {alex,Alex,ALEX}* names (still assuming Prelude) -------------- next part -------------- New patches: [make Alex only occupy {alex,Alex,ALEX}* names (still assuming Prelude) Isaac Dupree **20071227185722] { hunk ./src/Info.hs 63 --- = str "Array.array " . shows (bounds arr) . space +-- = str "AlexArray.array " . shows (bounds arr) . space hunk ./src/Main.hs 179 - "import Data.Array\n" ++ - "import Data.Char (ord)\n" ++ - "import Data.Array.Base (unsafeAt)\n" ++ + "import qualified Data.Array as AlexArray\n" ++ + "import qualified Data.Char as AlexChar (ord)\n" ++ + "import qualified Data.Array.Base as AlexArrayBase (unsafeAt)\n" ++ hunk ./src/Main.hs 183 - "import Array\n" ++ - "import Char (ord)\n" ++ + "import qualified Array as AlexArray\n" ++ + "import qualified Char as AlexChar (ord)\n" ++ hunk ./src/Main.hs 189 - "import GHC.Exts\n" ++ + "import qualified GHC.Exts as AlexGHCExts\n" ++ hunk ./src/Main.hs 191 - "import GlaExts\n" ++ + "import qualified GlaExts as AlexGHCExts\n" ++ hunk ./src/Main.hs 195 -import_debug = "#if __GLASGOW_HASKELL__ >= 503\n" ++ - "import System.IO\n" ++ - "import System.IO.Unsafe\n" ++ - "import Debug.Trace\n" ++ +import_debug = "#ifdef ALEX_DEBUG\n" ++ +--"IOExts" is dead: assume arbitrary compilers use the hierarchical names + "#if !defined(__GLASGOW_HASKELL__) || __GLASGOW_HASKELL__ >= 503\n" ++ + "import qualified System.IO as AlexDebug\n" ++ + "import qualified System.IO.Unsafe as AlexDebug\n" ++ + "import qualified Debug.Trace as AlexDebug\n" ++ hunk ./src/Main.hs 202 - "import IO\n" ++ - "import IOExts\n" ++ + "import qualified IO as AlexDebug\n" ++ + "import qualified IOExts as AlexDebug\n" ++ + "#endif\n" ++ hunk ./src/Output.hs 60 - str nm . str " :: Array Int Int\n" - . str nm . str " = listArray (0," . shows upper_bound + str nm . str " :: AlexArray.Array Int Int\n" + . str nm . str " = AlexArray.listArray (0," . shows upper_bound hunk ./src/Output.hs 67 - -- str accept_nm . str " :: Array Int (Accept Code)\n" - str accept_nm . str " = listArray (0::Int," . shows n_states + -- str accept_nm . str " :: AlexArray.Array Int (Accept Code)\n" + str accept_nm . str " = AlexArray.listArray (0::Int," . shows n_states hunk ./src/Output.hs 111 - = str "array " . shows (bounds arr) . space + = str "AlexArray.array " . shows (bounds arr) . space hunk ./src/Scan.hs 1 -{-# OPTIONS -fglasgow-exts -cpp #-} -{-# LINE 13 "src/Scan.x" #-} -module Scan(lexer, AlexPosn(..), Token(..), Tkn(..), tokPosn) where - -import Data.Char -import ParseMonad ---import Debug.Trace - -#if __GLASGOW_HASKELL__ >= 603 -#include "ghcconfig.h" -#else -#include "config.h" -#endif -#if __GLASGOW_HASKELL__ >= 503 -import Data.Array -import Data.Char (ord) -import Data.Array.Base (unsafeAt) -#else -import Array -import Char (ord) -#endif -#if __GLASGOW_HASKELL__ >= 503 -import GHC.Exts -#else -import GlaExts -#endif -alex_base :: AlexAddr -alex_base = AlexA# "\xf8\xff\xff\xff\x6e\x00\x00\x00\x89\x00\x00\x00\x77\x00\x00\x00\x7c\x00\x00\x00\xfc\xff\xff\xff\xfd\xff\xff\xff\xdb\xff\xff\xff\xdc\xff\xff\xff\x00\x00\x00\x00\x80\x00\x00\x00\x81\x00\x00\x00\x00\x00\x00\x00\x72\x00\x00\x00\xdd\xff\xff\xff\x73\x00\x00\x00\xde\xff\xff\xff\xfb\x00\x00\x00\x6d\x01\x00\x00\x00\x01\x00\x00\x74\x00\x00\x00\x75\x00\x00\x00\xdf\xff\xff\xff\x00\x00\x00\x00\x8a\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xa7\x01\x00\x00\x00\x00\x00\x00\x96\xff\xff\xff\x9c\xff\xff\xff\xae\xff\xff\xff\xa0\xff\xff\xff\xa1\xff\xff\xff\xad\xff\xff\xff\xa2\xff\xff\xff\xde\x00\x00\x00\x4b\x01\x00\x00\x03\x02\x00\x00\x52\x02\x00\x00\x69\x02\x00\x00\x55\x01\x00\x00\x89\x02\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x8f\x02\x00\x00\x02\x03\x00\x00\x74\x03\x00\x00\x84\x02\x00\x00\xc8\x03\x00\x00\x1c\x04\x00\x00\x59\x04\x00\x00\xcb\x04\x00\x00\x3d\x05\x00\x00\xaf\x05\x00\x00\xad\x05\x00\x00\x01\x06\x00\x00\x3e\x06\x00\x00\x00\x00\x00\x00\x87\x00\x00\x00\x8c\x01\x00\x00\xa7\x00\x00\x00\xa8\x00\x00\x00\xe6\xff\xff\xff\x00\x00\x00\x00\xa9\x00\x00\x00\x21\x03\x00\x00\xaa\x00\x00\x00\x19\x01\x00\x00\xe8\xff\xff\xff\x00\x00\x00\x00\x00\x00\x00\x00\x92\x06\x00\x00\xe6\x06\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xe0\x02\x00\x00"# - -alex_table :: AlexAddr -alex_table = AlexA# "\x00\x00\x04\x00\x04\x00\x04\x00\x04\x00\x04\x00\xff\xff\xff\xff\x05\x00\x05\x00\x0c\x00\x0c\x00\x14\x00\x1e\x00\x1f\x00\x20\x00\x21\x00\x22\x00\x23\x00\x3d\x00\x1c\x00\x43\x00\x00\x00\x00\x00\x04\x00\x2c\x00\x0a\x00\x1a\x00\x1b\x00\x1d\x00\x2c\x00\x2c\x00\x1a\x00\x1a\x00\x1a\x00\x1a\x00\x1a\x00\x08\x00\x1a\x00\x1a\x00\x2c\x00\x2c\x00\x2c\x00\x2c\x00\x2c\x00\x2c\x00\x2c\x00\x2c\x00\x2c\x00\x2c\x00\x10\x00\x1a\x00\x46\x00\x2c\x00\x2c\x00\x1a\x00\x2d\x00\x11\x00\x11\x00\x11\x00\x11\x00\x11\x00\x11\x00\x11\x00\x11\x00\x11\x00\x11\x00\x11\x00\x11\x00\x11\x00\x11\x00\x11\x00\x11\x00\x11\x00\x11\x00\x11\x00\x11\x00\x11\x00\x11\x00\x11\x00\x11\x00\x11\x00\x11\x00\x1a\x00\x26\x00\x1a\x00\x1a\x00\x2c\x00\x2c\x00\x11\x00\x11\x00\x11\x00\x11\x00\x11\x00\x11\x00\x11\x00\x11\x00\x11\x00\x11\x00\x11\x00\x11\x00\x11\x00\x11\x00\x11\x00\x11\x00\x11\x00\x11\x00\x11\x00\x11\x00\x11\x00\x11\x00\x11\x00\x11\x00\x11\x00\x11\x00\x17\x00\x1a\x00\x1a\x00\x1a\x00\x04\x00\x04\x00\x04\x00\x04\x00\x04\x00\xff\xff\xff\xff\xff\xff\xff\xff\x04\x00\x04\x00\x04\x00\x04\x00\x04\x00\x04\x00\x04\x00\x04\x00\x04\x00\x04\x00\xff\xff\xff\xff\x00\x00\x00\x00\x04\x00\x00\x00\x00\x00\xff\xff\x04\x00\x04\x00\x04\x00\x04\x00\x04\x00\x04\x00\x00\x00\x00\x00\x00\x00\x07\x00\x04\x00\x00\x00\x00\x00\x00\x00\x0d\x00\x00\x00\x09\x00\x09\x00\x07\x00\x00\x00\x00\x00\x00\x00\x00\x00\x04\x00\x00\x00\x00\x00\x0f\x00\x0f\x00\x0f\x00\x0f\x00\x00\x00\xff\xff\xff\xff\xff\xff\xff\xff\x4a\x00\x07\x00\x00\x00\x00\x00\x47\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\x3b\x00\x00\x00\x00\x00\x4b\x00\x00\x00\x00\x00\x48\x00\x48\x00\x48\x00\x48\x00\x48\x00\x48\x00\x48\x00\x48\x00\x48\x00\x48\x00\x48\x00\x48\x00\x48\x00\x48\x00\x48\x00\x48\x00\x48\x00\x48\x00\x48\x00\x48\x00\x48\x00\x48\x00\x48\x00\x48\x00\x48\x00\x48\x00\x3b\x00\x3b\x00\x41\x00\x41\x00\x00\x00\x4d\x00\x48\x00\x48\x00\x48\x00\x48\x00\x48\x00\x48\x00\x48\x00\x48\x00\x48\x00\x48\x00\x48\x00\x48\x00\x48\x00\x48\x00\x48\x00\x48\x00\x48\x00\x48\x00\x48\x00\x48\x00\x48\x00\x48\x00\x48\x00\x48\x00\x48\x00\x48\x00\x13\x00\x13\x00\x13\x00\x13\x00\x13\x00\x13\x00\x13\x00\x13\x00\x13\x00\x13\x00\x24\x00\x24\x00\x24\x00\x24\x00\x24\x00\x24\x00\x24\x00\x24\x00\x24\x00\x24\x00\x00\x00\x00\x00\x00\x00\x13\x00\x00\x00\x00\x00\x00\x00\x00\x00\x13\x00\x00\x00\x12\x00\xff\xff\x00\x00\x00\x00\x00\x00\x00\x00\x16\x00\x00\x00\x00\x00\x12\x00\x12\x00\x12\x00\x12\x00\x12\x00\x12\x00\x12\x00\x12\x00\x12\x00\x12\x00\x0e\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0e\x00\x00\x00\x12\x00\x12\x00\x12\x00\x12\x00\x12\x00\x12\x00\x12\x00\x12\x00\x12\x00\x12\x00\x12\x00\x12\x00\x12\x00\x12\x00\x12\x00\x12\x00\x12\x00\x12\x00\x12\x00\x12\x00\x12\x00\x12\x00\x12\x00\x12\x00\x12\x00\x12\x00\x41\x00\x00\x00\x00\x00\x00\x00\x12\x00\x00\x00\x12\x00\x12\x00\x12\x00\x12\x00\x12\x00\x12\x00\x12\x00\x12\x00\x12\x00\x12\x00\x12\x00\x12\x00\x12\x00\x12\x00\x12\x00\x12\x00\x12\x00\x12\x00\x12\x00\x12\x00\x12\x00\x12\x00\x12\x00\x12\x00\x12\x00\x12\x00\x13\x00\x13\x00\x13\x00\x13\x00\x13\x00\x24\x00\x24\x00\x24\x00\x24\x00\x24\x00\x24\x00\x24\x00\x24\x00\x24\x00\x24\x00\x29\x00\x29\x00\x29\x00\x29\x00\x29\x00\x29\x00\x29\x00\x29\x00\x13\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x12\x00\x3c\x00\x3c\x00\x3c\x00\x3c\x00\x3c\x00\x16\x00\x00\x00\x00\x00\x12\x00\x12\x00\x12\x00\x12\x00\x12\x00\x12\x00\x12\x00\x12\x00\x12\x00\x12\x00\x0e\x00\x00\x00\x00\x00\x00\x00\x00\x00\x3c\x00\x00\x00\x12\x00\x12\x00\x12\x00\x12\x00\x12\x00\x12\x00\x12\x00\x12\x00\x12\x00\x12\x00\x12\x00\x12\x00\x12\x00\x12\x00\x12\x00\x12\x00\x12\x00\x12\x00\x12\x00\x12\x00\x12\x00\x12\x00\x12\x00\x12\x00\x12\x00\x12\x00\x00\x00\x3a\x00\x00\x00\x00\x00\x12\x00\x00\x00\x12\x00\x12\x00\x12\x00\x12\x00\x12\x00\x12\x00\x12\x00\x12\x00\x12\x00\x12\x00\x12\x00\x12\x00\x12\x00\x12\x00\x12\x00\x12\x00\x12\x00\x12\x00\x12\x00\x12\x00\x12\x00\x12\x00\x12\x00\x12\x00\x12\x00\x12\x00\x2e\x00\x2e\x00\x2e\x00\x2e\x00\x2e\x00\x2e\x00\x2e\x00\x2e\x00\x2e\x00\x2e\x00\x2e\x00\x2e\x00\x2e\x00\x2e\x00\x2e\x00\x2e\x00\x2e\x00\x2e\x00\x2e\x00\x2e\x00\x2e\x00\x2e\x00\x2e\x00\x2e\x00\x2e\x00\x2e\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x2e\x00\x2e\x00\x2e\x00\x2e\x00\x2e\x00\x2e\x00\x2e\x00\x2e\x00\x2e\x00\x2e\x00\x2e\x00\x2e\x00\x2e\x00\x2e\x00\x2e\x00\x2e\x00\x2e\x00\x2e\x00\x2e\x00\x2e\x00\x2e\x00\x2e\x00\x2e\x00\x2e\x00\x2e\x00\x2e\x00\x33\x00\x2b\x00\x2b\x00\x2b\x00\x2b\x00\x2b\x00\x2b\x00\x2b\x00\x2b\x00\x2b\x00\x2b\x00\x2b\x00\x2b\x00\x2b\x00\x2b\x00\x2b\x00\x2b\x00\x25\x00\x25\x00\x25\x00\x25\x00\x25\x00\x25\x00\x25\x00\x25\x00\x25\x00\x25\x00\x2b\x00\x2b\x00\x2b\x00\x2b\x00\x2b\x00\x2b\x00\x2b\x00\x2b\x00\x2b\x00\x2b\x00\x2b\x00\x2b\x00\x2b\x00\x2b\x00\x2b\x00\x2b\x00\x2b\x00\x2b\x00\x2b\x00\x2b\x00\x2b\x00\x2b\x00\x2b\x00\x2b\x00\x2b\x00\x2b\x00\x2b\x00\x2b\x00\x2b\x00\x2b\x00\x2b\x00\x2b\x00\x2b\x00\x2b\x00\x2b\x00\x2b\x00\x2b\x00\x2b\x00\x2b\x00\x2b\x00\x2b\x00\x2b\x00\x2b\x00\x2b\x00\x2b\x00\x2b\x00\x2b\x00\x2b\x00\x2b\x00\x2b\x00\x2b\x00\x2b\x00\x2b\x00\x2a\x00\x2b\x00\x2b\x00\x2b\x00\x2b\x00\x2b\x00\x2b\x00\x2b\x00\x2b\x00\x28\x00\x2b\x00\x2b\x00\x2b\x00\x2b\x00\x2b\x00\x2b\x00\x27\x00\x27\x00\x27\x00\x27\x00\x27\x00\x27\x00\x27\x00\x27\x00\x27\x00\x27\x00\x00\x00\x3c\x00\x3c\x00\x3c\x00\x3c\x00\x3c\x00\x00\x00\x27\x00\x27\x00\x27\x00\x27\x00\x27\x00\x27\x00\x27\x00\x27\x00\x27\x00\x27\x00\x27\x00\x27\x00\x27\x00\x27\x00\x27\x00\x27\x00\x00\x00\x3c\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x27\x00\x27\x00\x27\x00\x27\x00\x27\x00\x27\x00\x00\x00\x3f\x00\x00\x00\x27\x00\x27\x00\x27\x00\x27\x00\x27\x00\x27\x00\x29\x00\x29\x00\x29\x00\x29\x00\x29\x00\x29\x00\x29\x00\x29\x00\x3a\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x27\x00\x27\x00\x27\x00\x27\x00\x27\x00\x27\x00\x34\x00\x34\x00\x34\x00\x34\x00\x34\x00\x34\x00\x34\x00\x34\x00\x34\x00\x34\x00\x34\x00\x34\x00\x34\x00\x34\x00\x34\x00\x34\x00\x34\x00\x34\x00\x34\x00\x34\x00\x34\x00\x34\x00\x34\x00\x34\x00\x34\x00\x34\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x34\x00\x34\x00\x34\x00\x34\x00\x34\x00\x34\x00\x34\x00\x34\x00\x34\x00\x34\x00\x34\x00\x34\x00\x34\x00\x34\x00\x34\x00\x34\x00\x34\x00\x34\x00\x34\x00\x34\x00\x34\x00\x34\x00\x34\x00\x34\x00\x34\x00\x34\x00\x39\x00\x3c\x00\x3c\x00\x3c\x00\x3c\x00\x3c\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x3c\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x2f\x00\x42\x00\x42\x00\x42\x00\x42\x00\x42\x00\x3f\x00\x00\x00\x00\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x00\x00\x00\x00\x00\x00\x3a\x00\x00\x00\x42\x00\x00\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x00\x00\x40\x00\x00\x00\x00\x00\x2f\x00\x00\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x3c\x00\x3c\x00\x3c\x00\x3c\x00\x3c\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x3c\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x2f\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x3f\x00\x00\x00\x00\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x00\x00\x00\x00\x00\x00\x3a\x00\x00\x00\x00\x00\x00\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x00\x00\x00\x00\x00\x00\x00\x00\x2f\x00\x00\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x2f\x00\x32\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x32\x00\x32\x00\x32\x00\x32\x00\x32\x00\x32\x00\x32\x00\x32\x00\x32\x00\x32\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x32\x00\x32\x00\x32\x00\x32\x00\x32\x00\x32\x00\x32\x00\x32\x00\x32\x00\x32\x00\x32\x00\x32\x00\x32\x00\x32\x00\x32\x00\x32\x00\x32\x00\x32\x00\x32\x00\x32\x00\x32\x00\x32\x00\x32\x00\x32\x00\x32\x00\x32\x00\x00\x00\x00\x00\x00\x00\x00\x00\x32\x00\x00\x00\x32\x00\x32\x00\x32\x00\x32\x00\x32\x00\x32\x00\x32\x00\x32\x00\x32\x00\x32\x00\x32\x00\x32\x00\x32\x00\x32\x00\x32\x00\x32\x00\x32\x00\x32\x00\x32\x00\x32\x00\x32\x00\x32\x00\x32\x00\x32\x00\x32\x00\x32\x00\x32\x00\x00\x00\x30\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x32\x00\x32\x00\x32\x00\x32\x00\x32\x00\x32\x00\x32\x00\x32\x00\x32\x00\x32\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x32\x00\x32\x00\x32\x00\x32\x00\x32\x00\x32\x00\x32\x00\x32\x00\x32\x00\x32\x00\x32\x00\x32\x00\x32\x00\x32\x00\x32\x00\x32\x00\x32\x00\x32\x00\x32\x00\x32\x00\x32\x00\x32\x00\x32\x00\x32\x00\x32\x00\x32\x00\x00\x00\x00\x00\x00\x00\x00\x00\x32\x00\x00\x00\x32\x00\x32\x00\x32\x00\x32\x00\x32\x00\x32\x00\x32\x00\x32\x00\x32\x00\x32\x00\x32\x00\x32\x00\x32\x00\x32\x00\x32\x00\x32\x00\x32\x00\x32\x00\x32\x00\x32\x00\x32\x00\x32\x00\x32\x00\x32\x00\x32\x00\x32\x00\x00\x00\x00\x00\x30\x00\x31\x00\x31\x00\x31\x00\x31\x00\x31\x00\x31\x00\x31\x00\x31\x00\x31\x00\x31\x00\x31\x00\x31\x00\x31\x00\x31\x00\x31\x00\x31\x00\x31\x00\x31\x00\x31\x00\x31\x00\x31\x00\x31\x00\x31\x00\x31\x00\x31\x00\x31\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x31\x00\x31\x00\x31\x00\x31\x00\x31\x00\x31\x00\x31\x00\x31\x00\x31\x00\x31\x00\x31\x00\x31\x00\x31\x00\x31\x00\x31\x00\x31\x00\x31\x00\x31\x00\x31\x00\x31\x00\x31\x00\x31\x00\x31\x00\x31\x00\x31\x00\x31\x00\x42\x00\x42\x00\x42\x00\x42\x00\x42\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x42\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x35\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x45\x00\x00\x00\x00\x00\x35\x00\x35\x00\x35\x00\x35\x00\x35\x00\x35\x00\x35\x00\x35\x00\x35\x00\x35\x00\x00\x00\x00\x00\x00\x00\x40\x00\x00\x00\x00\x00\x00\x00\x35\x00\x35\x00\x35\x00\x35\x00\x35\x00\x35\x00\x35\x00\x35\x00\x35\x00\x35\x00\x35\x00\x35\x00\x35\x00\x35\x00\x35\x00\x35\x00\x35\x00\x35\x00\x35\x00\x35\x00\x35\x00\x35\x00\x35\x00\x35\x00\x35\x00\x35\x00\x00\x00\x00\x00\x00\x00\x00\x00\x35\x00\x00\x00\x35\x00\x35\x00\x35\x00\x35\x00\x35\x00\x35\x00\x35\x00\x35\x00\x35\x00\x35\x00\x35\x00\x35\x00\x35\x00\x35\x00\x35\x00\x35\x00\x35\x00\x35\x00\x35\x00\x35\x00\x35\x00\x35\x00\x35\x00\x35\x00\x35\x00\x35\x00\x42\x00\x42\x00\x42\x00\x42\x00\x42\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x42\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x35\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x45\x00\x00\x00\x00\x00\x35\x00\x35\x00\x35\x00\x35\x00\x35\x00\x35\x00\x35\x00\x35\x00\x35\x00\x35\x00\x00\x00\x00\x00\x00\x00\x40\x00\x00\x00\x00\x00\x00\x00\x35\x00\x35\x00\x35\x00\x35\x00\x35\x00\x35\x00\x35\x00\x35\x00\x35\x00\x35\x00\x35\x00\x35\x00\x35\x00\x35\x00\x35\x00\x35\x00\x35\x00\x35\x00\x35\x00\x35\x00\x35\x00\x35\x00\x35\x00\x35\x00\x35\x00\x35\x00\x00\x00\x00\x00\x00\x00\x00\x00\x35\x00\x00\x00\x35\x00\x35\x00\x35\x00\x35\x00\x35\x00\x35\x00\x35\x00\x35\x00\x35\x00\x35\x00\x35\x00\x35\x00\x35\x00\x35\x00\x35\x00\x35\x00\x35\x00\x35\x00\x35\x00\x35\x00\x35\x00\x35\x00\x35\x00\x35\x00\x35\x00\x35\x00\x42\x00\x42\x00\x42\x00\x42\x00\x42\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x42\x00\x00\x00\x00\x00\x00\x00\x00\x00\x38\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x45\x00\x38\x00\x38\x00\x38\x00\x38\x00\x38\x00\x38\x00\x38\x00\x38\x00\x38\x00\x38\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x40\x00\x00\x00\x38\x00\x38\x00\x38\x00\x38\x00\x38\x00\x38\x00\x38\x00\x38\x00\x38\x00\x38\x00\x38\x00\x38\x00\x38\x00\x38\x00\x38\x00\x38\x00\x38\x00\x38\x00\x38\x00\x38\x00\x38\x00\x38\x00\x38\x00\x38\x00\x38\x00\x38\x00\x00\x00\x00\x00\x00\x00\x00\x00\x38\x00\x00\x00\x38\x00\x38\x00\x38\x00\x38\x00\x38\x00\x38\x00\x38\x00\x38\x00\x38\x00\x38\x00\x38\x00\x38\x00\x38\x00\x38\x00\x38\x00\x38\x00\x38\x00\x38\x00\x38\x00\x38\x00\x38\x00\x38\x00\x38\x00\x38\x00\x38\x00\x38\x00\x38\x00\x00\x00\x36\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x38\x00\x38\x00\x38\x00\x38\x00\x38\x00\x38\x00\x38\x00\x38\x00\x38\x00\x38\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x38\x00\x38\x00\x38\x00\x38\x00\x38\x00\x38\x00\x38\x00\x38\x00\x38\x00\x38\x00\x38\x00\x38\x00\x38\x00\x38\x00\x38\x00\x38\x00\x38\x00\x38\x00\x38\x00\x38\x00\x38\x00\x38\x00\x38\x00\x38\x00\x38\x00\x38\x00\x00\x00\x00\x00\x00\x00\x00\x00\x38\x00\x00\x00\x38\x00\x38\x00\x38\x00\x38\x00\x38\x00\x38\x00\x38\x00\x38\x00\x38\x00\x38\x00\x38\x00\x38\x00\x38\x00\x38\x00\x38\x00\x38\x00\x38\x00\x38\x00\x38\x00\x38\x00\x38\x00\x38\x00\x38\x00\x38\x00\x38\x00\x38\x00\x00\x00\x00\x00\x36\x00\x37\x00\x37\x00\x37\x00\x37\x00\x37\x00\x37\x00\x37\x00\x37\x00\x37\x00\x37\x00\x37\x00\x37\x00\x37\x00\x37\x00\x37\x00\x37\x00\x37\x00\x37\x00\x37\x00\x37\x00\x37\x00\x37\x00\x37\x00\x37\x00\x37\x00\x37\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x37\x00\x37\x00\x37\x00\x37\x00\x37\x00\x37\x00\x37\x00\x37\x00\x37\x00\x37\x00\x37\x00\x37\x00\x37\x00\x37\x00\x37\x00\x37\x00\x37\x00\x37\x00\x37\x00\x37\x00\x37\x00\x37\x00\x37\x00\x37\x00\x37\x00\x37\x00\x49\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x49\x00\x49\x00\x49\x00\x49\x00\x49\x00\x49\x00\x49\x00\x49\x00\x49\x00\x49\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x49\x00\x49\x00\x49\x00\x49\x00\x49\x00\x49\x00\x49\x00\x49\x00\x49\x00\x49\x00\x49\x00\x49\x00\x49\x00\x49\x00\x49\x00\x49\x00\x49\x00\x49\x00\x49\x00\x49\x00\x49\x00\x49\x00\x49\x00\x49\x00\x49\x00\x49\x00\x00\x00\x00\x00\x00\x00\x00\x00\x49\x00\x00\x00\x49\x00\x49\x00\x49\x00\x49\x00\x49\x00\x49\x00\x49\x00\x49\x00\x49\x00\x49\x00\x49\x00\x49\x00\x49\x00\x49\x00\x49\x00\x49\x00\x49\x00\x49\x00\x49\x00\x49\x00\x49\x00\x49\x00\x49\x00\x49\x00\x49\x00\x49\x00\x49\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x49\x00\x49\x00\x49\x00\x49\x00\x49\x00\x49\x00\x49\x00\x49\x00\x49\x00\x49\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x49\x00\x49\x00\x49\x00\x49\x00\x49\x00\x49\x00\x49\x00\x49\x00\x49\x00\x49\x00\x49\x00\x49\x00\x49\x00\x49\x00\x49\x00\x49\x00\x49\x00\x49\x00\x49\x00\x49\x00\x49\x00\x49\x00\x49\x00\x49\x00\x49\x00\x49\x00\x00\x00\x00\x00\x00\x00\x00\x00\x49\x00\x00\x00\x49\x00\x49\x00\x49\x00\x49\x00\x49\x00\x49\x00\x49\x00\x49\x00\x49\x00\x49\x00\x49\x00\x49\x00\x49\x00\x49\x00\x49\x00\x49\x00\x49\x00\x49\x00\x49\x00\x49\x00\x49\x00\x49\x00\x49\x00\x49\x00\x49\x00\x49\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"# - -alex_check :: AlexAddr -alex_check = AlexA# "\xff\xff\x09\x00\x0a\x00\x0b\x00\x0c\x00\x0d\x00\x0a\x00\x0a\x00\x2d\x00\x2d\x00\x2d\x00\x2d\x00\x2d\x00\x77\x00\x72\x00\x61\x00\x70\x00\x70\x00\x65\x00\x2d\x00\x72\x00\x2d\x00\xff\xff\xff\xff\x20\x00\x21\x00\x22\x00\x23\x00\x24\x00\x25\x00\x26\x00\x27\x00\x28\x00\x29\x00\x2a\x00\x2b\x00\x2c\x00\x2d\x00\x2e\x00\x2f\x00\x30\x00\x31\x00\x32\x00\x33\x00\x34\x00\x35\x00\x36\x00\x37\x00\x38\x00\x39\x00\x3a\x00\x3b\x00\x3c\x00\x3d\x00\x3e\x00\x3f\x00\x40\x00\x41\x00\x42\x00\x43\x00\x44\x00\x45\x00\x46\x00\x47\x00\x48\x00\x49\x00\x4a\x00\x4b\x00\x4c\x00\x4d\x00\x4e\x00\x4f\x00\x50\x00\x51\x00\x52\x00\x53\x00\x54\x00\x55\x00\x56\x00\x57\x00\x58\x00\x59\x00\x5a\x00\x5b\x00\x5c\x00\x5d\x00\x5e\x00\x5f\x00\x60\x00\x61\x00\x62\x00\x63\x00\x64\x00\x65\x00\x66\x00\x67\x00\x68\x00\x69\x00\x6a\x00\x6b\x00\x6c\x00\x6d\x00\x6e\x00\x6f\x00\x70\x00\x71\x00\x72\x00\x73\x00\x74\x00\x75\x00\x76\x00\x77\x00\x78\x00\x79\x00\x7a\x00\x7b\x00\x7c\x00\x7d\x00\x7e\x00\x09\x00\x0a\x00\x0b\x00\x0c\x00\x0d\x00\x0a\x00\x0a\x00\x0a\x00\x0a\x00\x09\x00\x0a\x00\x0b\x00\x0c\x00\x0d\x00\x09\x00\x0a\x00\x0b\x00\x0c\x00\x0d\x00\x0a\x00\x0a\x00\xff\xff\xff\xff\x20\x00\xff\xff\xff\xff\x0a\x00\x09\x00\x0a\x00\x0b\x00\x0c\x00\x0d\x00\x20\x00\xff\xff\xff\xff\xff\xff\x2d\x00\x20\x00\xff\xff\xff\xff\xff\xff\x2d\x00\xff\xff\x22\x00\x22\x00\x2d\x00\xff\xff\xff\xff\xff\xff\xff\xff\x20\x00\xff\xff\xff\xff\x3a\x00\x3a\x00\x3a\x00\x3a\x00\xff\xff\x0a\x00\x0a\x00\x0a\x00\x0a\x00\x2c\x00\x2d\x00\xff\xff\xff\xff\x30\x00\x30\x00\x31\x00\x32\x00\x33\x00\x34\x00\x35\x00\x36\x00\x37\x00\x38\x00\x39\x00\x3d\x00\xff\xff\xff\xff\x3e\x00\xff\xff\xff\xff\x41\x00\x42\x00\x43\x00\x44\x00\x45\x00\x46\x00\x47\x00\x48\x00\x49\x00\x4a\x00\x4b\x00\x4c\x00\x4d\x00\x4e\x00\x4f\x00\x50\x00\x51\x00\x52\x00\x53\x00\x54\x00\x55\x00\x56\x00\x57\x00\x58\x00\x59\x00\x5a\x00\x3d\x00\x3d\x00\x3d\x00\x3d\x00\xff\xff\x7b\x00\x61\x00\x62\x00\x63\x00\x64\x00\x65\x00\x66\x00\x67\x00\x68\x00\x69\x00\x6a\x00\x6b\x00\x6c\x00\x6d\x00\x6e\x00\x6f\x00\x70\x00\x71\x00\x72\x00\x73\x00\x74\x00\x75\x00\x76\x00\x77\x00\x78\x00\x79\x00\x7a\x00\x09\x00\x0a\x00\x0b\x00\x0c\x00\x0d\x00\x09\x00\x0a\x00\x0b\x00\x0c\x00\x0d\x00\x30\x00\x31\x00\x32\x00\x33\x00\x34\x00\x35\x00\x36\x00\x37\x00\x38\x00\x39\x00\xff\xff\xff\xff\xff\xff\x20\x00\xff\xff\xff\xff\xff\xff\xff\xff\x20\x00\xff\xff\x27\x00\x0a\x00\xff\xff\xff\xff\xff\xff\xff\xff\x2d\x00\xff\xff\xff\xff\x30\x00\x31\x00\x32\x00\x33\x00\x34\x00\x35\x00\x36\x00\x37\x00\x38\x00\x39\x00\x3a\x00\xff\xff\xff\xff\xff\xff\xff\xff\x3a\x00\xff\xff\x41\x00\x42\x00\x43\x00\x44\x00\x45\x00\x46\x00\x47\x00\x48\x00\x49\x00\x4a\x00\x4b\x00\x4c\x00\x4d\x00\x4e\x00\x4f\x00\x50\x00\x51\x00\x52\x00\x53\x00\x54\x00\x55\x00\x56\x00\x57\x00\x58\x00\x59\x00\x5a\x00\x3d\x00\xff\xff\xff\xff\xff\xff\x5f\x00\xff\xff\x61\x00\x62\x00\x63\x00\x64\x00\x65\x00\x66\x00\x67\x00\x68\x00\x69\x00\x6a\x00\x6b\x00\x6c\x00\x6d\x00\x6e\x00\x6f\x00\x70\x00\x71\x00\x72\x00\x73\x00\x74\x00\x75\x00\x76\x00\x77\x00\x78\x00\x79\x00\x7a\x00\x09\x00\x0a\x00\x0b\x00\x0c\x00\x0d\x00\x30\x00\x31\x00\x32\x00\x33\x00\x34\x00\x35\x00\x36\x00\x37\x00\x38\x00\x39\x00\x30\x00\x31\x00\x32\x00\x33\x00\x34\x00\x35\x00\x36\x00\x37\x00\x20\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\x27\x00\x09\x00\x0a\x00\x0b\x00\x0c\x00\x0d\x00\x2d\x00\xff\xff\xff\xff\x30\x00\x31\x00\x32\x00\x33\x00\x34\x00\x35\x00\x36\x00\x37\x00\x38\x00\x39\x00\x3a\x00\xff\xff\xff\xff\xff\xff\xff\xff\x20\x00\xff\xff\x41\x00\x42\x00\x43\x00\x44\x00\x45\x00\x46\x00\x47\x00\x48\x00\x49\x00\x4a\x00\x4b\x00\x4c\x00\x4d\x00\x4e\x00\x4f\x00\x50\x00\x51\x00\x52\x00\x53\x00\x54\x00\x55\x00\x56\x00\x57\x00\x58\x00\x59\x00\x5a\x00\xff\xff\x3d\x00\xff\xff\xff\xff\x5f\x00\xff\xff\x61\x00\x62\x00\x63\x00\x64\x00\x65\x00\x66\x00\x67\x00\x68\x00\x69\x00\x6a\x00\x6b\x00\x6c\x00\x6d\x00\x6e\x00\x6f\x00\x70\x00\x71\x00\x72\x00\x73\x00\x74\x00\x75\x00\x76\x00\x77\x00\x78\x00\x79\x00\x7a\x00\x41\x00\x42\x00\x43\x00\x44\x00\x45\x00\x46\x00\x47\x00\x48\x00\x49\x00\x4a\x00\x4b\x00\x4c\x00\x4d\x00\x4e\x00\x4f\x00\x50\x00\x51\x00\x52\x00\x53\x00\x54\x00\x55\x00\x56\x00\x57\x00\x58\x00\x59\x00\x5a\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\x61\x00\x62\x00\x63\x00\x64\x00\x65\x00\x66\x00\x67\x00\x68\x00\x69\x00\x6a\x00\x6b\x00\x6c\x00\x6d\x00\x6e\x00\x6f\x00\x70\x00\x71\x00\x72\x00\x73\x00\x74\x00\x75\x00\x76\x00\x77\x00\x78\x00\x79\x00\x7a\x00\x7b\x00\x20\x00\x21\x00\x22\x00\x23\x00\x24\x00\x25\x00\x26\x00\x27\x00\x28\x00\x29\x00\x2a\x00\x2b\x00\x2c\x00\x2d\x00\x2e\x00\x2f\x00\x30\x00\x31\x00\x32\x00\x33\x00\x34\x00\x35\x00\x36\x00\x37\x00\x38\x00\x39\x00\x3a\x00\x3b\x00\x3c\x00\x3d\x00\x3e\x00\x3f\x00\x40\x00\x41\x00\x42\x00\x43\x00\x44\x00\x45\x00\x46\x00\x47\x00\x48\x00\x49\x00\x4a\x00\x4b\x00\x4c\x00\x4d\x00\x4e\x00\x4f\x00\x50\x00\x51\x00\x52\x00\x53\x00\x54\x00\x55\x00\x56\x00\x57\x00\x58\x00\x59\x00\x5a\x00\x5b\x00\x5c\x00\x5d\x00\x5e\x00\x5f\x00\x60\x00\x61\x00\x62\x00\x63\x00\x64\x00\x65\x00\x66\x00\x67\x00\x68\x00\x69\x00\x6a\x00\x6b\x00\x6c\x00\x6d\x00\x6e\x00\x6f\x00\x70\x00\x71\x00\x72\x00\x73\x00\x74\x00\x75\x00\x76\x00\x77\x00\x78\x00\x79\x00\x7a\x00\x7b\x00\x7c\x00\x7d\x00\x7e\x00\x30\x00\x31\x00\x32\x00\x33\x00\x34\x00\x35\x00\x36\x00\x37\x00\x38\x00\x39\x00\xff\xff\x09\x00\x0a\x00\x0b\x00\x0c\x00\x0d\x00\xff\xff\x41\x00\x42\x00\x43\x00\x44\x00\x45\x00\x46\x00\x30\x00\x31\x00\x32\x00\x33\x00\x34\x00\x35\x00\x36\x00\x37\x00\x38\x00\x39\x00\xff\xff\x20\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\x41\x00\x42\x00\x43\x00\x44\x00\x45\x00\x46\x00\xff\xff\x2d\x00\xff\xff\x61\x00\x62\x00\x63\x00\x64\x00\x65\x00\x66\x00\x30\x00\x31\x00\x32\x00\x33\x00\x34\x00\x35\x00\x36\x00\x37\x00\x3d\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\x61\x00\x62\x00\x63\x00\x64\x00\x65\x00\x66\x00\x41\x00\x42\x00\x43\x00\x44\x00\x45\x00\x46\x00\x47\x00\x48\x00\x49\x00\x4a\x00\x4b\x00\x4c\x00\x4d\x00\x4e\x00\x4f\x00\x50\x00\x51\x00\x52\x00\x53\x00\x54\x00\x55\x00\x56\x00\x57\x00\x58\x00\x59\x00\x5a\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\x61\x00\x62\x00\x63\x00\x64\x00\x65\x00\x66\x00\x67\x00\x68\x00\x69\x00\x6a\x00\x6b\x00\x6c\x00\x6d\x00\x6e\x00\x6f\x00\x70\x00\x71\x00\x72\x00\x73\x00\x74\x00\x75\x00\x76\x00\x77\x00\x78\x00\x79\x00\x7a\x00\x7b\x00\x09\x00\x0a\x00\x0b\x00\x0c\x00\x0d\x00\x30\x00\x31\x00\x32\x00\x33\x00\x34\x00\x35\x00\x36\x00\x37\x00\x38\x00\x39\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\x20\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\x27\x00\x09\x00\x0a\x00\x0b\x00\x0c\x00\x0d\x00\x2d\x00\xff\xff\xff\xff\x30\x00\x31\x00\x32\x00\x33\x00\x34\x00\x35\x00\x36\x00\x37\x00\x38\x00\x39\x00\xff\xff\xff\xff\xff\xff\x3d\x00\xff\xff\x20\x00\xff\xff\x41\x00\x42\x00\x43\x00\x44\x00\x45\x00\x46\x00\x47\x00\x48\x00\x49\x00\x4a\x00\x4b\x00\x4c\x00\x4d\x00\x4e\x00\x4f\x00\x50\x00\x51\x00\x52\x00\x53\x00\x54\x00\x55\x00\x56\x00\x57\x00\x58\x00\x59\x00\x5a\x00\xff\xff\x3d\x00\xff\xff\xff\xff\x5f\x00\xff\xff\x61\x00\x62\x00\x63\x00\x64\x00\x65\x00\x66\x00\x67\x00\x68\x00\x69\x00\x6a\x00\x6b\x00\x6c\x00\x6d\x00\x6e\x00\x6f\x00\x70\x00\x71\x00\x72\x00\x73\x00\x74\x00\x75\x00\x76\x00\x77\x00\x78\x00\x79\x00\x7a\x00\x09\x00\x0a\x00\x0b\x00\x0c\x00\x0d\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\x20\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\x27\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\x2d\x00\xff\xff\xff\xff\x30\x00\x31\x00\x32\x00\x33\x00\x34\x00\x35\x00\x36\x00\x37\x00\x38\x00\x39\x00\xff\xff\xff\xff\xff\xff\x3d\x00\xff\xff\xff\xff\xff\xff\x41\x00\x42\x00\x43\x00\x44\x00\x45\x00\x46\x00\x47\x00\x48\x00\x49\x00\x4a\x00\x4b\x00\x4c\x00\x4d\x00\x4e\x00\x4f\x00\x50\x00\x51\x00\x52\x00\x53\x00\x54\x00\x55\x00\x56\x00\x57\x00\x58\x00\x59\x00\x5a\x00\xff\xff\xff\xff\xff\xff\xff\xff\x5f\x00\xff\xff\x61\x00\x62\x00\x63\x00\x64\x00\x65\x00\x66\x00\x67\x00\x68\x00\x69\x00\x6a\x00\x6b\x00\x6c\x00\x6d\x00\x6e\x00\x6f\x00\x70\x00\x71\x00\x72\x00\x73\x00\x74\x00\x75\x00\x76\x00\x77\x00\x78\x00\x79\x00\x7a\x00\x27\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\x30\x00\x31\x00\x32\x00\x33\x00\x34\x00\x35\x00\x36\x00\x37\x00\x38\x00\x39\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\x41\x00\x42\x00\x43\x00\x44\x00\x45\x00\x46\x00\x47\x00\x48\x00\x49\x00\x4a\x00\x4b\x00\x4c\x00\x4d\x00\x4e\x00\x4f\x00\x50\x00\x51\x00\x52\x00\x53\x00\x54\x00\x55\x00\x56\x00\x57\x00\x58\x00\x59\x00\x5a\x00\xff\xff\xff\xff\xff\xff\xff\xff\x5f\x00\xff\xff\x61\x00\x62\x00\x63\x00\x64\x00\x65\x00\x66\x00\x67\x00\x68\x00\x69\x00\x6a\x00\x6b\x00\x6c\x00\x6d\x00\x6e\x00\x6f\x00\x70\x00\x71\x00\x72\x00\x73\x00\x74\x00\x75\x00\x76\x00\x77\x00\x78\x00\x79\x00\x7a\x00\x27\x00\xff\xff\x7d\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\x30\x00\x31\x00\x32\x00\x33\x00\x34\x00\x35\x00\x36\x00\x37\x00\x38\x00\x39\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\x41\x00\x42\x00\x43\x00\x44\x00\x45\x00\x46\x00\x47\x00\x48\x00\x49\x00\x4a\x00\x4b\x00\x4c\x00\x4d\x00\x4e\x00\x4f\x00\x50\x00\x51\x00\x52\x00\x53\x00\x54\x00\x55\x00\x56\x00\x57\x00\x58\x00\x59\x00\x5a\x00\xff\xff\xff\xff\xff\xff\xff\xff\x5f\x00\xff\xff\x61\x00\x62\x00\x63\x00\x64\x00\x65\x00\x66\x00\x67\x00\x68\x00\x69\x00\x6a\x00\x6b\x00\x6c\x00\x6d\x00\x6e\x00\x6f\x00\x70\x00\x71\x00\x72\x00\x73\x00\x74\x00\x75\x00\x76\x00\x77\x00\x78\x00\x79\x00\x7a\x00\xff\xff\xff\xff\x7d\x00\x41\x00\x42\x00\x43\x00\x44\x00\x45\x00\x46\x00\x47\x00\x48\x00\x49\x00\x4a\x00\x4b\x00\x4c\x00\x4d\x00\x4e\x00\x4f\x00\x50\x00\x51\x00\x52\x00\x53\x00\x54\x00\x55\x00\x56\x00\x57\x00\x58\x00\x59\x00\x5a\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\x61\x00\x62\x00\x63\x00\x64\x00\x65\x00\x66\x00\x67\x00\x68\x00\x69\x00\x6a\x00\x6b\x00\x6c\x00\x6d\x00\x6e\x00\x6f\x00\x70\x00\x71\x00\x72\x00\x73\x00\x74\x00\x75\x00\x76\x00\x77\x00\x78\x00\x79\x00\x7a\x00\x09\x00\x0a\x00\x0b\x00\x0c\x00\x0d\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\x20\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\x27\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\x2d\x00\xff\xff\xff\xff\x30\x00\x31\x00\x32\x00\x33\x00\x34\x00\x35\x00\x36\x00\x37\x00\x38\x00\x39\x00\xff\xff\xff\xff\xff\xff\x3d\x00\xff\xff\xff\xff\xff\xff\x41\x00\x42\x00\x43\x00\x44\x00\x45\x00\x46\x00\x47\x00\x48\x00\x49\x00\x4a\x00\x4b\x00\x4c\x00\x4d\x00\x4e\x00\x4f\x00\x50\x00\x51\x00\x52\x00\x53\x00\x54\x00\x55\x00\x56\x00\x57\x00\x58\x00\x59\x00\x5a\x00\xff\xff\xff\xff\xff\xff\xff\xff\x5f\x00\xff\xff\x61\x00\x62\x00\x63\x00\x64\x00\x65\x00\x66\x00\x67\x00\x68\x00\x69\x00\x6a\x00\x6b\x00\x6c\x00\x6d\x00\x6e\x00\x6f\x00\x70\x00\x71\x00\x72\x00\x73\x00\x74\x00\x75\x00\x76\x00\x77\x00\x78\x00\x79\x00\x7a\x00\x09\x00\x0a\x00\x0b\x00\x0c\x00\x0d\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\x20\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\x27\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\x2d\x00\xff\xff\xff\xff\x30\x00\x31\x00\x32\x00\x33\x00\x34\x00\x35\x00\x36\x00\x37\x00\x38\x00\x39\x00\xff\xff\xff\xff\xff\xff\x3d\x00\xff\xff\xff\xff\xff\xff\x41\x00\x42\x00\x43\x00\x44\x00\x45\x00\x46\x00\x47\x00\x48\x00\x49\x00\x4a\x00\x4b\x00\x4c\x00\x4d\x00\x4e\x00\x4f\x00\x50\x00\x51\x00\x52\x00\x53\x00\x54\x00\x55\x00\x56\x00\x57\x00\x58\x00\x59\x00\x5a\x00\xff\xff\xff\xff\xff\xff\xff\xff\x5f\x00\xff\xff\x61\x00\x62\x00\x63\x00\x64\x00\x65\x00\x66\x00\x67\x00\x68\x00\x69\x00\x6a\x00\x6b\x00\x6c\x00\x6d\x00\x6e\x00\x6f\x00\x70\x00\x71\x00\x72\x00\x73\x00\x74\x00\x75\x00\x76\x00\x77\x00\x78\x00\x79\x00\x7a\x00\x09\x00\x0a\x00\x0b\x00\x0c\x00\x0d\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\x20\x00\xff\xff\xff\xff\xff\xff\xff\xff\x27\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\x2d\x00\x30\x00\x31\x00\x32\x00\x33\x00\x34\x00\x35\x00\x36\x00\x37\x00\x38\x00\x39\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\x3d\x00\xff\xff\x41\x00\x42\x00\x43\x00\x44\x00\x45\x00\x46\x00\x47\x00\x48\x00\x49\x00\x4a\x00\x4b\x00\x4c\x00\x4d\x00\x4e\x00\x4f\x00\x50\x00\x51\x00\x52\x00\x53\x00\x54\x00\x55\x00\x56\x00\x57\x00\x58\x00\x59\x00\x5a\x00\xff\xff\xff\xff\xff\xff\xff\xff\x5f\x00\xff\xff\x61\x00\x62\x00\x63\x00\x64\x00\x65\x00\x66\x00\x67\x00\x68\x00\x69\x00\x6a\x00\x6b\x00\x6c\x00\x6d\x00\x6e\x00\x6f\x00\x70\x00\x71\x00\x72\x00\x73\x00\x74\x00\x75\x00\x76\x00\x77\x00\x78\x00\x79\x00\x7a\x00\x27\x00\xff\xff\x7d\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\x30\x00\x31\x00\x32\x00\x33\x00\x34\x00\x35\x00\x36\x00\x37\x00\x38\x00\x39\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\x41\x00\x42\x00\x43\x00\x44\x00\x45\x00\x46\x00\x47\x00\x48\x00\x49\x00\x4a\x00\x4b\x00\x4c\x00\x4d\x00\x4e\x00\x4f\x00\x50\x00\x51\x00\x52\x00\x53\x00\x54\x00\x55\x00\x56\x00\x57\x00\x58\x00\x59\x00\x5a\x00\xff\xff\xff\xff\xff\xff\xff\xff\x5f\x00\xff\xff\x61\x00\x62\x00\x63\x00\x64\x00\x65\x00\x66\x00\x67\x00\x68\x00\x69\x00\x6a\x00\x6b\x00\x6c\x00\x6d\x00\x6e\x00\x6f\x00\x70\x00\x71\x00\x72\x00\x73\x00\x74\x00\x75\x00\x76\x00\x77\x00\x78\x00\x79\x00\x7a\x00\xff\xff\xff\xff\x7d\x00\x41\x00\x42\x00\x43\x00\x44\x00\x45\x00\x46\x00\x47\x00\x48\x00\x49\x00\x4a\x00\x4b\x00\x4c\x00\x4d\x00\x4e\x00\x4f\x00\x50\x00\x51\x00\x52\x00\x53\x00\x54\x00\x55\x00\x56\x00\x57\x00\x58\x00\x59\x00\x5a\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\x61\x00\x62\x00\x63\x00\x64\x00\x65\x00\x66\x00\x67\x00\x68\x00\x69\x00\x6a\x00\x6b\x00\x6c\x00\x6d\x00\x6e\x00\x6f\x00\x70\x00\x71\x00\x72\x00\x73\x00\x74\x00\x75\x00\x76\x00\x77\x00\x78\x00\x79\x00\x7a\x00\x27\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\x30\x00\x31\x00\x32\x00\x33\x00\x34\x00\x35\x00\x36\x00\x37\x00\x38\x00\x39\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\x41\x00\x42\x00\x43\x00\x44\x00\x45\x00\x46\x00\x47\x00\x48\x00\x49\x00\x4a\x00\x4b\x00\x4c\x00\x4d\x00\x4e\x00\x4f\x00\x50\x00\x51\x00\x52\x00\x53\x00\x54\x00\x55\x00\x56\x00\x57\x00\x58\x00\x59\x00\x5a\x00\xff\xff\xff\xff\xff\xff\xff\xff\x5f\x00\xff\xff\x61\x00\x62\x00\x63\x00\x64\x00\x65\x00\x66\x00\x67\x00\x68\x00\x69\x00\x6a\x00\x6b\x00\x6c\x00\x6d\x00\x6e\x00\x6f\x00\x70\x00\x71\x00\x72\x00\x73\x00\x74\x00\x75\x00\x76\x00\x77\x00\x78\x00\x79\x00\x7a\x00\x27\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\x30\x00\x31\x00\x32\x00\x33\x00\x34\x00\x35\x00\x36\x00\x37\x00\x38\x00\x39\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\x41\x00\x42\x00\x43\x00\x44\x00\x45\x00\x46\x00\x47\x00\x48\x00\x49\x00\x4a\x00\x4b\x00\x4c\x00\x4d\x00\x4e\x00\x4f\x00\x50\x00\x51\x00\x52\x00\x53\x00\x54\x00\x55\x00\x56\x00\x57\x00\x58\x00\x59\x00\x5a\x00\xff\xff\xff\xff\xff\xff\xff\xff\x5f\x00\xff\xff\x61\x00\x62\x00\x63\x00\x64\x00\x65\x00\x66\x00\x67\x00\x68\x00\x69\x00\x6a\x00\x6b\x00\x6c\x00\x6d\x00\x6e\x00\x6f\x00\x70\x00\x71\x00\x72\x00\x73\x00\x74\x00\x75\x00\x76\x00\x77\x00\x78\x00\x79\x00\x7a\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff"# - -alex_deflt :: AlexAddr -alex_deflt = AlexA# "\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\x06\x00\x06\x00\xff\xff\xff\xff\xff\xff\x0b\x00\x0b\x00\xff\xff\x15\x00\xff\xff\x15\x00\xff\xff\xff\xff\xff\xff\xff\xff\x15\x00\x15\x00\xff\xff\xff\xff\x19\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\x3e\x00\xff\xff\x3e\x00\x3e\x00\xff\xff\xff\xff\x44\x00\xff\xff\x44\x00\x44\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\x4c\x00"# - -alex_accept = listArray (0::Int,77) [[],[(AlexAcc (alex_action_21))],[],[],[(AlexAcc (alex_action_0))],[(AlexAcc (alex_action_0))],[(AlexAcc (alex_action_0))],[],[(AlexAcc (alex_action_4))],[(AlexAcc (alex_action_1))],[(AlexAcc (alex_action_10))],[],[(AlexAcc (alex_action_2))],[(AlexAcc (alex_action_2))],[],[],[(AlexAcc (alex_action_10))],[(AlexAcc (alex_action_10))],[],[],[],[],[],[(AlexAccPred (alex_action_3) (alexRightContext 24)),(AlexAcc (alex_action_4))],[],[(AlexAccSkip)],[(AlexAcc (alex_action_4))],[(AlexAcc (alex_action_4))],[(AlexAcc (alex_action_5))],[],[],[],[],[],[],[],[(AlexAcc (alex_action_6))],[(AlexAcc (alex_action_6))],[(AlexAcc (alex_action_10))],[(AlexAcc (alex_action_7))],[(AlexAcc (alex_action_9))],[(AlexAcc (alex_action_8))],[(AlexAcc (alex_action_9))],[(AlexAcc (alex_action_9))],[(AlexAcc (alex_action_10))],[(AlexAcc (alex_action_10))],[(AlexAcc (alex_action_11))],[(AlexAcc (alex_action_11))],[(AlexAcc (alex_action_11))],[],[],[],[(AlexAcc (alex_action_12))],[(AlexAcc (alex_action_12))],[(AlexAcc (alex_action_12))],[],[],[],[(AlexAcc (alex_action_13))],[(AlexAcc (alex_action_13))],[],[],[],[],[(AlexAcc (alex_action_14))],[(AlexAcc (alex_action_14))],[],[],[],[],[(AlexAcc (alex_action_15))],[(AlexAcc (alex_action_16))],[(AlexAcc (alex_action_17))],[(AlexAcc (alex_action_17))],[(AlexAcc (alex_action_18))],[(AlexAcc (alex_action_19))],[(AlexAcc (alex_action_20))],[]] -{-# LINE 73 "src/Scan.x" #-} - --- ----------------------------------------------------------------------------- --- Token type - -data Token = T AlexPosn Tkn - deriving Show - -tokPosn (T p _) = p - -data Tkn - = SpecialT Char - | CodeT String - | ZeroT - | IdT String - | StringT String - | BindT String - | CharT Char - | SMacT String - | RMacT String - | SMacDefT String - | RMacDefT String - | NumT Int - | WrapperT - | EOFT - deriving Show - --- ----------------------------------------------------------------------------- --- Token functions - -special (p,_,str) ln = return $ T p (SpecialT (head str)) -zero (p,_,str) ln = return $ T p ZeroT -string (p,_,str) ln = return $ T p (StringT (extract ln str)) -bind (p,_,str) ln = return $ T p (BindT (takeWhile isIdChar str)) -escape (p,_,str) ln = return $ T p (CharT (esc str)) -decch (p,_,str) ln = return $ T p (CharT (do_ech 10 ln (take (ln-1) (tail str)))) -hexch (p,_,str) ln = return $ T p (CharT (do_ech 16 ln (take (ln-2) (drop 2 str)))) -octch (p,_,str) ln = return $ T p (CharT (do_ech 8 ln (take (ln-2) (drop 2 str)))) -char (p,_,str) ln = return $ T p (CharT (head str)) -smac (p,_,str) ln = return $ T p (SMacT (mac ln str)) -rmac (p,_,str) ln = return $ T p (RMacT (mac ln str)) -smacdef (p,_,str) ln = return $ T p (SMacDefT (macdef ln str)) -rmacdef (p,_,str) ln = return $ T p (RMacDefT (macdef ln str)) -startcode (p,_,str) ln = return $ T p (IdT (take ln str)) -wrapper (p,_,str) ln = return $ T p WrapperT - -isIdChar c = isAlphaNum c || c `elem` "_'" - -extract ln str = take (ln-2) (tail str) - -do_ech radix ln str = chr (parseInt radix str) - -mac ln (_ : str) = take (ln-1) str - -macdef ln (_ : str) = takeWhile (not.isSpace) str - -esc (_ : x : _) = - case x of - 'a' -> '\a' - 'b' -> '\b' - 'f' -> '\f' - 'n' -> '\n' - 'r' -> '\r' - 't' -> '\t' - 'v' -> '\v' - c -> c - -parseInt :: Int -> String -> Int -parseInt radix ds = foldl1 (\n d -> n * radix + d) (map digitToInt ds) - --- In brace-delimited code, we have to be careful to match braces --- within the code, but ignore braces inside strings and character --- literals. We do an approximate job (doing it properly requires --- implementing a large chunk of the Haskell lexical syntax). - -code (p,_,inp) len = do - inp <- getInput - go inp 1 "" - where - go inp 0 cs = do - setInput inp - return (T p (CodeT (reverse (tail cs)))) - go inp n cs = do - case alexGetChar inp of - Nothing -> err inp - Just (c,inp) -> - case c of - '{' -> go inp (n+1) (c:cs) - '}' -> go inp (n-1) (c:cs) - '\'' -> go_char inp n (c:cs) - '\"' -> go_str inp n (c:cs) '\"' - c -> go inp n (c:cs) - - -- try to catch occurrences of ' within an identifier - go_char inp n (c1:c2:cs) | isAlphaNum c2 = go inp n (c1:c2:cs) - go_char inp n cs = go_str inp n cs '\'' - - go_str inp n cs end = do - case alexGetChar inp of - Nothing -> err inp - Just (c,inp) - | c == end -> go inp n (c:cs) - | otherwise -> - case c of - '\\' -> case alexGetChar inp of - Nothing -> err inp - Just (d,inp) -> go_str inp n (d:c:cs) end - c -> go_str inp n (c:cs) end - - err inp = do setInput inp; lexError "lexical error in code fragment" - - - -lexError s = do - (p,_,input) <- getInput - failP (s ++ (if (not (null input)) - then " at " ++ show (head input) - else " at end of file")) - -lexer :: (Token -> P a) -> P a -lexer cont = lexToken >>= cont - -lexToken :: P Token -lexToken = do - inp@(p,_,_) <- getInput - sc <- getStartCode - case alexScan inp sc of - AlexEOF -> return (T p EOFT) - AlexError _ -> lexError "lexical error" - AlexSkip inp1 len -> do - setInput inp1 - lexToken - AlexToken inp1 len t -> do - setInput inp1 - t inp len - -type Action = AlexInput -> Int -> P Token - -skip :: Action -skip _ _ = lexToken - -andBegin :: Action -> StartCode -> Action -andBegin act sc inp len = setStartCode sc >> act inp len - - -afterstartcodes,startcodes :: Int -afterstartcodes = 1 -startcodes = 2 -alex_action_0 = skip -alex_action_1 = string -alex_action_2 = bind -alex_action_3 = code -alex_action_4 = special -alex_action_5 = wrapper -alex_action_6 = decch -alex_action_7 = hexch -alex_action_8 = octch -alex_action_9 = escape -alex_action_10 = char -alex_action_11 = smac -alex_action_12 = rmac -alex_action_13 = smacdef -alex_action_14 = rmacdef -alex_action_15 = special `andBegin` startcodes -alex_action_16 = zero -alex_action_17 = startcode -alex_action_18 = special -alex_action_19 = special `andBegin` afterstartcodes -alex_action_20 = special `andBegin` 0 -alex_action_21 = skip `andBegin` 0 -{-# LINE 1 "GenericTemplate.hs" #-} -{-# LINE 1 "" #-} -{-# LINE 1 "" #-} -{-# LINE 1 "GenericTemplate.hs" #-} --- ----------------------------------------------------------------------------- --- ALEX TEMPLATE --- --- This code is in the PUBLIC DOMAIN; you may copy it freely and use --- it for any purpose whatsoever. - --- ----------------------------------------------------------------------------- --- INTERNALS and main scanner engine - -{-# LINE 35 "GenericTemplate.hs" #-} - -{-# LINE 45 "GenericTemplate.hs" #-} - - -data AlexAddr = AlexA# Addr# - -#if __GLASGOW_HASKELL__ < 503 -uncheckedShiftL# = shiftL# -#endif - -{-# INLINE alexIndexInt16OffAddr #-} -alexIndexInt16OffAddr (AlexA# arr) off = -#ifdef WORDS_BIGENDIAN - narrow16Int# i - where - i = word2Int# ((high `uncheckedShiftL#` 8#) `or#` low) - high = int2Word# (ord# (indexCharOffAddr# arr (off' +# 1#))) - low = int2Word# (ord# (indexCharOffAddr# arr off')) - off' = off *# 2# -#else - indexInt16OffAddr# arr off -#endif - - - - - -{-# INLINE alexIndexInt32OffAddr #-} -alexIndexInt32OffAddr (AlexA# arr) off = -#ifdef WORDS_BIGENDIAN - narrow32Int# i - where - i = word2Int# ((b3 `uncheckedShiftL#` 24#) `or#` - (b2 `uncheckedShiftL#` 16#) `or#` - (b1 `uncheckedShiftL#` 8#) `or#` b0) - b3 = int2Word# (ord# (indexCharOffAddr# arr (off' +# 3#))) - b2 = int2Word# (ord# (indexCharOffAddr# arr (off' +# 2#))) - b1 = int2Word# (ord# (indexCharOffAddr# arr (off' +# 1#))) - b0 = int2Word# (ord# (indexCharOffAddr# arr off')) - off' = off *# 4# -#else - indexInt32OffAddr# arr off -#endif - - - - - -#if __GLASGOW_HASKELL__ < 503 -quickIndex arr i = arr ! i -#else --- GHC >= 503, unsafeAt is available from Data.Array.Base. -quickIndex = unsafeAt -#endif - - - - --- ----------------------------------------------------------------------------- --- Main lexing routines - -data AlexReturn a - = AlexEOF - | AlexError !AlexInput - | AlexSkip !AlexInput !Int - | AlexToken !AlexInput !Int a - --- alexScan :: AlexInput -> StartCode -> AlexReturn a -alexScan input (I# (sc)) - = alexScanUser undefined input (I# (sc)) - -alexScanUser user input (I# (sc)) - = case alex_scan_tkn user input 0# input sc AlexNone of - (AlexNone, input') -> - case alexGetChar input of - Nothing -> - - - - AlexEOF - Just _ -> - - - - AlexError input' - - (AlexLastSkip input len, _) -> - - - - AlexSkip input len - - (AlexLastAcc k input len, _) -> - - - - AlexToken input len k - - --- Push the input through the DFA, remembering the most recent accepting --- state it encountered. - -alex_scan_tkn user orig_input len input s last_acc = - input `seq` -- strict in the input - let - new_acc = check_accs (alex_accept `quickIndex` (I# (s))) - in - new_acc `seq` - case alexGetChar input of - Nothing -> (new_acc, input) - Just (c, new_input) -> - - - - let - base = alexIndexInt32OffAddr alex_base s - (I# (ord_c)) = ord c - offset = (base +# ord_c) - check = alexIndexInt16OffAddr alex_check offset - - new_s = if (offset >=# 0#) && (check ==# ord_c) - then alexIndexInt16OffAddr alex_table offset - else alexIndexInt16OffAddr alex_deflt s - in - case new_s of - -1# -> (new_acc, input) - -- on an error, we want to keep the input *before* the - -- character that failed, not after. - _ -> alex_scan_tkn user orig_input (len +# 1#) - new_input new_s new_acc - - where - check_accs [] = last_acc - check_accs (AlexAcc a : _) = AlexLastAcc a input (I# (len)) - check_accs (AlexAccSkip : _) = AlexLastSkip input (I# (len)) - check_accs (AlexAccPred a pred : rest) - | pred user orig_input (I# (len)) input - = AlexLastAcc a input (I# (len)) - check_accs (AlexAccSkipPred pred : rest) - | pred user orig_input (I# (len)) input - = AlexLastSkip input (I# (len)) - check_accs (_ : rest) = check_accs rest - -data AlexLastAcc a - = AlexNone - | AlexLastAcc a !AlexInput !Int - | AlexLastSkip !AlexInput !Int - -data AlexAcc a user - = AlexAcc a - | AlexAccSkip - | AlexAccPred a (AlexAccPred user) - | AlexAccSkipPred (AlexAccPred user) - -type AlexAccPred user = user -> AlexInput -> Int -> AlexInput -> Bool - --- ----------------------------------------------------------------------------- --- Predicates on a rule - -alexAndPred p1 p2 user in1 len in2 - = p1 user in1 len in2 && p2 user in1 len in2 - ---alexPrevCharIsPred :: Char -> AlexAccPred _ -alexPrevCharIs c _ input _ _ = c == alexInputPrevChar input - ---alexPrevCharIsOneOfPred :: Array Char Bool -> AlexAccPred _ -alexPrevCharIsOneOf arr _ input _ _ = arr ! alexInputPrevChar input - ---alexRightContext :: Int -> AlexAccPred _ -alexRightContext (I# (sc)) user _ _ input = - case alex_scan_tkn user input 0# input sc AlexNone of - (AlexNone, _) -> False - _ -> True - -- TODO: there's no need to find the longest - -- match when checking the right context, just - -- the first match will do. - --- used by wrappers -iUnbox (I# (i)) = i rmfile ./src/Scan.hs hunk ./templates/GenericTemplate.hs 12 -#define IBOX(n) (I# (n)) -#define FAST_INT Int# -#define LT(n,m) (n <# m) -#define GTE(n,m) (n >=# m) -#define EQ(n,m) (n ==# m) -#define PLUS(n,m) (n +# m) -#define MINUS(n,m) (n -# m) -#define TIMES(n,m) (n *# m) -#define NEGATE(n) (negateInt# (n)) +#define IBOX(n) (AlexGHCExts.I# (n)) +#define IUNBOX(n) (case (n) of AlexGHCExts.I# alexX -> alexX) +#define FAST_INT AlexGHCExts.Int# +#define LT(n,m) (n AlexGHCExts.<# m) +#define GTE(n,m) (n AlexGHCExts.>=# m) +#define EQ(n,m) (n AlexGHCExts.==# m) +#define PLUS(n,m) (n AlexGHCExts.+# m) +#define MINUS(n,m) (n AlexGHCExts.-# m) +#define TIMES(n,m) (n AlexGHCExts.*# m) +#define NEGATE(n) (AlexGHCExts.negateInt# (n)) hunk ./templates/GenericTemplate.hs 47 +alexSafeIndex arr i = arr AlexArray.! i hunk ./templates/GenericTemplate.hs 49 -data AlexAddr = AlexA# Addr# +ALEX_IF_GHC_LT_503 +alexQuickIndex arr i = arr `alexSafeIndex` i +ALEX_ELSE +-- GHC >= 503, unsafeAt is available from Data.Array.Base. +alexQuickIndex = AlexArrayBase.unsafeAt +ALEX_ENDIF +#else +alexQuickIndex arr i = arr `alexSafeIndex` i +#endif + +#ifdef ALEX_GHC +data AlexAddr = AlexA# AlexGHCExts.Addr# hunk ./templates/GenericTemplate.hs 63 -uncheckedShiftL# = shiftL# +alexUncheckedShiftL = AlexGHCExts.shiftL +ALEX_ELSE +alexUncheckedShiftL = AlexGHCExts.uncheckedShiftL# hunk ./templates/GenericTemplate.hs 71 - narrow16Int# i + AlexGHCExts.narrow16Int# i hunk ./templates/GenericTemplate.hs 73 - i = word2Int# ((high `uncheckedShiftL#` 8#) `or#` low) - high = int2Word# (ord# (indexCharOffAddr# arr (off' +# 1#))) - low = int2Word# (ord# (indexCharOffAddr# arr off')) - off' = off *# 2# + i = AlexGHCExts.word2Int# ((high `alexUncheckedShiftL` 8#) `AlexGHCExts.or#` low) + high = AlexGHCExts.int2Word# (AlexGHCExts.ord# (AlexGHCExts.indexCharOffAddr# arr (off' AlexGHCExts.+# 1#))) + low = AlexGHCExts.int2Word# (AlexGHCExts.ord# (AlexGHCExts.indexCharOffAddr# arr off')) + off' = off AlexGHCExts.*# 2# hunk ./templates/GenericTemplate.hs 78 - indexInt16OffAddr# arr off + AlexGHCExts.indexInt16OffAddr# arr off hunk ./templates/GenericTemplate.hs 81 -alexIndexInt16OffAddr arr off = arr ! off +alexIndexInt16OffAddr arr off = arr `alexQuickIndex` off hunk ./templates/GenericTemplate.hs 88 - narrow32Int# i + AlexGHCExts.narrow32Int# i hunk ./templates/GenericTemplate.hs 90 - i = word2Int# ((b3 `uncheckedShiftL#` 24#) `or#` - (b2 `uncheckedShiftL#` 16#) `or#` - (b1 `uncheckedShiftL#` 8#) `or#` b0) - b3 = int2Word# (ord# (indexCharOffAddr# arr (off' +# 3#))) - b2 = int2Word# (ord# (indexCharOffAddr# arr (off' +# 2#))) - b1 = int2Word# (ord# (indexCharOffAddr# arr (off' +# 1#))) - b0 = int2Word# (ord# (indexCharOffAddr# arr off')) - off' = off *# 4# + i = AlexGHCExts.word2Int# ((b3 `alexUncheckedShiftL` 24#) `AlexGHCExts.or#` + (b2 `alexUncheckedShiftL` 16#) `AlexGHCExts.or#` + (b1 `alexUncheckedShiftL` 8#) `AlexGHCExts.or#` b0) + b3 = AlexGHCExts.int2Word# (AlexGHCExts.ord# (AlexGHCExts.indexCharOffAddr# arr (off' AlexGHCExts.+# 3#))) + b2 = AlexGHCExts.int2Word# (AlexGHCExts.ord# (AlexGHCExts.indexCharOffAddr# arr (off' AlexGHCExts.+# 2#))) + b1 = AlexGHCExts.int2Word# (AlexGHCExts.ord# (AlexGHCExts.indexCharOffAddr# arr (off' AlexGHCExts.+# 1#))) + b0 = AlexGHCExts.int2Word# (AlexGHCExts.ord# (AlexGHCExts.indexCharOffAddr# arr off')) + off' = off AlexGHCExts.*# 4# hunk ./templates/GenericTemplate.hs 99 - indexInt32OffAddr# arr off -ALEX_ENDIF -#else -alexIndexInt32OffAddr arr off = arr ! off -#endif - -#ifdef ALEX_GHC -ALEX_IF_GHC_LT_503 -quickIndex arr i = arr ! i -ALEX_ELSE --- GHC >= 503, unsafeAt is available from Data.Array.Base. -quickIndex = unsafeAt + AlexGHCExts.indexInt32OffAddr# arr off hunk ./templates/GenericTemplate.hs 102 -quickIndex arr i = arr ! i +alexIndexInt32OffAddr arr off = arr `alexQuickIndex` off hunk ./templates/GenericTemplate.hs 124 - trace ("End of input.") $ + AlexDebug.trace ("End of input.") $ hunk ./templates/GenericTemplate.hs 129 - trace ("Error.") $ + AlexDebug.trace ("Error.") $ hunk ./templates/GenericTemplate.hs 135 - trace ("Skipping.") $ + AlexDebug.trace ("Skipping.") $ hunk ./templates/GenericTemplate.hs 141 - trace ("Accept.") $ + AlexDebug.trace ("Accept.") $ hunk ./templates/GenericTemplate.hs 152 - new_acc = check_accs (alex_accept `quickIndex` IBOX(s)) + new_acc = check_accs (alex_accept `alexQuickIndex` IBOX(s)) hunk ./templates/GenericTemplate.hs 159 - trace ("State: " ++ show IBOX(s) ++ ", char: " ++ show c) $ + AlexDebug.trace ("State: " ++ show IBOX(s) ++ ", char: " ++ show c) $ hunk ./templates/GenericTemplate.hs 163 - IBOX(ord_c) = ord c + IBOX(ord_c) = AlexChar.ord c hunk ./templates/GenericTemplate.hs 213 -alexPrevCharIsOneOf arr _ input _ _ = arr ! alexInputPrevChar input +alexPrevCharIsOneOf arr _ input _ _ = arr `alexSafeIndex` alexInputPrevChar input hunk ./templates/GenericTemplate.hs 224 --- used by wrappers -iUnbox IBOX(i) = i } Context: [Use configurations to allow to build with old ghc, but requires new cabal Duncan Coutts **20070906183845 Also update Setup.lhs, again requires new cabal, but much simplified. ] [Install LICENSE in the correct place sven.panne@aedion.de**20070902120038] [Guess what? Fixed Cabal-induced breakage (in a totally wrong way) sven.panne@aedion.de**20070902114446 Tired of trying to find out how to do this correctly and backwards compatible, I've hardwired things to GHC and the Cabal-of-the-day. ] [We depend on array, containers and directory nowadays sven.panne@aedion.de**20070902114409] [Add category: Development to .cabal file Duncan Coutts **20070831112158 Otherwise it appears on the hackage website in the "Unclassified" category. ] [Handle Cabal API changes regarding hooks sven.panne@aedion.de**20070623180848] [Manpage should call file location DATADIR rather than LIBDIR Ian Lynagh **20070622000203] [don't gobble up the first character of a code fragment Simon Marlow **20070619095806] [Patch the Setup.lhs to work with the latest version of Cabal - things have changed to returning IO (), not IO ExitCode Neil Mitchell**20070613072344] [Typo spotted by Helmut Grohne: appriate -> appropriate Ian Lynagh **20070417122330] [fix for using generated code with !GHC Simon Marlow **20070417075855] [Add new ByteString wrappers Duncan Coutts **20070112120814 Wrappers for basic-bytestring, posn-bytestring and monad-bytestring Just like the ordinary ones but taking a lazy ByteString rather than a String as input. Required one change in the order in the generated code (in Main.hs), this is because the ByteString wrappers need to use an extra import which of course has to come at the top of the generated module, so we have to output the wrapper earlier than we did before. ] [add script for building the Windows dist Simon Marlow **20070109134817] [move release notes into docs Simon Marlow **20070108155312] [announce for 2.1.0 Simon Marlow **20070108152640] [TAG 2.1.0 RC Simon Marlow **20061024124241] Patch bundle hash: 188c4e2ccd02443cdd071510dee856ad6da8ad83 From agl at imperialviolet.org Thu Jan 17 10:27:12 2008 From: agl at imperialviolet.org (Adam Langley) Date: Thu Jan 17 10:27:14 2008 Subject: GHC options in Cabal In-Reply-To: <478F5D5A.9070400@iee.org> References: <478F5D5A.9070400@iee.org> Message-ID: <396556a20801170727o69175421pfa7a52becab4993e@mail.gmail.com> On Jan 17, 2008 5:51 AM, Adrian Hey wrote: > IOW, if I already have.. > ghc-options: -O2 As an aside, I believe that -O2 in ghc-options is considered poor form because cabal handles the -O options itself (so that --disable-optimization and friends work). There's a trac ticket to write a patch to warn about this, which I did at some point but, come to think of it, never heard about it again. Oh well, AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org 650-283-9641 From Christian.Maeder at dfki.de Thu Jan 17 10:31:40 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Thu Jan 17 10:31:46 2008 Subject: Proposal: Add split and splitWith (trac #2048) In-Reply-To: <20080117003755.GM4629@scytale.galois.com> References: <478E8C95.7020500@gmail.com> <20080117000025.GA27886@matrix.chaos.earth.li> <478E9CFC.5080607@gmail.com> <404396ef0801161632s6d54164aw494df189f6549b0d@mail.gmail.com> <20080117003755.GM4629@scytale.galois.com> Message-ID: <478F74DC.90608@dfki.de> Don Stewart wrote: > Note here the funniness of lines, complicates the properties: > > prop_linessplit xs = > lines xs == split '\n' xs ++ (if last xs == '\n' then [empty] else []) This property is wrong (i.e. for xs == "\n") > What properties relating to current List functoins does this split have? Data.ByteString.Char8.split only behaves differently to the proposed Data.List.split function on empty input lists. (as Twan showed) last xs == '\n' ==> lines xs == Data.List.split '\n' (init xs) Christian From Christian.Maeder at dfki.de Thu Jan 17 10:51:47 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Thu Jan 17 10:51:51 2008 Subject: Proposal: Add split and splitWith (trac #2048) In-Reply-To: <478F74DC.90608@dfki.de> References: <478E8C95.7020500@gmail.com> <20080117000025.GA27886@matrix.chaos.earth.li> <478E9CFC.5080607@gmail.com> <404396ef0801161632s6d54164aw494df189f6549b0d@mail.gmail.com> <20080117003755.GM4629@scytale.galois.com> <478F74DC.90608@dfki.de> Message-ID: <478F7993.3040208@dfki.de> Christian Maeder wrote: > Don Stewart wrote: >> Note here the funniness of lines, complicates the properties: [...] > Data.ByteString.Char8.split only behaves differently to the proposed > Data.List.split function on empty input lists. (as Twan showed) > > last xs == '\n' ==> > lines xs == Data.List.split '\n' (init xs) This property would be wrong for Data.ByteString.Char8.split and "\n". If we ignore the empty input (which is trivial) the following remaining property case is: not (null xs) && last xs /= '\n' ==> Data.List.split '\n' xs = lines (xs ++ "\n") which is true also for Data.ByteString.Char8.split Christian From Christian.Maeder at dfki.de Thu Jan 17 11:36:07 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Thu Jan 17 11:36:12 2008 Subject: Proposal: Add split and splitWith (trac #2048) In-Reply-To: <20080117000025.GA27886@matrix.chaos.earth.li> References: <478E8C95.7020500@gmail.com> <20080117000025.GA27886@matrix.chaos.earth.li> Message-ID: <478F83F7.6080104@dfki.de> Ian Lynagh wrote: > One or the other should be changed so that these agree: > > *Main> split 'a' "" > [""] > *Main> Data.ByteString.Char8.split 'a' (Data.ByteString.Char8.pack "") > Loading package array-0.1.0.0 ... linking ... done. > Loading package bytestring-0.9.0.1 ... linking ... done. > [] > > although I couldn't say which is "right" OTTOMH... I've convinced myself (see my previous mails) that Twan's version is right and Data.ByteString.Char8.split should be changed (and all its usages need to be checked)! The documentation in both modules should contain the example! split c [] == [[]] I don't think that the oddity of Data.ByteString.Char8.split on empty input helps to establish the treatment of a missing final newline for the lines function. Christian From gale at sefer.org Thu Jan 17 11:52:34 2008 From: gale at sefer.org (Yitzchak Gale) Date: Thu Jan 17 11:52:38 2008 Subject: Integrating editline with ghc In-Reply-To: <478F57B8.8060806@charter.net> References: <6d74b0d20801161305na9e0732m2a6bae7098ec531d@mail.gmail.com> <478F1DB8.1080807@dfki.de> <2608b8a80801170508o3960c268o720a20350d433907@mail.gmail.com> <478F57B8.8060806@charter.net> Message-ID: <2608b8a80801170852u388fce28vea5af7eb6b6ba628@mail.gmail.com> Isaac Dupree wrote: > GHC is in no legal trouble whatsoever... only if proprietary Haskell > code uses the readline library and doesn't switch to using the editline > backend. Agreed. I didn't mean that GHC itself was ever in any legal trouble. But as a compiler, it must be possible for users to compile with it without getting into legal trouble. > On Linux here I have readline installed and not editline > currently, so it seems silly to require installing editline by default > ("default" meaning "if I don't want to, I have to figure out the right > configure flag to give to allow readline to be used"). It makes sense > to use editline by default for Mac and Windows builds though, where > readline isn't native, I guess. Statically linking to editline for > binary builds would be alright (not exporting any readline to > ghc-compiled programs by default?). How is "Search for editline first; > if not found, try to use readline"? Yes, I also have a Debian box, and I agree. Regards, Yitz From dons at galois.com Thu Jan 17 11:54:54 2008 From: dons at galois.com (Don Stewart) Date: Thu Jan 17 11:55:10 2008 Subject: Announcing: HsDNS Version 1.1 Available For Download In-Reply-To: <87ir1s4sa5.fsf@write-only.cryp.to> References: <871w8g6aib.fsf@write-only.cryp.to> <1200566179.5639.173.camel@localhost> <87ir1s4sa5.fsf@write-only.cryp.to> Message-ID: <20080117165454.GB10397@scytale.galois.com> simons: > Duncan Coutts writes: > > > Will we see this on hackage? > > > > The current hackage version is 1.0: > > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hsdns-1.0 > > Unfortunately, I cannot update the entry at the moment because I > don't remember my Hackage login and password; and the machine on > which that information is stored is temporarily unavailable. I'll do > the update as soon as possible, though. Thank you for reminding me. Ping Ross Patterson if you'd like your password reset. -- Don From gale at sefer.org Thu Jan 17 12:20:30 2008 From: gale at sefer.org (Yitzchak Gale) Date: Thu Jan 17 12:20:33 2008 Subject: Integrating editline with ghc In-Reply-To: <478F5F90.1030804@dfki.de> References: <6d74b0d20801161305na9e0732m2a6bae7098ec531d@mail.gmail.com> <478F1DB8.1080807@dfki.de> <2608b8a80801170508o3960c268o720a20350d433907@mail.gmail.com> <478F5F90.1030804@dfki.de> Message-ID: <2608b8a80801170920g5c537aebi66616fcd312a310e@mail.gmail.com> Christian Maeder wrote: > ghc will link to "libedit" if it is available on your platform, but the > Haskell package will still have the name "readline" and give ghc all the > functionality it needs (without licence problems). > Only the current readline Haskell package needs "libreadline" and > supplies more functionality than needed by ghc. This extra-functionality > should go into a new Haskell package readline-ext (that will only be > rarely needed). That is one possible solution for GHC. The problem is that the readline package currently provides System.Console.Readline with the full interface to readline. It has been that way for eons, so we must assume that there is software out there that uses all of it, even though ghc only uses part of it. We don't want to break those programs, and that includes creating a situation where the programs will no longer compile unless the user installs some new package with a different name. So I think the package named "readline" needs to continue to provide both the interface and the implementation for full readline. However, if needed, it can provide some or all of the pieces vacuously by simply depending on some new packages. On the other hand, GHC should depend only on a subset of readline that can optionally be provided by editline instead. And in fact, editline should be preferred over readline when available. There should be a smooth upgrade path to the new system for all users, both of GHC and the readline, for any combination of versions installed of any of those things. Everything should happen automatically as people gradually upgrade GHC and/or various readline-like packages to new versions. Can we meet all of those goals? Thanks, Yitz From judah.jacobson at gmail.com Thu Jan 17 12:22:06 2008 From: judah.jacobson at gmail.com (Judah Jacobson) Date: Thu Jan 17 12:22:08 2008 Subject: Integrating editline with ghc In-Reply-To: <478F5F90.1030804@dfki.de> References: <6d74b0d20801161305na9e0732m2a6bae7098ec531d@mail.gmail.com> <478F1DB8.1080807@dfki.de> <2608b8a80801170508o3960c268o720a20350d433907@mail.gmail.com> <478F5F90.1030804@dfki.de> Message-ID: <6d74b0d20801170922u2e1122a8k94d0186c04364efe@mail.gmail.com> On Jan 17, 2008 6:00 AM, Christian Maeder wrote: > > Yitzchak Gale wrote: > > Christian Maeder wrote: > >> The extended packages "2" could go under extra libs or hackageDB, while > >> "1" remains a boot package for ghc that can link to editline on macs > >> and readline under linux, but has the same interface and package name! > > > > I would hope that ghc will link to editline-ext on all platforms. > > That gives ghc the functionality it needs without getting > > into legal trouble with the license. Then those who want the full > > readline interface can install readline-ext, and those who > > want the full editline interface can install editline. > > Just to clarify: > > ghc will link to "libedit" if it is available on your platform, but the > Haskell package will still have the name "readline" and give ghc all the > functionality it needs (without licence problems). > > Only the current readline Haskell package needs "libreadline" and > supplies more functionality than needed by ghc. This extra-functionality > should go into a new Haskell package readline-ext (that will only be > rarely needed). > > The haskell package "editline-ext" is just an add-on that _requires_ > "libedit" (an is only needed for special future developments). > > Also editline-ext should only be used rarely, because some installation > will still only have "libreadline". > > The new haskell package "readline" will only contain the common > functionality of libedit and libreadline! > > The new haskell package "readline" should not be renamed in order to > achieve best backward compatibility in most cases. Renaming it (i.e. to > "editline") would not change the possibility to either link to libedit > _or_ libreadline (but would require to change all packages that > currently use readline) This sounds fine, except I don't think that we should have a package editline-ext. A readline API is either in both libedit and libreadline (in which case it should be in the readline package), or it is only in libreadline (in which case it should be in readline-ext). The functions in System.Console.Editline are unrelated to the readline APIs; I think that they should just go in a package called "editline". -Judah From bulat.ziganshin at gmail.com Thu Jan 17 12:18:24 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Thu Jan 17 12:23:05 2008 Subject: Proposal: hands off the base! :) In-Reply-To: <478E8C95.7020500@gmail.com> References: <478E8C95.7020500@gmail.com> Message-ID: <295830643.20080117201824@gmail.com> Hello Twan, Thursday, January 17, 2008, 2:00:37 AM, you wrote: > An often requested function is 'split', to split a list into parts delimited by > some separator. ByteString has the functions split and splitWith for this > purpose. I propose we add equivalents to Data.List: one more proposal to ruin all the programs that define this function themselves. i wonder whether all who propose to add function or two ever seen MissingH package? it includes a lot of such popular functions and anyone who needs them can install this package (or just borrow code) i make a contra-proposal - fix base library in 6.8 state and add to ghc distribution new libs with all the popular Monad, List and any other functions. this will allow: 1) precisely control which functions are available by importing exact versions of all libs (except of base which anyway will be frozen) 2) use all the new functions regardless of ghc version you are using. otherwise, adding `split` function to the base actually means that noone except for core hackers can use it for a year - because all these changes in base will go in production GHC version at the end of 2008 and because using user-defined split function will automatically make program incompatible with next GHC version overall, i want to use GHC for production, open-source programming and can formalize requirements which will allow to do this: 1) frozen base library interface, except for GHC.* modules 2) if we want to improve some base code, we *duplicate* it into new lib (with modified module names), publish first version of this libarry with exactly original code (and therefore equivalent interfaces) and then start to improve it, publishing newer and newer versions. imagine, for example, that we want to improve Data.Array.*: step 1: create library NewArray with modules Data.NewArray.* copied one-to-one from Data.Array.* and publish it as version 1 step 2: raise NewArray version to 2.0 and start making changes. once we've finished, raise version to 3.0 and keep interfaces for 3.* intact so anyone can import NewArray 3.* and got latest version with exactly the same interface as he used yes, this means that every functionality improved against the base package, should be installed in two versions - one inside base one in new package. but this is very natural taking into account that we can't change base without breaking all the code that relies on it. so, if we want new arrays, Handles or Exceptions - we will need to keep old version in base and add new one in other lib. overall, it should be recommended to not import directly anything from base but use separate libraries instead 3) GHC distribution should include all the popular libs (which, at the last end, should terminate rushes to include "popular functions" into the base!) with *MULTIPLE* versions - i.e. last 1.* version of NewArray, last 2.* version and so on. this will ensure that program developed in year 2007, will continue to compile with newest ghc versions in 2008, 2009 and so on. we can drop library from ghc distribution after, say, 3 years. i also propose that Haskell' ccommittee will decide every year which libs to include into Haskell standard libs set with exact major version. for example: year 2007: BS 1.*, Collections 2.*, HDBC 1.* year 2008: BS 2.*, Collections 2.*, HSQL 1.* year 2009: BS 2.*, Collections 2.*, HSQL 2.* ghc-2009 should include std libs from last 3 years, i.e. BS 1.*/2.*, Collections 2.*, HDBC 1.*, HSQL 1.*/2.* ghc-2010 may drop BS 1.* and HDBC 1.* support and of course should add newer libs from HL-2010 standard. the same should do other haskell compilers. this will significantly improve situation with Haskell standard libraries: 1) Haskell' committee will not need to develop artificial "standard libraries" set - actually, i think it can't and anyway any fixed set will become obsolete next year. libraries are most important part of any language and nowadays we can't develop proper stdlibs set "by committee". it should be made by community and committee should only "sign up" final results 2) every haskell distribution will include some guaranteed minimum of common, up-to-date libraries. any program written using H2009 specifications, will continue to run with any major Haskell compilers for a next 3 years. this should overcome "libraries hell" for mid-sized apps 3) any book or courses teaching Haskell can declare, for example, that it investigates Haskell-2009 and any Haskell2009-compatible compiler will provide both the syntax and libs discussed in the book. it will also mean that when you hire "Haskell2009-certified" specialist, you will be sure that he knows not only the language itself but also basic set of libs, equivalent of STL for C++ defining large standard set of libs was the major source of success for Java/C#/C++ last decade. we can go one step further and join development by community with standardization by committee. it should make Haskell better solution for developing large, long-standing products - by providing RICH set of MODERN STANDARD libs, which are guaranteed to run across compilers and years. criteria of inclusion library in this set are (obvious): 1) popularity (this can be fairly measured by downloads/installations/ user votes) 2) open-source, free license, unix/win and ghc/hugs compatibility -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From fmartini at gmail.com Thu Jan 17 12:24:16 2008 From: fmartini at gmail.com (Felix Martini) Date: Thu Jan 17 12:24:22 2008 Subject: Integrating editline with ghc In-Reply-To: <2608b8a80801170508o3960c268o720a20350d433907@mail.gmail.com> References: <6d74b0d20801161305na9e0732m2a6bae7098ec531d@mail.gmail.com> <478F1DB8.1080807@dfki.de> <2608b8a80801170508o3960c268o720a20350d433907@mail.gmail.com> Message-ID: <6c0416190801170924r23e6fa8ci45026bf0dd5dbde3@mail.gmail.com> On Jan 17, 2008 2:08 PM, Yitzchak Gale wrote: > I would hope that ghc will link to editline-ext on all platforms. Unfortunately it seems that editline cannot currently be build on Windows. I have tried to build the editline source from http://www.thrysoee.dk/editline/ with MinGW/msys. Pdcurses could be used instead of ncurses, but it also requires termios.h which MinGW does not have. From dons at galois.com Thu Jan 17 14:15:42 2008 From: dons at galois.com (Don Stewart) Date: Thu Jan 17 14:15:48 2008 Subject: Proposal: hands off the base! :) In-Reply-To: <295830643.20080117201824@gmail.com> References: <478E8C95.7020500@gmail.com> <295830643.20080117201824@gmail.com> Message-ID: <20080117191542.GE10636@scytale.galois.com> bulat.ziganshin: > i make a contra-proposal - fix base library in 6.8 state and add to > ghc distribution new libs with all the popular Monad, List and any > other functions. this will allow: > > 2) if we want to improve some base code, we *duplicate* it into new > lib (with modified module names), publish first version of this > libarry with exactly original code (and therefore equivalent > interfaces) and then start to improve it, publishing newer and newer > versions. imagine, for example, that we want to improve Data.Array.*: > > step 1: create library NewArray with modules Data.NewArray.* copied > one-to-one from Data.Array.* and publish it as version 1 Data.Array is in the external 'array' package now. -- Don From duncan.coutts at worc.ox.ac.uk Thu Jan 17 17:28:32 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Jan 17 17:28:50 2008 Subject: Proposal: Add split and splitWith (trac #2048) In-Reply-To: <478F83F7.6080104@dfki.de> References: <478E8C95.7020500@gmail.com> <20080117000025.GA27886@matrix.chaos.earth.li> <478F83F7.6080104@dfki.de> Message-ID: <1200608912.5639.192.camel@localhost> On Thu, 2008-01-17 at 17:36 +0100, Christian Maeder wrote: > Ian Lynagh wrote: > > One or the other should be changed so that these agree: > > > > *Main> split 'a' "" > > [""] > > *Main> Data.ByteString.Char8.split 'a' (Data.ByteString.Char8.pack "") > > Loading package array-0.1.0.0 ... linking ... done. > > Loading package bytestring-0.9.0.1 ... linking ... done. > > [] > > > > although I couldn't say which is "right" OTTOMH... > > I've convinced myself (see my previous mails) that Twan's version is > right and Data.ByteString.Char8.split should be changed (and all its > usages need to be checked)! > > The documentation in both modules should contain the example! > split c [] == [[]] > > I don't think that the oddity of Data.ByteString.Char8.split on empty > input helps to establish the treatment of a missing final newline for > the lines function. If everyone thinks this is the right behaviour we can certainly change Data.ByteString to follow. It is supposed to follow the Data.List api. Duncan From duncan.coutts at worc.ox.ac.uk Thu Jan 17 17:35:34 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Jan 17 17:35:43 2008 Subject: GHC options in Cabal In-Reply-To: <396556a20801170727o69175421pfa7a52becab4993e@mail.gmail.com> References: <478F5D5A.9070400@iee.org> <396556a20801170727o69175421pfa7a52becab4993e@mail.gmail.com> Message-ID: <1200609334.5639.194.camel@localhost> On Thu, 2008-01-17 at 07:27 -0800, Adam Langley wrote: > On Jan 17, 2008 5:51 AM, Adrian Hey wrote: > > IOW, if I already have.. > > ghc-options: -O2 > > As an aside, I believe that -O2 in ghc-options is considered poor form > because cabal handles the -O options itself (so that > --disable-optimization and friends work). Yes. > There's a trac ticket to write a patch to warn about this, which I did > at some point but, come to think of it, never heard about it again. Oh > well, Did you? Oh, that'd be great. Where is the patch? Duncan From duncan.coutts at worc.ox.ac.uk Thu Jan 17 17:39:49 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Jan 17 17:40:00 2008 Subject: GHC options in Cabal In-Reply-To: <478F5D5A.9070400@iee.org> References: <478F5D5A.9070400@iee.org> Message-ID: <1200609589.5639.199.camel@localhost> On Thu, 2008-01-17 at 13:51 +0000, Adrian Hey wrote: > Hello, > > Looking at the latest Cabal docs, I see that in addition to ghc-options, > there are also ghc-prof-options and ghc-shared-options. What isn't clear > to me though from the docs is that are the latter two in addition to the > first, or are they a substitute for the first (for profiling/shared). > > IOW, if I already have.. > ghc-options: -O2 > > will the O2 also be applied to profiling build (say)? Or do I need an > extra explicit.. > ghc-prof-options: -O2 They are additive. I'm not at all convinced about these fields. It's not clear what their use cases are. As Adam says, adding -O is discouraged. If I had my way I'd make hackage require a performance profile to be supplied along with any package that wanted to use -O2 over -O. Duncan From duncan.coutts at worc.ox.ac.uk Thu Jan 17 17:42:01 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Jan 17 17:42:03 2008 Subject: darcs patch: make Alex only occupy {alex,Alex,ALEX}* names (still assuming Prelude) In-Reply-To: <478F690E.3030704@charter.net> References: <478F690E.3030704@charter.net> Message-ID: <1200609721.5639.203.camel@localhost> On Thu, 2008-01-17 at 09:41 -0500, Isaac Dupree wrote: > Therefore I propose that, though it may break code in the short term, > Happy and Alex should only import things qualified as AlexSomething. It > didn't make things too ugly; they still rely on sufficient basic Prelude > stuff being imported without qualification by the module that uses > Happy/Alex, but that seems the best arrangement to me anyway. (for > example, if a module wants to redefine (&&) in a compatible way -- this > has been done with type-classes, Alex will at least try to use that > instead of importing (&&) unqualified from the Prelude and getting an > ambiguity error) > > This patch does that for Alex, and I've been using it to compile GHC; a > similar patch would be a similar amount of work to make for Happy. > > Thoughts? Does this seem like a good idea? Sounds sensible to me. I've had code break by changing -agc options to happy because it started importing Haskell98 modules and my package did not depend on the haskell98 package. Duncan From isaacdupree at charter.net Thu Jan 17 18:12:19 2008 From: isaacdupree at charter.net (Isaac Dupree) Date: Thu Jan 17 18:12:12 2008 Subject: darcs patch: make Alex only occupy {alex, Alex, ALEX}* names (still assuming Prelude) In-Reply-To: <1200609721.5639.203.camel@localhost> References: <478F690E.3030704@charter.net> <1200609721.5639.203.camel@localhost> Message-ID: <478FE0D3.9020600@charter.net> Duncan Coutts wrote: > I've had code break by changing -agc options to happy because it started > importing Haskell98 modules and my package did not depend on the > haskell98 package. in that case, should we switch to importing the hierarchical names in Happy/Alex-generated code, since everyone uses those these days? I could make a patch to do that too. I wonder if the change I originally proposed should go through the library submission process, which I'm not familiar enough with... http://www.haskell.org/haskellwiki/Library_submissions , okay, probably yes? for alex, I can't figure out how to run the tests, as the Makefile in alex/tests/ doesn't work (after all it was cabalized?). Also the darcs alex/alex.cabal says version: 2.1.0, whereas http://haskell.org/alex/ says the latest released version is 2.2 (not even 2.2.0, and maybe we would say 2.2.0.0 these days!) ~Isaac From isaacdupree at charter.net Thu Jan 17 18:26:22 2008 From: isaacdupree at charter.net (Isaac Dupree) Date: Thu Jan 17 18:26:17 2008 Subject: darcs patch: make Alex only occupy {alex, Alex, ALEX}* names (still assuming Prelude) In-Reply-To: <478FE0D3.9020600@charter.net> References: <478F690E.3030704@charter.net> <1200609721.5639.203.camel@localhost> <478FE0D3.9020600@charter.net> Message-ID: <478FE41E.2030606@charter.net> Isaac Dupree wrote: > Duncan Coutts wrote: >> I've had code break by changing -agc options to happy because it started >> importing Haskell98 modules and my package did not depend on the >> haskell98 package. > > in that case, should we switch to importing the hierarchical names in > Happy/Alex-generated code, since everyone uses those these days? I > could make a patch to do that too. a better design IMHO, though more work, would be to make alex also provide a haskell-library that its generated code uses and depends upon; then it wouldn't have to be quite as ugly in a few ways ~Isaac From agl at imperialviolet.org Thu Jan 17 18:31:38 2008 From: agl at imperialviolet.org (Adam Langley) Date: Thu Jan 17 18:31:39 2008 Subject: GHC options in Cabal In-Reply-To: <1200609334.5639.194.camel@localhost> References: <478F5D5A.9070400@iee.org> <396556a20801170727o69175421pfa7a52becab4993e@mail.gmail.com> <1200609334.5639.194.camel@localhost> Message-ID: <396556a20801171531h5a769be5p1cbbb9605a7f33a9@mail.gmail.com> On Jan 17, 2008 2:35 PM, Duncan Coutts wrote: > Did you? Oh, that'd be great. Where is the patch? I had an hour to kill. I think I remember being a little unsure about where the code for the 3rd one should hook in. Mon Dec 31 09:47:09 PST 2007 agl@imperialviolet.org * Ticket 176: Fix verbosity error to include the valid -v values Mon Dec 31 10:05:16 PST 2007 agl@imperialviolet.org * Ticket 201: report IO errors during clean Mon Dec 31 10:40:21 PST 2007 agl@imperialviolet.org * Ticket 191: check for common, unwise GHC options -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org 650-283-9641 -------------- next part -------------- A non-text attachment was scrubbed... Name: cabal-patches.darcs Type: application/octet-stream Size: 28875 bytes Desc: not available Url : http://www.haskell.org/pipermail/libraries/attachments/20080117/7e40c787/cabal-patches-0001.obj From chak at cse.unsw.edu.au Thu Jan 17 20:03:06 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Thu Jan 17 20:03:09 2008 Subject: Integrating editline with ghc In-Reply-To: <20080117104733.47ea65ad.Malcolm.Wallace@cs.york.ac.uk> References: <6d74b0d20801161305na9e0732m2a6bae7098ec531d@mail.gmail.com> <478F1DB8.1080807@dfki.de> <20080117104733.47ea65ad.Malcolm.Wallace@cs.york.ac.uk> Message-ID: <8AE12C50-BB0F-4914-85F2-C21FC60D7F10@cse.unsw.edu.au> Malcolm Wallace: > Christian Maeder wrote: > >> 1. a _new_ readline package that only contains the interface that can >> be implemented using libeditline _or_ libreadline. If this package is >> call "readline" (with a new version number) most libraries i.e. like >> Shellac would not need modifications. > > I totally agree. Backwards compatibility for all the programs out > there > that already use the readline package (but really don't care whether > it > is actually readline or editline) is vital. I would hate to see all > client code forced to use CPP macros and cabal magic to select the > right > package and module imports. We can avoid such a retrograde step by > explicitly making 'readline' the backend-agnostic package, which > re-exports functionality from either the real readline or editline, > depending on which is available. I don't think we should touch the existing readline package. It's a binding to readline and whether everybody likes its license or not doesn't matter. Some people just want to use readline, and they should be able to continue to do this by importing the library called System.Console.Readline. In addition System.Console.Editline should be a binding to editline. (Again if somebody want editline and nothing else, that's what they import.) Finally, we'd like a module (let's call it EditReadline) whose interface coincides with the readline emulation layer of editline (ie, ). This module should use editline where it is available and otherwise readline (if that is available). We can argue about where in the hierarchy EditReadline should be located (and whether we want to call it EditReadline or something else). Following Judah's proposal, it could be System.Console.Editline.Readline (essentially following the C header structure), but it could alternatively be System.Console.EditReadline (or something else). I think it is important to make a clear distinction between these *three* interface for two reasons: * Both editline and readline have functionality that is not exposed by EditReadline (aka ). * Static linking against EditReadline is allowed for non-GPL compatible code only on systems that have editline. Manuel From dons at galois.com Thu Jan 17 20:05:10 2008 From: dons at galois.com (Don Stewart) Date: Thu Jan 17 20:05:53 2008 Subject: Integrating editline with ghc In-Reply-To: <8AE12C50-BB0F-4914-85F2-C21FC60D7F10@cse.unsw.edu.au> References: <6d74b0d20801161305na9e0732m2a6bae7098ec531d@mail.gmail.com> <478F1DB8.1080807@dfki.de> <20080117104733.47ea65ad.Malcolm.Wallace@cs.york.ac.uk> <8AE12C50-BB0F-4914-85F2-C21FC60D7F10@cse.unsw.edu.au> Message-ID: <20080118010510.GQ10636@scytale.galois.com> chak: > Malcolm Wallace: > >Christian Maeder wrote: > > > >>1. a _new_ readline package that only contains the interface that can > >>be implemented using libeditline _or_ libreadline. If this package is > >>call "readline" (with a new version number) most libraries i.e. like > >>Shellac would not need modifications. > > > >I totally agree. Backwards compatibility for all the programs out > >there > >that already use the readline package (but really don't care whether > >it > >is actually readline or editline) is vital. I would hate to see all > >client code forced to use CPP macros and cabal magic to select the > >right > >package and module imports. We can avoid such a retrograde step by > >explicitly making 'readline' the backend-agnostic package, which > >re-exports functionality from either the real readline or editline, > >depending on which is available. > > I don't think we should touch the existing readline package. It's a > binding to readline and whether everybody likes its license or not > doesn't matter. Some people just want to use readline, and they > should be able to continue to do this by importing the library called > System.Console.Readline. I agree, it makes no sense to hide/obscure readline. Just depend on a different package. So as for the regex-compat lib, we can live happily with a readline-compat that gives a compatible interface to readline, via other means. -- Don From chak at cse.unsw.edu.au Thu Jan 17 20:22:28 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Thu Jan 17 20:22:37 2008 Subject: Integrating editline with ghc In-Reply-To: <478F1DB8.1080807@dfki.de> References: <6d74b0d20801161305na9e0732m2a6bae7098ec531d@mail.gmail.com> <478F1DB8.1080807@dfki.de> Message-ID: <3089E693-CBAE-463B-97EC-328DAC4E36E5@cse.unsw.edu.au> Christian Maeder: > Judah Jacobson wrote: >> - System.Console.Editline.Readline contains the readline APIs >> provided >> by the editline library (mostly a cut/paste of >> System.Console.Readline). > > I would like to see a restructuring of the old readline > package: > > 1. a _new_ readline package that only contains the interface that > can be > implemented using libeditline _or_ libreadline. If this package is > call > "readline" (with a new version number) most libraries i.e. like > Shellac > would not need modifications. I disagree. Readline should stay as it is. (Why force existing readline users who use functionality not supported by editline's emulation layer to change the package they are using?) Instead, we should have a new module whose interface coincides with editline's readline emulation. Everybody who wants to use editline when available and readline only if editline is not available can then use that new module (which I called EditReadline in my previous post). GHC will be one of these programs. Manuel From chak at cse.unsw.edu.au Fri Jan 18 00:29:50 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Fri Jan 18 00:29:53 2008 Subject: Integrating editline with ghc In-Reply-To: <20080118010510.GQ10636@scytale.galois.com> References: <6d74b0d20801161305na9e0732m2a6bae7098ec531d@mail.gmail.com> <478F1DB8.1080807@dfki.de> <20080117104733.47ea65ad.Malcolm.Wallace@cs.york.ac.uk> <8AE12C50-BB0F-4914-85F2-C21FC60D7F10@cse.unsw.edu.au> <20080118010510.GQ10636@scytale.galois.com> Message-ID: Don Stewart: > chak: >> Malcolm Wallace: >>> Christian Maeder wrote: >>> >>>> 1. a _new_ readline package that only contains the interface that >>>> can >>>> be implemented using libeditline _or_ libreadline. If this >>>> package is >>>> call "readline" (with a new version number) most libraries i.e. >>>> like >>>> Shellac would not need modifications. >>> >>> I totally agree. Backwards compatibility for all the programs out >>> there >>> that already use the readline package (but really don't care whether >>> it >>> is actually readline or editline) is vital. I would hate to see all >>> client code forced to use CPP macros and cabal magic to select the >>> right >>> package and module imports. We can avoid such a retrograde step by >>> explicitly making 'readline' the backend-agnostic package, which >>> re-exports functionality from either the real readline or editline, >>> depending on which is available. >> >> I don't think we should touch the existing readline package. It's a >> binding to readline and whether everybody likes its license or not >> doesn't matter. Some people just want to use readline, and they >> should be able to continue to do this by importing the library called >> System.Console.Readline. > > I agree, it makes no sense to hide/obscure readline. Just depend on a > different package. > > So as for the regex-compat lib, we can live happily with a readline- > compat > that gives a compatible interface to readline, via other means. Yes, readline-compat seems like the right package name for this. Manuel From lemming at henning-thielemann.de Fri Jan 18 02:07:07 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri Jan 18 02:07:08 2008 Subject: Proposal: Add split and splitWith (trac #2048) In-Reply-To: <1200608912.5639.192.camel@localhost> References: <478E8C95.7020500@gmail.com> <20080117000025.GA27886@matrix.chaos.earth.li> <478F83F7.6080104@dfki.de> <1200608912.5639.192.camel@localhost> Message-ID: On Thu, 17 Jan 2008, Duncan Coutts wrote: > On Thu, 2008-01-17 at 17:36 +0100, Christian Maeder wrote: > > > > I've convinced myself (see my previous mails) that Twan's version is > > right and Data.ByteString.Char8.split should be changed (and all its > > usages need to be checked)! > > > > The documentation in both modules should contain the example! > > split c [] == [[]] > > > > I don't think that the oddity of Data.ByteString.Char8.split on empty > > input helps to establish the treatment of a missing final newline for > > the lines function. > > If everyone thinks this is the right behaviour we can certainly change > Data.ByteString to follow. It is supposed to follow the Data.List api. I vote for the change. From Christian.Maeder at dfki.de Fri Jan 18 04:03:54 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Fri Jan 18 04:04:03 2008 Subject: Integrating editline with ghc In-Reply-To: <3089E693-CBAE-463B-97EC-328DAC4E36E5@cse.unsw.edu.au> References: <6d74b0d20801161305na9e0732m2a6bae7098ec531d@mail.gmail.com> <478F1DB8.1080807@dfki.de> <3089E693-CBAE-463B-97EC-328DAC4E36E5@cse.unsw.edu.au> Message-ID: <47906B7A.6050407@dfki.de> Manuel M T Chakravarty wrote: > Christian Maeder: >> 1. a _new_ readline package that only contains the interface that can be >> implemented using libeditline _or_ libreadline. If this package is call >> "readline" (with a new version number) most libraries i.e. like Shellac >> would not need modifications. > > I disagree. Readline should stay as it is. (Why force existing > readline users who use functionality not supported by editline's > emulation layer to change the package they are using?) Your point is also supported by Yitz Gale, my point by Malcolm. Where are the users that use the functionality not supported by editline's emulation layer? (Shout now or be quiet ever after) Disadvantage of my proposal (to change the readline interface): We have restructured libraries massively between 6.2 and 6.8 (why not for 6.10?) Disadvantage of making a new interface: Everybody who wants to profit from libedit has to do active changes (so many will not bother, although most would want it.) Christian From Christian.Maeder at dfki.de Fri Jan 18 04:48:44 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Fri Jan 18 04:48:49 2008 Subject: Proposal: Add split and splitWith (trac #2048) In-Reply-To: <1200608912.5639.192.camel@localhost> References: <478E8C95.7020500@gmail.com> <20080117000025.GA27886@matrix.chaos.earth.li> <478F83F7.6080104@dfki.de> <1200608912.5639.192.camel@localhost> Message-ID: <479075FC.7080301@dfki.de> Duncan Coutts wrote: > If everyone thinks this is the right behaviour we can certainly change > Data.ByteString to follow. It is supposed to follow the Data.List api. Good, lines can be best shortly expressed in terms of split as follows: mylines s = if null (last l) then init l else l where l = split '\n' s This is safe (though inefficient), because split always returns a non-empty list (in contrast to Data.ByteString.Char8.split)! Furthermore Data.PackedString.splitPS corresponds to lines. Below are some test case. Cheers Christian import qualified Data.ByteString.Char8 as B import qualified Data.PackedString as P *GHCI> l ["","a","\n","aa","a\n","\na","\n\n"] *GHCI> map (intercalate "\n" . split '\n') l ["","a","\n","aa","a\n","\na","\n\n"] *GHCI> map (B.intercalate (B.pack "\n") . B.split '\n' . B.pack) l ["","a","\n","aa","a\n","\na","\n\n"] *GHCI> map (unlines . lines) l ["","a\n","\n","aa\n","a\n","\na\n","\n\n"] *GHCI> map lines l [[],["a"],[""],["aa"],["a"],["","a"],["",""]] *GHCI> map (lines . unlines . lines) l [[],["a"],[""],["aa"],["a"],["","a"],["",""]] *GHCI> map mylines l [[],["a"],[""],["aa"],["a"],["","a"],["",""]] *GHCI> map (P.splitPS '\n' . P.packString) l [[],["a"],[""],["aa"],["a"],["","a"],["",""]] *GHCI> map (B.split '\n' . B.pack) l [[],["a"],["",""],["aa"],["a",""],["","a"],["","",""]] *GHCI> map (split '\n') l [[""],["a"],["",""],["aa"],["a",""],["","a"],["","",""]] From duncan.coutts at worc.ox.ac.uk Fri Jan 18 05:17:18 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Jan 18 05:19:48 2008 Subject: GHC options in Cabal In-Reply-To: <396556a20801171531h5a769be5p1cbbb9605a7f33a9@mail.gmail.com> References: <478F5D5A.9070400@iee.org> <396556a20801170727o69175421pfa7a52becab4993e@mail.gmail.com> <1200609334.5639.194.camel@localhost> <396556a20801171531h5a769be5p1cbbb9605a7f33a9@mail.gmail.com> Message-ID: <1200651438.5639.229.camel@localhost> On Thu, 2008-01-17 at 15:31 -0800, Adam Langley wrote: > On Jan 17, 2008 2:35 PM, Duncan Coutts wrote: > > Did you? Oh, that'd be great. Where is the patch? > > I had an hour to kill. I think I remember being a little unsure about > where the code for the 3rd one should hook in. Yeah, that's not immediately obvious. It depends on when we want to give those warnings. Eg it's ok to have some of those flags locally but we want to warn if you're preparing a package to distribute. So I'm leaning towards putting the check in sdist and perhaps also in it's own qa/check/lint command. Oh and of course to export it and use it in hackagedb's upload code too. > Mon Dec 31 09:47:09 PST 2007 agl@imperialviolet.org > * Ticket 176: Fix verbosity error to include the valid -v values We'd got a patch for this on in the mean time, though I prefer your clearer error message so have applied it and resolved the conflict. > Mon Dec 31 10:05:16 PST 2007 agl@imperialviolet.org > * Ticket 201: report IO errors during clean Applied. > Mon Dec 31 10:40:21 PST 2007 agl@imperialviolet.org > * Ticket 191: check for common, unwise GHC options Sorry, duplication here. Lennart sent in a patch for this yesterday and I think I prefer that approach. Though there's still work to do in linking the checks into the right places as I describe above. So thanks very much for the patches. Next time send them in as soon as you write them :-) and we'll avoid duplicated work. (I might be going mad, but I don't think I saw them sent to any list.) Next time you have a spare hour for Cabal, I'd suggest looking at the one on striping: http://hackage.haskell.org/trac/hackage/ticket/88 Several packages are now using ghc-options: -opl-Wl,-s which is not great because I don't think that works on all platforms and it causes problems for distros that prefer to handle striping themselves. Duncan From duncan.coutts at worc.ox.ac.uk Fri Jan 18 05:21:44 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Jan 18 05:23:19 2008 Subject: darcs patch: make Alex only occupy {alex, Alex, ALEX}* names (still assuming Prelude) In-Reply-To: <478FE0D3.9020600@charter.net> References: <478F690E.3030704@charter.net> <1200609721.5639.203.camel@localhost> <478FE0D3.9020600@charter.net> Message-ID: <1200651704.5639.232.camel@localhost> On Thu, 2008-01-17 at 18:12 -0500, Isaac Dupree wrote: > Duncan Coutts wrote: > > I've had code break by changing -agc options to happy because it started > > importing Haskell98 modules and my package did not depend on the > > haskell98 package. > > in that case, should we switch to importing the hierarchical names in > Happy/Alex-generated code, since everyone uses those these days? I > could make a patch to do that too. I think so. Everyone always uses the base package but not necessarily the haskell98 package. (nhc98 hackers may disagree however) > I wonder if the change I originally proposed should go through the > library submission process, which I'm not familiar enough with... > http://www.haskell.org/haskellwiki/Library_submissions , okay, probably yes? I'm not sure that's necessary. If there is general agreement and the maintainer accepts the patches that would seem to be sufficient. > for alex, I can't figure out how to run the tests, as the Makefile in > alex/tests/ doesn't work (after all it was cabalized?). > > Also the darcs alex/alex.cabal says version: 2.1.0, whereas > http://haskell.org/alex/ says the latest released version is 2.2 (not > even 2.2.0, and maybe we would say 2.2.0.0 these days!) Ask Simon Marlow. Duncan From duncan.coutts at worc.ox.ac.uk Fri Jan 18 05:23:34 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Jan 18 05:25:32 2008 Subject: darcs patch: make Alex only occupy {alex, Alex, ALEX}* names (still assuming Prelude) In-Reply-To: <478FE41E.2030606@charter.net> References: <478F690E.3030704@charter.net> <1200609721.5639.203.camel@localhost> <478FE0D3.9020600@charter.net> <478FE41E.2030606@charter.net> Message-ID: <1200651814.5639.235.camel@localhost> On Thu, 2008-01-17 at 18:26 -0500, Isaac Dupree wrote: > Isaac Dupree wrote: > > Duncan Coutts wrote: > >> I've had code break by changing -agc options to happy because it started > >> importing Haskell98 modules and my package did not depend on the > >> haskell98 package. > > > > in that case, should we switch to importing the hierarchical names in > > Happy/Alex-generated code, since everyone uses those these days? I > > could make a patch to do that too. > > a better design IMHO, though more work, would be to make alex also > provide a haskell-library that its generated code uses and depends upon; > then it wouldn't have to be quite as ugly in a few ways I disagree. One of the great advantages of alex and happy is that they generate (mostly) self contained modules. If you had to have alex installed to use a alex-generated module that'd be a step back and could cause tricky bootstrapping problems. Duncan From ahey at iee.org Fri Jan 18 06:50:06 2008 From: ahey at iee.org (Adrian Hey) Date: Fri Jan 18 06:50:07 2008 Subject: GHC options in Cabal In-Reply-To: <1200609589.5639.199.camel@localhost> References: <478F5D5A.9070400@iee.org> <1200609589.5639.199.camel@localhost> Message-ID: <4790926E.2090001@iee.org> Duncan Coutts wrote: > On Thu, 2008-01-17 at 13:51 +0000, Adrian Hey wrote: >> Hello, >> >> Looking at the latest Cabal docs, I see that in addition to ghc-options, >> there are also ghc-prof-options and ghc-shared-options. What isn't clear >> to me though from the docs is that are the latter two in addition to the >> first, or are they a substitute for the first (for profiling/shared). >> >> IOW, if I already have.. >> ghc-options: -O2 >> >> will the O2 also be applied to profiling build (say)? Or do I need an >> extra explicit.. >> ghc-prof-options: -O2 > > They are additive. > > I'm not at all convinced about these fields. It's not clear what their > use cases are. > > As Adam says, adding -O is discouraged. If I had my way I'd make hackage > require a performance profile to be supplied along with any package that > wanted to use -O2 over -O. Thanks. Personally I'm not at all sure that having users specify all this stuff on the command line is a good idea. I thought policy was that (ideally) all users should have to do is type.. runghc Setup configure runghc Setup build ..etc If users don't like the defaults defined in the .cabal file they can always edit it (that way they have a record of what was actually used to build the package). I habitually add -split-objs to the ghc-options of stuff I download, for example. I have read about --enable-split-objs, I just don't like using it. I do use --enable-library-profiling habitually, but only because I haven't figured out how to put this in the .cabal file :-) Regards -- Adrian Hey From simonmarhaskell at gmail.com Fri Jan 18 08:07:00 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Fri Jan 18 08:07:07 2008 Subject: Integrating editline with ghc In-Reply-To: <8AE12C50-BB0F-4914-85F2-C21FC60D7F10@cse.unsw.edu.au> References: <6d74b0d20801161305na9e0732m2a6bae7098ec531d@mail.gmail.com> <478F1DB8.1080807@dfki.de> <20080117104733.47ea65ad.Malcolm.Wallace@cs.york.ac.uk> <8AE12C50-BB0F-4914-85F2-C21FC60D7F10@cse.unsw.edu.au> Message-ID: <4790A474.2060607@gmail.com> Manuel M T Chakravarty wrote: > Malcolm Wallace: >> Christian Maeder wrote: >> >>> 1. a _new_ readline package that only contains the interface that can >>> be implemented using libeditline _or_ libreadline. If this package is >>> call "readline" (with a new version number) most libraries i.e. like >>> Shellac would not need modifications. >> >> I totally agree. Backwards compatibility for all the programs out there >> that already use the readline package (but really don't care whether it >> is actually readline or editline) is vital. I would hate to see all >> client code forced to use CPP macros and cabal magic to select the right >> package and module imports. We can avoid such a retrograde step by >> explicitly making 'readline' the backend-agnostic package, which >> re-exports functionality from either the real readline or editline, >> depending on which is available. > > I don't think we should touch the existing readline package. It's a > binding to readline and whether everybody likes its license or not > doesn't matter. Some people just want to use readline, and they should > be able to continue to do this by importing the library called > System.Console.Readline. > > In addition System.Console.Editline should be a binding to editline. > (Again if somebody want editline and nothing else, that's what they > import.) > > Finally, we'd like a module (let's call it EditReadline) whose interface > coincides with the readline emulation layer of editline (ie, > ). This module should use editline where it is > available and otherwise readline (if that is available). We can argue > about where in the hierarchy EditReadline should be located (and whether > we want to call it EditReadline or something else). Following Judah's > proposal, it could be System.Console.Editline.Readline (essentially > following the C header structure), but it could alternatively be > System.Console.EditReadline (or something else). I think it would be a bad idea to provide EditReadline as described. The reason being that this would be a package with a variant license: its license is conditional on how it is built, which makes it that much harder for clients to understand what licensing restrictions apply, and to license themselves appropriately. (the alternative is to make EditReadline GPL, but that defeats the purpose). I don't even think we've considered variant licenses in Cabal before, and my inclination would be to disallow or at least vigorously discourage it. So I suggest we just keep readline as it is, and packages that want to use editline can switch at their discretion, using System.Console.Editline.Readline to make porting easier. In GHC I imagine we'll just switch to using editline. Cheers, Simon From simonmarhaskell at gmail.com Fri Jan 18 08:28:21 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Fri Jan 18 08:28:24 2008 Subject: Proposal: Add split and splitWith (trac #2048) In-Reply-To: <478E8C95.7020500@gmail.com> References: <478E8C95.7020500@gmail.com> Message-ID: <4790A975.6060209@gmail.com> Twan van Laarhoven wrote: > Hello Haskellers, > > An often requested function is 'split', to split a list into parts > delimited by some separator. ByteString has the functions split and > splitWith for this purpose. I propose we add equivalents to Data.List: > > > split :: Eq a => a -> [a] -> [[a]] > > split x = splitWith (x==) > > > > splitWith :: (a -> Bool) -> [a] -> [[a]] > > splitWith p xs = ys : case zs of > > [] -> [] > > _:ws -> splitWith p ws > > where (ys,zs) = break p xs > > trac: http://hackage.haskell.org/trac/ghc/ticket/2048 > deadline: two weeks from now, January 30 Those interested in contributing to this discussion might like to review some of the past threads on this topic :-) http://www.haskell.org/pipermail/libraries/2006-July/005504.html http://www.haskell.org/pipermail/libraries/2006-July/005499.html http://www.haskell.org/pipermail/libraries/2006-July/005525.html http://www.haskell.org/pipermail/libraries/2006-October/006072.html and I'm sure there are earlier threads, but the above probably covers enough of the design space. Cheers, Simon From simonmarhaskell at gmail.com Fri Jan 18 08:36:16 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Fri Jan 18 08:36:18 2008 Subject: darcs patch: make Alex only occupy {alex, Alex, ALEX}* names (still assuming Prelude) In-Reply-To: <478FE0D3.9020600@charter.net> References: <478F690E.3030704@charter.net> <1200609721.5639.203.camel@localhost> <478FE0D3.9020600@charter.net> Message-ID: <4790AB50.1030007@gmail.com> Isaac Dupree wrote: > Duncan Coutts wrote: >> I've had code break by changing -agc options to happy because it started >> importing Haskell98 modules and my package did not depend on the >> haskell98 package. > > in that case, should we switch to importing the hierarchical names in > Happy/Alex-generated code, since everyone uses those these days? I > could make a patch to do that too. Sounds good to me, and I'm happy for you to make the changes in your original patch too (modulo hierarchical modules). > Also the darcs alex/alex.cabal says version: 2.1.0, whereas > http://haskell.org/alex/ says the latest released version is 2.2 (not > even 2.2.0, and maybe we would say 2.2.0.0 these days!) Sorry, I'd forgotten to push my patches for 2.2, but I've done it now. CHeers, Simon From Alistair_Bayley at invescoperpetual.co.uk Fri Jan 18 08:47:26 2008 From: Alistair_Bayley at invescoperpetual.co.uk (Bayley, Alistair) Date: Fri Jan 18 08:47:25 2008 Subject: Proposal: Add split and splitWith (trac #2048) In-Reply-To: <4790A975.6060209@gmail.com> References: <478E8C95.7020500@gmail.com> <4790A975.6060209@gmail.com> Message-ID: <125EACD0CAE4D24ABDB4D148C4593DA9049E9234@GBLONXMB02.corp.amvescap.net> > From: libraries-bounces@haskell.org > [mailto:libraries-bounces@haskell.org] On Behalf Of Simon Marlow > > Twan van Laarhoven wrote: > > Hello Haskellers, > > > > An often requested function is 'split', to split a list into parts > > Those interested in contributing to this discussion might > like to review some of the past threads on this topic :-) There is also this wiki page: http://haskell.org/haskellwiki/List_function_suggestions (which also contains links to the same discussions that Simon referenced.) Alistair ***************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. ***************************************************************** From judah.jacobson at gmail.com Fri Jan 18 12:09:27 2008 From: judah.jacobson at gmail.com (Judah Jacobson) Date: Fri Jan 18 12:09:28 2008 Subject: Integrating editline with ghc In-Reply-To: <478F1DB8.1080807@dfki.de> References: <6d74b0d20801161305na9e0732m2a6bae7098ec531d@mail.gmail.com> <478F1DB8.1080807@dfki.de> Message-ID: <6d74b0d20801180909p38e51531sffcf53d1c41decdd@mail.gmail.com> On Jan 17, 2008 1:19 AM, Christian Maeder wrote: > Judah Jacobson wrote: > > - System.Console.Editline.Readline contains the readline APIs provided > > by the editline library (mostly a cut/paste of > > System.Console.Readline). > > I would like to see a restructuring of the old readline > package: > > 1. a _new_ readline package that only contains the interface that can be > implemented using libeditline _or_ libreadline. If this package is call > "readline" (with a new version number) most libraries i.e. like Shellac > would not need modifications. > > 2. Two further packages for extension of editline and those functions of > readline that are not part of "1". Maybe call these packages > editline-ext and readline-ext A problem with the above proposal: the readline-ext package would depend not just on the readline package, but on an instance of the readline package that was built against libreadline specifically. I don't think that we can enforce that constraint; and even if we could, on a machine with both editline and readline installed it would get confusing pretty quickly. I think it will be much simpler if we keep the readline and editline packages as they are now, and possibly add a third readline-compat package which can use either one as a dependency. Then any project (including GHC) can choose which of those packages to use, based on API requirements and/or license issues. Best, -Judah From alexander.dunlap at gmail.com Sat Jan 19 02:10:23 2008 From: alexander.dunlap at gmail.com (Alexander Dunlap) Date: Sat Jan 19 02:10:19 2008 Subject: Readline read_history and write_history addition Message-ID: <57526e770801182310r2e44c662wd513465d71e67bda@mail.gmail.com> Hello all, I'd like to propose the addition of read_history and write_history bindings to the readline library. I believe I've followed the instructions on the Haskell wiki appropriately and I've set up a ticket (with a patch) at http://hackage.haskell.org/trac/ghc/ticket/2053. Essentially, the patch adds simple bindings so that Haskell programs can use Readline's read_history and write_history functions. This will be useful for the implementation of http://hackage.haskell.org/trac/ghc/ticket/2050 (add persistent history to GHCi) and potentially other applications. Thanks for your time and consideration. Alex From duncan.coutts at worc.ox.ac.uk Sat Jan 19 09:02:31 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sat Jan 19 09:02:29 2008 Subject: GHC options in Cabal In-Reply-To: <4790926E.2090001@iee.org> References: <478F5D5A.9070400@iee.org> <1200609589.5639.199.camel@localhost> <4790926E.2090001@iee.org> Message-ID: <1200751351.5639.266.camel@localhost> On Fri, 2008-01-18 at 11:50 +0000, Adrian Hey wrote: > Personally I'm not at all sure that having users specify all this stuff > on the command line is a good idea. > > I thought policy was that (ideally) all users should have to do is > type.. > runghc Setup configure > runghc Setup build > ..etc Or even better: cabal install Or even better than that, is to not bother downloading, untaring and just say: cabal install xmonad This works now, and I encourage everyone on this list to try it out and report issues. Currently you need the darcs versions of the Cabal lib and cabal-install. It also needs released versions of the zlib and HTTP packages. > If users don't like the defaults defined in the .cabal file they > can always edit it (that way they have a record of what was actually > used to build the package). I habitually add -split-objs to the > ghc-options of stuff I download, for example. I have read about > --enable-split-objs, I just don't like using it. The idea is that end users do not need to edit the .cabal flags. That requires too much manual intervention and gets in the way of automatically installing dependencies if each one has to be customised by manually downloading, unpacking, editing and installing. > I do use --enable-library-profiling habitually, but only because I > haven't figured out how to put this in the .cabal file :-) You'll be able to stick your favourite defaults in the config file for cabal-install, and they'll get used every time. Currently many options but not all can be set in the cabal-install config file. We should extend that to all the configure options. Also, to make life easier, cabal-install already supports bash command line flag completion to save your typing fingers. Duncan From judah.jacobson at gmail.com Sat Jan 19 14:09:56 2008 From: judah.jacobson at gmail.com (Judah Jacobson) Date: Sat Jan 19 14:09:51 2008 Subject: Readline read_history and write_history addition In-Reply-To: <57526e770801182310r2e44c662wd513465d71e67bda@mail.gmail.com> References: <57526e770801182310r2e44c662wd513465d71e67bda@mail.gmail.com> Message-ID: <6d74b0d20801191109m4c484a44x96e83abb528b2277@mail.gmail.com> On Jan 18, 2008 11:10 PM, Alexander Dunlap wrote: > Hello all, > > I'd like to propose the addition of read_history and write_history > bindings to the readline library. I believe I've followed the > instructions on the Haskell wiki appropriately and I've set up a > ticket (with a patch) at > http://hackage.haskell.org/trac/ghc/ticket/2053. > > Essentially, the patch adds simple bindings so that Haskell programs > can use Readline's read_history and write_history functions. This will > be useful for the implementation of > http://hackage.haskell.org/trac/ghc/ticket/2050 (add persistent > history to GHCi) and potentially other applications. > > Thanks for your time and consideration. > > Alex That patch looks good to me. While we're at it, can we also add the following related functions, which are used to control the maximum size of the history file? (They're also provided by editline.) void clear_history(void); void stifle_history(int); int unstifle_history(void); int history_is_stifled(void); Thanks, -Judah From alexander.dunlap at gmail.com Sat Jan 19 18:43:30 2008 From: alexander.dunlap at gmail.com (Alexander Dunlap) Date: Sat Jan 19 18:43:27 2008 Subject: Readline read_history and write_history addition In-Reply-To: <6d74b0d20801191109m4c484a44x96e83abb528b2277@mail.gmail.com> References: <57526e770801182310r2e44c662wd513465d71e67bda@mail.gmail.com> <6d74b0d20801191109m4c484a44x96e83abb528b2277@mail.gmail.com> Message-ID: <57526e770801191543u71ad5c52r2edd09387c8fe870@mail.gmail.com> I don't see why not. I've attached a patch to add bindings for all six functions. Alex On Jan 19, 2008 11:09 AM, Judah Jacobson wrote: > > On Jan 18, 2008 11:10 PM, Alexander Dunlap wrote: > > Hello all, > > > > I'd like to propose the addition of read_history and write_history > > bindings to the readline library. I believe I've followed the > > instructions on the Haskell wiki appropriately and I've set up a > > ticket (with a patch) at > > http://hackage.haskell.org/trac/ghc/ticket/2053. > > > > Essentially, the patch adds simple bindings so that Haskell programs > > can use Readline's read_history and write_history functions. This will > > be useful for the implementation of > > http://hackage.haskell.org/trac/ghc/ticket/2050 (add persistent > > history to GHCi) and potentially other applications. > > > > Thanks for your time and consideration. > > > > Alex > > That patch looks good to me. While we're at it, can we also add the > following related functions, which are used to control the maximum > size of the history file? (They're also provided by editline.) > > void clear_history(void); > void stifle_history(int); > int unstifle_history(void); > int history_is_stifled(void); > > Thanks, > -Judah > -------------- next part -------------- A non-text attachment was scrubbed... Name: readline-2053-history.patch Type: application/octet-stream Size: 7849 bytes Desc: not available Url : http://www.haskell.org/pipermail/libraries/attachments/20080119/2a76a4a4/readline-2053-history.obj From frederik at a5.repetae.net Sat Jan 19 23:46:58 2008 From: frederik at a5.repetae.net (Frederik Eaton) Date: Sat Jan 19 23:46:56 2008 Subject: HSQL defunct? In-Reply-To: <4606A979.10408@cs.chalmers.se> References: <20060817001711.GD3356@a5.repetae.net> <20060817004940.GE3356@a5.repetae.net> <20060817211056.GR3356@a5.repetae.net> <44EEC0F7.3010302@cs.chalmers.se> <20070303173504.GA14521@a5.repetae.net> <4606A979.10408@cs.chalmers.se> Message-ID: <20080120044658.GA10424@a5.repetae.net> Hello all, Is there going to be a new maintainer for HSQL? I have submitted a number of patches to fix some painful bugs. It's been almost a year since my previous enquiry and the last release was December 15, 2005, over two years ago: https://sourceforge.net/project/showfiles.php?group_id=65248 The software no longer compiles with the latest version of GHC, due to some (seemingly gratuitous) changes in the Cabal libraries (I see there is a September 2007 thread on libraries@). Unfortunately, I am too busy to maintain it myself; I was probably even too busy to write the patches in the first place, but it is sad to see them go to waste... Frederik P.S. Quan Ta: regarding your July 20, 2006 query, "HSQL-MySQL: non-standard port", my first patch adds the ability to specify a non-standard port with the server host name, if you are still interested I can send it. On Sun, Mar 25, 2007 at 06:55:21PM +0200, Bj?rn Bringert wrote: > I found this very old mail in my inbox, sorry for not responding sooner. > Yeah, a new HSQL release would be a good idea, IMO. Krasimir is the > maintainer, so it's really up to him. > > /Bj?rn > > Frederik Eaton wrote: > > Hi Bjorn, > > > > The sourceforge page for HSQL shows a most recent release date of > > December 15, 2005 - over a year ago, presumably not including the > > timezone patch which I think fixes a rather serious bug, which caused > > a lot of problems for me when I tried to use HSQL for my master's > > project. Perhaps it might be helpful to other users if the fix were > > made available to them as well? > > > > Thanks, > > > > Frederik > > > > On Fri, Aug 25, 2006 at 11:20:55AM +0200, Bj?rn Bringert wrote: > >> Sorry for the delay, I've been on vacation. The timezone patch has been > >> committed. I haven't added the Makefile, since I think that some cabal > >> tools that will come with GHC 6.6 could make it obsolete. > >> > >> /Bj?rn > >> > >> Frederik Eaton wrote: > >>> Hi, > >>> > >>> Oops, sorry, there was a bug. Here's a more-tested patch. Stay tuned! > >>> > >>> (if you've already applied the last one, change HSQL.hsc's > >>> > >>> ctMonth = toEnum $ mon, > >>> > >>> to > >>> > >>> ctMonth = toEnum $ (mon-1), > >>> > >>> ) > >>> > >>> Frederik > >>> > >>> On Thu, Aug 17, 2006 at 01:49:40AM +0100, Frederik Eaton wrote: > >>> > >>>> I'm attaching a patch which I've tested. > >>>> > >>>> I'm also attaching a Makefile derived from Bulat's IIRC, it might be > >>>> good to include it in those directories which contain a .cabal file. > >>>> > >>>> Thanks, > >>>> > >>>> Frederik > >>>> > >>>> On Thu, Aug 17, 2006 at 01:17:11AM +0100, Frederik Eaton wrote: > >>>> > >>>>> Hi, in > >>>>> > >>>>> HSQL/Database/HSQL.hsc > >>>>> > >>>>> instance SqlBind ClockTime where > >>>>> ... > >>>>> > >>>>> all of the 'fromSqlValue' functions convert with respect to the local > >>>>> timezone, while 'toSqlValue' converts with respect to UTC. Thus the > >>>>> values being written are not the same, it would seem, as those being > >>>>> read. Certainly that is the case for me. > >>>>> > >>>>> If the three appearances of currTZ within the body of that instance > >>>>> (and not elsewhere) are changed to 0, it should fix the problem (but I > >>>>> haven't tested). > >>>>> > >>>>> Also, I don't understand why a custom function 'mkClockTime' has been > >>>>> written in that module (it calls 'mktime' via FFI), rather than > >>>>> calling the standard library function toClockTime which seems to do > >>>>> the same thing. > >>>>> > >>>>> Frederik > >>>>> > >>>>> On Thu, Aug 10, 2006 at 04:19:36PM +0100, Frederik Eaton wrote: > >>>>> > >>>>>> In HSQL, why are 'datetime' columns interpreted as being in the local > >>>>>> timezone? > >>>>>> > >>>>>> I would think that UTC would be more useful. If the local timezone is > >>>>>> used, then it makes it more difficult to move a server between > >>>>>> timezones, or to have multiple servers in multiple timezones. > >>>>>> > >>>>>> Frederik > >>>>>> > >>>>>> On Sat, Aug 05, 2006 at 06:59:21PM +0100, Frederik Eaton wrote: > >>>>>> > >>>>>>> Thanks! > >>>>>>> > >>>>>>> On Sat, Aug 05, 2006 at 05:27:04PM +0200, Bjorn Bringert wrote: > >>>>>>> > >>>>>>>> On Aug 5, 2006, at 3:34 PM, Frederik Eaton wrote: > >>>>>>>> > >>>>>>>> > >>>>>>>>> On Sat, Aug 05, 2006 at 11:15:19AM +0200, Bjorn Bringert wrote: > >>>>>>>>> > >>>>>>>>>> On Jul 31, 2006, at 12:55 PM, Frederik Eaton wrote: > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> Hi, > >>>>>>>>>>> > >>>>>>>>>>> I'm attaching another HSQL patch. > >>>>>>>>>>> > >>>>>>>>>>> It allows users to specify a port number with the server name in the > >>>>>>>>>>> MySQL client. > >>>>>>>>>>> > >>>>>>>>>>> Frederik > >>>>>>>>>> Hi Frederik, > >>>>>>>>>> > >>>>>>>>>> the patch doesn't apply cleanly against the current CVS version. Is > >>>>>>>>>> there any chance you could make a patch against the CVS version > >>>>>>>>>> instead? > >>>>>>>>> It's a very simple modification, can't you just copy and paste from > >>>>>>>>> the patch? > >>>>>>>> It appears to have been a simple whitespace mismatch problem (tabs in the original HSQL source). I > >>>>>>>> have committed your patch to CVS. > >>>>>>>> > >>>>>>>> Thanks! > >>>>>>>> > >>>>>>>> /Bj?rn > >>>> -- > >>>> http://ofb.net/~frederik/ > >>> > >>>> diff -ur HSQL-1.7-modified/HSQL/Database/HSQL.hsc HSQL-1.7-modified-2/HSQL/Database/HSQL.hsc > >>>> --- HSQL-1.7-modified/HSQL/Database/HSQL.hsc 2005-12-15 20:57:18.000000000 +0000 > >>>> +++ HSQL-1.7-modified-2/HSQL/Database/HSQL.hsc 2006-08-17 01:43:19.000000000 +0100 > >>>> @@ -304,28 +304,17 @@ > >>>> > >>>> toSqlValue d = show d > >>>> > >>>> -mkClockTime :: Int -> Int -> Int -> Int -> Int -> Int -> Int -> ClockTime > >>>> mkClockTime year mon mday hour min sec tz = > >>>> - unsafePerformIO $ do > >>>> - allocaBytes (#const sizeof(struct tm)) $ \ p_tm -> do > >>>> - (#poke struct tm,tm_sec ) p_tm (fromIntegral sec :: CInt) > >>>> - (#poke struct tm,tm_min ) p_tm (fromIntegral min :: CInt) > >>>> - (#poke struct tm,tm_hour ) p_tm (fromIntegral hour :: CInt) > >>>> - (#poke struct tm,tm_mday ) p_tm (fromIntegral mday :: CInt) > >>>> - (#poke struct tm,tm_mon ) p_tm (fromIntegral (mon-1) :: CInt) > >>>> - (#poke struct tm,tm_year ) p_tm (fromIntegral (year-1900) :: CInt) > >>>> - (#poke struct tm,tm_isdst) p_tm (-1 :: CInt) > >>>> - t <- mktime p_tm > >>>> -#if __GLASGOW_HASKELL__ >= 603 > >>>> - return (TOD (fromIntegral (fromEnum t) + fromIntegral (tz-currTZ)) 0) > >>>> -#else > >>>> - return (TOD (fromIntegral t + fromIntegral (tz-currTZ)) 0) > >>>> -#endif > >>>> -foreign import ccall unsafe mktime :: Ptr () -> IO CTime > >>>> - > >>>> -{-# NOINLINE currTZ #-} > >>>> -currTZ :: Int > >>>> -currTZ = ctTZ (unsafePerformIO (getClockTime >>= toCalendarTime)) -- Hack > >>>> + toClockTime $ CalendarTime { > >>>> + ctYear = year, > >>>> + ctMonth = toEnum $ mon, > >>>> + ctDay = mday, > >>>> + ctHour = hour, > >>>> + ctMin = min, > >>>> + ctSec = sec, > >>>> + ctPicosec = 0, > >>>> + ctTZ = tz > >>>> + } > >>>> > >>>> parseTZ :: ReadP Int > >>>> parseTZ = (char '+' >> readDecP) `mplus` (char '-' >> fmap negate readDecP) > >>>> @@ -373,14 +362,14 @@ > >>>> getTime :: ReadP ClockTime > >>>> getTime = do > >>>> (hour, minutes, seconds) <- readHMS > >>>> - return (mkClockTime 1970 1 1 hour minutes seconds currTZ) > >>>> + return (mkClockTime 1970 1 1 hour minutes seconds 0) > >>>> > >>>> fromSqlValue SqlDate s = f_read getDate s > >>>> where > >>>> getDate :: ReadP ClockTime > >>>> getDate = do > >>>> (year, month, day) <- readYMD > >>>> - return (mkClockTime year month day 0 0 0 currTZ) > >>>> + return (mkClockTime year month day 0 0 0 0) > >>>> > >>>> fromSqlValue SqlDateTimeTZ s = f_read getDateTimeTZ s > >>>> where > >>>> @@ -400,7 +389,7 @@ > >>>> getDateTime :: ReadP ClockTime > >>>> getDateTime = do > >>>> (year, month, day, hour, minutes, seconds) <- readDateTime > >>>> - return (mkClockTime year month day hour minutes seconds currTZ) > >>>> + return (mkClockTime year month day hour minutes seconds 0) > >>>> > >>>> fromSqlValue _ _ = Nothing > >>>> > >>> > >>>> # This Makefile is mostly a wrapper around Setup.hs for people who > >>>> # just want to type make. > >>>> > >>>> CAS=runhaskell Setup.lhs > >>>> CONFOPTS ?= --user --prefix=${HOME} > >>>> INSTOPTS ?= --user > >>>> > >>>> all: build > >>>> > >>>> configure: .setup-config > >>>> .setup-config: HSQL.cabal > >>>> ${CAS} configure ${CONFOPTS} > >>>> > >>>> build: configure > >>>> ${CAS} build > >>>> > >>>> install: build > >>>> ${CAS} install ${INSTOPTS} > >>>> > >>>> uninstall: unregister > >>>> unregister: configure > >>>> ${CAS} unregister > >>>> > >>>> clean: > >>>> -runhaskell Setup.hs clean > >>>> -rm -rf dist > >>>> -rm -f .setup-config > >>>> > >>>> .PHONY: all configure build install uninstall unregister clean > >>> > >>> > >>> > >>> ------------------------------------------------------------------------ > >>> > >>> diff -ur HSQL-1.7-modified/HSQL/Database/HSQL.hsc HSQL-1.7-modified-2/HSQL/Database/HSQL.hsc > >>> --- HSQL-1.7-modified/HSQL/Database/HSQL.hsc 2005-12-15 20:57:18.000000000 +0000 > >>> +++ HSQL-1.7-modified-2/HSQL/Database/HSQL.hsc 2006-08-17 22:04:23.000000000 +0100 > >>> @@ -304,28 +304,17 @@ > >>> > >>> toSqlValue d = show d > >>> > >>> -mkClockTime :: Int -> Int -> Int -> Int -> Int -> Int -> Int -> ClockTime > >>> mkClockTime year mon mday hour min sec tz = > >>> - unsafePerformIO $ do > >>> - allocaBytes (#const sizeof(struct tm)) $ \ p_tm -> do > >>> - (#poke struct tm,tm_sec ) p_tm (fromIntegral sec :: CInt) > >>> - (#poke struct tm,tm_min ) p_tm (fromIntegral min :: CInt) > >>> - (#poke struct tm,tm_hour ) p_tm (fromIntegral hour :: CInt) > >>> - (#poke struct tm,tm_mday ) p_tm (fromIntegral mday :: CInt) > >>> - (#poke struct tm,tm_mon ) p_tm (fromIntegral (mon-1) :: CInt) > >>> - (#poke struct tm,tm_year ) p_tm (fromIntegral (year-1900) :: CInt) > >>> - (#poke struct tm,tm_isdst) p_tm (-1 :: CInt) > >>> - t <- mktime p_tm > >>> -#if __GLASGOW_HASKELL__ >= 603 > >>> - return (TOD (fromIntegral (fromEnum t) + fromIntegral (tz-currTZ)) 0) > >>> -#else > >>> - return (TOD (fromIntegral t + fromIntegral (tz-currTZ)) 0) > >>> -#endif > >>> -foreign import ccall unsafe mktime :: Ptr () -> IO CTime > >>> - > >>> -{-# NOINLINE currTZ #-} > >>> -currTZ :: Int > >>> -currTZ = ctTZ (unsafePerformIO (getClockTime >>= toCalendarTime)) -- Hack > >>> + toClockTime $ CalendarTime { > >>> + ctYear = year, > >>> + ctMonth = toEnum $ (mon-1), > >>> + ctDay = mday, > >>> + ctHour = hour, > >>> + ctMin = min, > >>> + ctSec = sec, > >>> + ctPicosec = 0, > >>> + ctTZ = tz > >>> + } > >>> > >>> parseTZ :: ReadP Int > >>> parseTZ = (char '+' >> readDecP) `mplus` (char '-' >> fmap negate readDecP) > >>> @@ -373,14 +362,14 @@ > >>> getTime :: ReadP ClockTime > >>> getTime = do > >>> (hour, minutes, seconds) <- readHMS > >>> - return (mkClockTime 1970 1 1 hour minutes seconds currTZ) > >>> + return (mkClockTime 1970 1 1 hour minutes seconds 0) > >>> > >>> fromSqlValue SqlDate s = f_read getDate s > >>> where > >>> getDate :: ReadP ClockTime > >>> getDate = do > >>> (year, month, day) <- readYMD > >>> - return (mkClockTime year month day 0 0 0 currTZ) > >>> + return (mkClockTime year month day 0 0 0 0) > >>> > >>> fromSqlValue SqlDateTimeTZ s = f_read getDateTimeTZ s > >>> where > >>> @@ -400,7 +389,7 @@ > >>> getDateTime :: ReadP ClockTime > >>> getDateTime = do > >>> (year, month, day, hour, minutes, seconds) <- readDateTime > >>> - return (mkClockTime year month day hour minutes seconds currTZ) > >>> + return (mkClockTime year month day hour minutes seconds 0) > >>> > >>> fromSqlValue _ _ = Nothing > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > htoolkit-users mailing list > htoolkit-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/htoolkit-users > -- http://ofb.net/~frederik/ From bos at serpentine.com Sun Jan 20 00:05:33 2008 From: bos at serpentine.com (Bryan O'Sullivan) Date: Sun Jan 20 00:05:28 2008 Subject: HSQL defunct? In-Reply-To: <20080120044658.GA10424@a5.repetae.net> References: <20060817001711.GD3356@a5.repetae.net> <20060817004940.GE3356@a5.repetae.net> <20060817211056.GR3356@a5.repetae.net> <44EEC0F7.3010302@cs.chalmers.se> <20070303173504.GA14521@a5.repetae.net> <4606A979.10408@cs.chalmers.se> <20080120044658.GA10424@a5.repetae.net> Message-ID: <4792D69D.7070103@serpentine.com> Frederik Eaton wrote: > Is there going to be a new maintainer for HSQL? I have submitted a > number of patches to fix some painful bugs. It's been almost a year > since my previous enquiry and the last release was December 15, 2005, > over two years ago: I think that if it's sat moribund for this long, you could reasonably declare yourself the maintainer by fiat. Some OSS communities have a formal process for declaring packages as orphaned, but I don't think we're big enough for that. If you don't mind the idea of taking the HSQL package over, perhaps you should follow the same steps Don did with the X11 package: * declare your intention to take over in a message to libraries@ * wait a week for someone to pop up with an objection * if nobody does, upload a new release with your fixes to Hackage References: <20060817001711.GD3356@a5.repetae.net> <20060817004940.GE3356@a5.repetae.net> <20060817211056.GR3356@a5.repetae.net> <44EEC0F7.3010302@cs.chalmers.se> <20070303173504.GA14521@a5.repetae.net> <4606A979.10408@cs.chalmers.se> <20080120044658.GA10424@a5.repetae.net> <4792D69D.7070103@serpentine.com> Message-ID: Hi Frederik and Bryan, The latest darcs repository for HSQL is here: http://darcs.haskell.org/HSQL/ I have to admit that I didn't have enough energy to maintain the HSQL in the last two years. If someone voluntee to take the HSQL maintaince then he is highly welcome. There are some new features like prepared statements and large binary objects that aren't completed/tested yet and this should be done before the next official release. Best regards, Krasimir On 1/20/08, Bryan O'Sullivan wrote: > Frederik Eaton wrote: > > > Is there going to be a new maintainer for HSQL? I have submitted a > > number of patches to fix some painful bugs. It's been almost a year > > since my previous enquiry and the last release was December 15, 2005, > > over two years ago: > > I think that if it's sat moribund for this long, you could reasonably > declare yourself the maintainer by fiat. Some OSS communities have a > formal process for declaring packages as orphaned, but I don't think > we're big enough for that. > > If you don't mind the idea of taking the HSQL package over, perhaps you > should follow the same steps Don did with the X11 package: > > * declare your intention to take over in a message to libraries@ > * wait a week for someone to pop up with an objection > * if nobody does, upload a new release with your fixes to Hackage > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > htoolkit-users mailing list > htoolkit-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/htoolkit-users > From duncan.coutts at worc.ox.ac.uk Sun Jan 20 07:46:21 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Jan 20 07:46:14 2008 Subject: HSQL defunct? In-Reply-To: <20080120044658.GA10424@a5.repetae.net> References: <20060817001711.GD3356@a5.repetae.net> <20060817004940.GE3356@a5.repetae.net> <20060817211056.GR3356@a5.repetae.net> <44EEC0F7.3010302@cs.chalmers.se> <20070303173504.GA14521@a5.repetae.net> <4606A979.10408@cs.chalmers.se> <20080120044658.GA10424@a5.repetae.net> Message-ID: <1200833181.5639.312.camel@localhost> On Sun, 2008-01-20 at 04:46 +0000, Frederik Eaton wrote: > Hello all, > > Is there going to be a new maintainer for HSQL? I have submitted a > number of patches to fix some painful bugs. It's been almost a year > since my previous enquiry and the last release was December 15, 2005, > over two years ago: > > https://sourceforge.net/project/showfiles.php?group_id=65248 > > The software no longer compiles with the latest version of GHC, due to > some (seemingly gratuitous) changes in the Cabal libraries (I see > there is a September 2007 thread on libraries@). Unfortunately, I am > too busy to maintain it myself; I was probably even too busy to write > the patches in the first place, but it is sad to see them go to > waste... Gentoo has patches to make hsql-* build with ghc-6.8.x which you or any volunteer maintainer may find useful. Duncan From johan.tibell at gmail.com Mon Jan 21 04:13:24 2008 From: johan.tibell at gmail.com (Johan Tibell) Date: Mon Jan 21 04:13:16 2008 Subject: Proposal: hands off the base! :) In-Reply-To: <295830643.20080117201824@gmail.com> References: <478E8C95.7020500@gmail.com> <295830643.20080117201824@gmail.com> Message-ID: <90889fe70801210113p285698e7x46368e9f849a0ea0@mail.gmail.com> Hi Bulat, On Jan 17, 2008 6:18 PM, Bulat Ziganshin wrote: > step 1: create library NewArray with modules Data.NewArray.* copied > one-to-one from Data.Array.* and publish it as version 1 Having words like "new" for the purpose of versioning is quite confusing because a library which is new at some point will eventually become old and then the name is misleading. Versioning doesn't belong in module/function names IMHO. -- Johan From Christian.Maeder at dfki.de Mon Jan 21 05:40:07 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Mon Jan 21 05:40:02 2008 Subject: Integrating editline with ghc In-Reply-To: <6d74b0d20801180909p38e51531sffcf53d1c41decdd@mail.gmail.com> References: <6d74b0d20801161305na9e0732m2a6bae7098ec531d@mail.gmail.com> <478F1DB8.1080807@dfki.de> <6d74b0d20801180909p38e51531sffcf53d1c41decdd@mail.gmail.com> Message-ID: <47947687.6020604@dfki.de> Judah Jacobson wrote: > I think it will be much simpler if we keep the readline and editline > packages as they are now, and possibly add a third readline-compat > package which can use either one as a dependency. Then any project > (including GHC) can choose which of those packages to use, based on > API requirements and/or license issues. Could then editline go already into ghc-6.8.3, because interfaces don't change? Re-iterating, I would like to see your package readline-compat and hope it will be sufficient for the packages Shellac and Shellac-readline. (Even better if the current package readline is renamed to old-readline and readline-compat to readline.) I wonder how many hackage packages have readline as build-depends (and how many of them would be content with readline-compat). Which version of editline to you require? Our newest version installed (under Solaris) is: editline.h,v 1.5 Which include files are used on Macs? Cheers Christian From gale at sefer.org Mon Jan 21 08:18:19 2008 From: gale at sefer.org (Yitzchak Gale) Date: Mon Jan 21 08:18:09 2008 Subject: Integrating editline with ghc In-Reply-To: <47947687.6020604@dfki.de> References: <6d74b0d20801161305na9e0732m2a6bae7098ec531d@mail.gmail.com> <478F1DB8.1080807@dfki.de> <6d74b0d20801180909p38e51531sffcf53d1c41decdd@mail.gmail.com> <47947687.6020604@dfki.de> Message-ID: <2608b8a80801210518k6c59d34cl893b2a081739af91@mail.gmail.com> Hi Christian, Christian Maeder wrote: > ...Even better if the current package readline is renamed to old-readline > and readline-compat to readline. I have been trying to understand why you want to do that. What would we gain? Thanks, Yitz From Christian.Maeder at dfki.de Mon Jan 21 09:13:23 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Mon Jan 21 09:13:13 2008 Subject: Integrating editline with ghc In-Reply-To: <2608b8a80801210518k6c59d34cl893b2a081739af91@mail.gmail.com> References: <6d74b0d20801161305na9e0732m2a6bae7098ec531d@mail.gmail.com> <478F1DB8.1080807@dfki.de> <6d74b0d20801180909p38e51531sffcf53d1c41decdd@mail.gmail.com> <47947687.6020604@dfki.de> <2608b8a80801210518k6c59d34cl893b2a081739af91@mail.gmail.com> Message-ID: <4794A883.2070903@dfki.de> Yitzchak Gale wrote: > Hi Christian, > > Christian Maeder wrote: >> ...Even better if the current package readline is renamed to old-readline >> and readline-compat to readline. > > I have been trying to understand why you want to do > that. What would we gain? On Macs I want Shellac-readline to use editline, under linux we don't have editline, so there I want to continue to use Shellac-readline as it is now. But I don't want to use different Haskell packages for different platforms (for the same project). On Macs, the only change I had to make to the Shellac-readline package was to replace "readline >= 1.0" with "editline >= 0.1" in Shellac-readline.cabal and "System.Console.Readline" with "System.Console.Editline.Readline" in src/System/Console/Shell/Backend/Readline.hs These changes were not necessary if readline-compat supplied a module System.Console.Readline and would be named "readline". (A better name for old-readline would be GPL-readline, though) I wonder how many other packages would work without changes and how many would break, because readline-compat supplies only a part of the old readline. Depending on what the ghc team and the library maintainers decide, either "readline" has to be changed to "readline-compat" in *.cabal or (worse) we get packages Shellac-readline and Shellac-editline or (more worse) Shellac-readline stays as is and I have to fiddle with editline or readline on Macs myself (like now). HTH Christian From Christian.Maeder at dfki.de Mon Jan 21 10:22:44 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Mon Jan 21 10:22:38 2008 Subject: Integrating editline with ghc In-Reply-To: <4794A883.2070903@dfki.de> References: <6d74b0d20801161305na9e0732m2a6bae7098ec531d@mail.gmail.com> <478F1DB8.1080807@dfki.de> <6d74b0d20801180909p38e51531sffcf53d1c41decdd@mail.gmail.com> <47947687.6020604@dfki.de> <2608b8a80801210518k6c59d34cl893b2a081739af91@mail.gmail.com> <4794A883.2070903@dfki.de> Message-ID: <4794B8C4.4080304@dfki.de> Christian Maeder wrote: > Depending on what the ghc team and the library maintainers decide, > "readline" has to be changed to "readline-compat" in *.cabal Maybe someone could point out how the conditional build-depends entry would look like in Shellac-readline.cabal if readline is to be used for older ghc versions (with GNU readline only) and readline-compat for newer ghcs (possible using editline). Will there be a new flag hasReadlineCompat? Cheers C. From simonmarhaskell at gmail.com Mon Jan 21 10:54:31 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Mon Jan 21 10:54:24 2008 Subject: Integrating editline with ghc In-Reply-To: <4794A883.2070903@dfki.de> References: <6d74b0d20801161305na9e0732m2a6bae7098ec531d@mail.gmail.com> <478F1DB8.1080807@dfki.de> <6d74b0d20801180909p38e51531sffcf53d1c41decdd@mail.gmail.com> <47947687.6020604@dfki.de> <2608b8a80801210518k6c59d34cl893b2a081739af91@mail.gmail.com> <4794A883.2070903@dfki.de> Message-ID: <4794C037.90609@gmail.com> Christian Maeder wrote: > Depending on what the ghc team and the library maintainers decide, > either "readline" has to be changed to "readline-compat" in *.cabal or > (worse) we get packages Shellac-readline and Shellac-editline or (more > worse) Shellac-readline stays as is and I have to fiddle with editline > or readline on Macs myself (like now). It would be a bad idea to remove functionality from the readline package. It's a binding to the GNU readline library, and as such it does a fine job. In a similar vein, we should have an editline package that provides a binding to libedit. For convenience, we would like there to be an API that can be supported by both readline and editline. It would be a bad idea for this to be a package, because (as I mentioned earlier on libraries@) that package would have a variant license, depending on whether the API-provider was readline or editline at build-time (or perhaps in the future link-time or run-time). If you chose between readline and editline, then you have to make an explicit choice in your .cabal file - making a package that abstracts this choice is not good, unless said package is explicitly GPL'd. So the compatible API could be in a module that is exposed by *both* readline and editline, say System.Console.ReadlineCompat. So your source code wouldn't have to change to switch from one to the other, just your .cabal file. Cheers, Simon From Christian.Maeder at dfki.de Mon Jan 21 12:10:55 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Mon Jan 21 12:10:50 2008 Subject: Integrating editline with ghc In-Reply-To: <4794C037.90609@gmail.com> References: <6d74b0d20801161305na9e0732m2a6bae7098ec531d@mail.gmail.com> <478F1DB8.1080807@dfki.de> <6d74b0d20801180909p38e51531sffcf53d1c41decdd@mail.gmail.com> <47947687.6020604@dfki.de> <2608b8a80801210518k6c59d34cl893b2a081739af91@mail.gmail.com> <4794A883.2070903@dfki.de> <4794C037.90609@gmail.com> Message-ID: <4794D21F.6080201@dfki.de> Simon Marlow wrote: > It would be a bad idea to remove functionality from the readline > package. It's a binding to the GNU readline library, and as such it does > a fine job. I only want to move (not remove). > For convenience, we would like there to be an API that can be supported > by both readline and editline. It would be a bad idea for this to be a > package, because (as I mentioned earlier on libraries@) that package > would have a variant license, depending on whether the API-provider was > readline or editline at build-time (or perhaps in the future link-time > or run-time). If you chose between readline and editline, then you have > to make an explicit choice in your .cabal file - making a package that > abstracts this choice is not good, unless said package is explicitly GPL'd. Actually, the license is not (so) important for me. I basically want the convenience to link against libedit on Macs and against libreadline on other unix system, because these libs are usually there without further ado. > So the compatible API could be in a module that is exposed by *both* > readline and editline, say System.Console.ReadlineCompat. So your > source code wouldn't have to change to switch from one to the other, > just your .cabal file. Things ghc does not support, users have to do. Christian From judah.jacobson at gmail.com Mon Jan 21 12:35:42 2008 From: judah.jacobson at gmail.com (Judah Jacobson) Date: Mon Jan 21 12:35:31 2008 Subject: Integrating editline with ghc In-Reply-To: <47947687.6020604@dfki.de> References: <6d74b0d20801161305na9e0732m2a6bae7098ec531d@mail.gmail.com> <478F1DB8.1080807@dfki.de> <6d74b0d20801180909p38e51531sffcf53d1c41decdd@mail.gmail.com> <47947687.6020604@dfki.de> Message-ID: <6d74b0d20801210935iffcadd4j1d942b44c2cae776@mail.gmail.com> On Jan 21, 2008 2:40 AM, Christian Maeder wrote: > Judah Jacobson wrote: > > I think it will be much simpler if we keep the readline and editline > > packages as they are now, and possibly add a third readline-compat > > package which can use either one as a dependency. Then any project > > (including GHC) can choose which of those packages to use, based on > > API requirements and/or license issues. > > Could then editline go already into ghc-6.8.3, because interfaces don't > change? > > Re-iterating, I would like to see your package readline-compat and hope > it will be sufficient for the packages Shellac and Shellac-readline. > (Even better if the current package readline is renamed to old-readline > and readline-compat to readline.) Hmm...As Christian suggested to me in a private email, I was wrong in my initial testing of Shellac-readline: it relies on a variable (_history_max_entries) that is not in editline. So I think we should definitely keep the readline package the way that it is. Luckily, there are other functions, giving the same functionality, which are shared by readline and editline, and are scheduled to become official parts of readline in a week or two; see (http://www.nabble.com/Readline-read_history-and-write_history-addition-td14967976.html) I'll add those functions to the editline and readline-compat packages. > I wonder how many hackage packages have readline as build-depends (and > how many of them would be content with readline-compat). > > Which version of editline to you require? > > Our newest version installed (under Solaris) is: editline.h,v 1.5 > > Which include files are used on Macs? On OS X 10.4, I have readline.h,v 1.11 as the libedit readline compatibility header. Can you please try linking a simple program that uses System.Console.Editline.Readline on your Solaris machine and see if it throws up any link errors? If so, I may be able to fix that. Thanks, -Judah From judah.jacobson at gmail.com Mon Jan 21 13:27:35 2008 From: judah.jacobson at gmail.com (Judah Jacobson) Date: Mon Jan 21 13:27:24 2008 Subject: Readline read_history and write_history addition In-Reply-To: <57526e770801191543u71ad5c52r2edd09387c8fe870@mail.gmail.com> References: <57526e770801182310r2e44c662wd513465d71e67bda@mail.gmail.com> <6d74b0d20801191109m4c484a44x96e83abb528b2277@mail.gmail.com> <57526e770801191543u71ad5c52r2edd09387c8fe870@mail.gmail.com> Message-ID: <6d74b0d20801211027v621580b2k6584eb3b24bf8320@mail.gmail.com> > On Jan 19, 2008 11:09 AM, Judah Jacobson wrote: > > > > On Jan 18, 2008 11:10 PM, Alexander Dunlap wrote: > > > Hello all, > > > > > > I'd like to propose the addition of read_history and write_history > > > bindings to the readline library. I believe I've followed the > > > instructions on the Haskell wiki appropriately and I've set up a > > > ticket (with a patch) at > > > http://hackage.haskell.org/trac/ghc/ticket/2053. > > > > > > Essentially, the patch adds simple bindings so that Haskell programs > > > can use Readline's read_history and write_history functions. This will > > > be useful for the implementation of > > > http://hackage.haskell.org/trac/ghc/ticket/2050 (add persistent > > > history to GHCi) and potentially other applications. > > > > > > Thanks for your time and consideration. > > > > > > Alex > > > > That patch looks good to me. While we're at it, can we also add the > > following related functions, which are used to control the maximum > > size of the history file? (They're also provided by editline.) > > > > void clear_history(void); > > void stifle_history(int); > > int unstifle_history(void); > > int history_is_stifled(void); > > One more suggestion, from Robert Dockins (author of the Shellac and Shellac-readline packages): > The only concern I have is that this patch doesn't seem to > be handling errors properly. read_history and write_history should return > errno, but this binding has them returning (). These functions do file > operations and therefore can fail; we want (be able) to know when that > happens. I think we should just throw an error if those functions return a nonzero value; for example, we already do that in the functions readInitFile and parseAndBind. Thanks, -Judah From robdockins at fastmail.fm Mon Jan 21 14:09:59 2008 From: robdockins at fastmail.fm (Robert Dockins) Date: Mon Jan 21 13:42:07 2008 Subject: Readline read_history and write_history addition In-Reply-To: <6d74b0d20801211027v621580b2k6584eb3b24bf8320@mail.gmail.com> References: <57526e770801182310r2e44c662wd513465d71e67bda@mail.gmail.com> <57526e770801191543u71ad5c52r2edd09387c8fe870@mail.gmail.com> <6d74b0d20801211027v621580b2k6584eb3b24bf8320@mail.gmail.com> Message-ID: <200801211410.00022.robdockins@fastmail.fm> On Monday 21 January 2008 01:27:35 pm Judah Jacobson wrote: > > On Jan 19, 2008 11:09 AM, Judah Jacobson wrote: > > > On Jan 18, 2008 11:10 PM, Alexander Dunlap wrote: > > > > Hello all, > > > > > > > > I'd like to propose the addition of read_history and write_history > > > > bindings to the readline library. I believe I've followed the > > > > instructions on the Haskell wiki appropriately and I've set up a > > > > ticket (with a patch) at > > > > http://hackage.haskell.org/trac/ghc/ticket/2053. > > > > > > > > Essentially, the patch adds simple bindings so that Haskell programs > > > > can use Readline's read_history and write_history functions. This > > > > will be useful for the implementation of > > > > http://hackage.haskell.org/trac/ghc/ticket/2050 (add persistent > > > > history to GHCi) and potentially other applications. > > > > > > > > Thanks for your time and consideration. > > > > > > > > Alex > > > > > > That patch looks good to me. While we're at it, can we also add the > > > following related functions, which are used to control the maximum > > > size of the history file? (They're also provided by editline.) > > > > > > void clear_history(void); > > > void stifle_history(int); > > > int unstifle_history(void); > > > int history_is_stifled(void); > > One more suggestion, from Robert Dockins (author of the Shellac and > > Shellac-readline packages): > > The only concern I have is that this patch doesn't seem to > > be handling errors properly. read_history and write_history should > > return errno, but this binding has them returning (). These functions do > > file operations and therefore can fail; we want (be able) to know when > > that happens. > > I think we should just throw an error if those functions return a > nonzero value; for example, we already do that in the functions > readInitFile and parseAndBind. Ha, I was just now composing an email to this effect. In addition, it would be nice for me if you could include: history_max_entries :: IO Int You can get this from readline by peeking this variable: foreign import ccall "readline/history.h &history_max_entries" history_max_entries :: Ptr CInt Then I could completely remove direct FFI bindings from my packages. > Thanks, > -Judah From ahey at iee.org Mon Jan 21 16:09:26 2008 From: ahey at iee.org (Adrian Hey) Date: Mon Jan 21 16:09:18 2008 Subject: Quick Hackage question Message-ID: <47950A06.4020303@iee.org> Hello, Could someone explain why some packages in Hackage have links to the haddock for exposed modules and others don't? Also some seem to have links to a "buildlog", but others don't. What's going on? Thanks -- Adrian Hey From nominolo at googlemail.com Mon Jan 21 17:29:39 2008 From: nominolo at googlemail.com (Thomas Schilling) Date: Mon Jan 21 17:31:00 2008 Subject: Quick Hackage question In-Reply-To: <47950A06.4020303@iee.org> References: <47950A06.4020303@iee.org> Message-ID: <1200954579.5883.44.camel@intothevoid> On Mon, 2008-01-21 at 21:09 +0000, Adrian Hey wrote: > Hello, > > Could someone explain why some packages in Hackage have links to the > haddock for exposed modules and others don't? I think that's due to Haddock errors. From judah.jacobson at gmail.com Mon Jan 21 17:57:03 2008 From: judah.jacobson at gmail.com (Judah Jacobson) Date: Mon Jan 21 17:56:51 2008 Subject: Quick Hackage question In-Reply-To: <1200954579.5883.44.camel@intothevoid> References: <47950A06.4020303@iee.org> <1200954579.5883.44.camel@intothevoid> Message-ID: <6d74b0d20801211457wb0ef86dr2e6da81096f1acee@mail.gmail.com> On Jan 21, 2008 2:29 PM, Thomas Schilling wrote: > On Mon, 2008-01-21 at 21:09 +0000, Adrian Hey wrote: > > Hello, > > > > Could someone explain why some packages in Hackage have links to the > > haddock for exposed modules and others don't? > > I think that's due to Haddock errors. Would it be possible to get better reporting of errors that prevent Haddock docs from being built? Some packages without docs list a build log, but many others don't. For example, the editline package was posted about 5-6 days ago, and still doesn't have haddock links (probably because libedit isn't installed on the hackage server). It would be nice to see the build errors, if any, so that I could request for any missing libraries to be installed. Thanks, -Judah From nominolo at googlemail.com Mon Jan 21 18:08:49 2008 From: nominolo at googlemail.com (Thomas Schilling) Date: Mon Jan 21 18:10:12 2008 Subject: Quick Hackage question In-Reply-To: <6d74b0d20801211457wb0ef86dr2e6da81096f1acee@mail.gmail.com> References: <47950A06.4020303@iee.org> <1200954579.5883.44.camel@intothevoid> <6d74b0d20801211457wb0ef86dr2e6da81096f1acee@mail.gmail.com> Message-ID: <1200956929.5883.50.camel@intothevoid> On Mon, 2008-01-21 at 14:57 -0800, Judah Jacobson wrote: > On Jan 21, 2008 2:29 PM, Thomas Schilling wrote: > > On Mon, 2008-01-21 at 21:09 +0000, Adrian Hey wrote: > > > Hello, > > > > > > Could someone explain why some packages in Hackage have links to the > > > haddock for exposed modules and others don't? > > > > I think that's due to Haddock errors. > > Would it be possible to get better reporting of errors that prevent > Haddock docs from being built? Some packages without docs list a > build log, but many others don't. > > For example, the editline package was posted about 5-6 days ago, and > still doesn't have haddock links (probably because libedit isn't > installed on the hackage server). It would be nice to see the build > errors, if any, so that I could request for any missing libraries to > be installed. FWIW, using $ cabal install -v3 editline I get [...lots] configure: error: editline not found, so this package cannot be built I guess we'd have the same error on Hackage. From duncan.coutts at worc.ox.ac.uk Mon Jan 21 19:53:04 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Jan 21 19:52:54 2008 Subject: Quick Hackage question In-Reply-To: <6d74b0d20801211457wb0ef86dr2e6da81096f1acee@mail.gmail.com> References: <47950A06.4020303@iee.org> <1200954579.5883.44.camel@intothevoid> <6d74b0d20801211457wb0ef86dr2e6da81096f1acee@mail.gmail.com> Message-ID: <1200963184.5639.479.camel@localhost> On Mon, 2008-01-21 at 14:57 -0800, Judah Jacobson wrote: > On Jan 21, 2008 2:29 PM, Thomas Schilling wrote: > > On Mon, 2008-01-21 at 21:09 +0000, Adrian Hey wrote: > > > Hello, > > > > > > Could someone explain why some packages in Hackage have links to the > > > haddock for exposed modules and others don't? > > > > I think that's due to Haddock errors. > > Would it be possible to get better reporting of errors that prevent > Haddock docs from being built? Some packages without docs list a > build log, but many others don't. We're trying to do even better than that: http://hackage.haskell.org/trac/hackage/ticket/184 You're most welcome to help out. There are several sub-tasks to this. In the medium term, expecting the hackage server to be able to build each package is unrealistic. It will never have all the system libs and eventually will probably not have the cpu time to even build them all. The solution is to have separate building and have hackage just report the results. Duncan From judah.jacobson at gmail.com Mon Jan 21 20:47:18 2008 From: judah.jacobson at gmail.com (Judah Jacobson) Date: Mon Jan 21 20:47:06 2008 Subject: Quick Hackage question In-Reply-To: <1200963184.5639.479.camel@localhost> References: <47950A06.4020303@iee.org> <1200954579.5883.44.camel@intothevoid> <6d74b0d20801211457wb0ef86dr2e6da81096f1acee@mail.gmail.com> <1200963184.5639.479.camel@localhost> Message-ID: <6d74b0d20801211747wcb463e0w84fe88d79c7f8d54@mail.gmail.com> On Jan 21, 2008 4:53 PM, Duncan Coutts wrote: > > On Mon, 2008-01-21 at 14:57 -0800, Judah Jacobson wrote: > > > > Would it be possible to get better reporting of errors that prevent > > Haddock docs from being built? Some packages without docs list a > > build log, but many others don't. > > [...] > > In the medium term, expecting the hackage server to be able to build > each package is unrealistic. It will never have all the system libs and > eventually will probably not have the cpu time to even build them all. > The solution is to have separate building and have hackage just report > the results. That makes sense; but if the packages aren't built on the server, will we still be able to display the Haddock docs? Maybe there should be some way for the person uploading a package to also upload its Haddock files? Thanks, -Judah From alexander.dunlap at gmail.com Mon Jan 21 23:34:50 2008 From: alexander.dunlap at gmail.com (Alexander Dunlap) Date: Mon Jan 21 23:34:37 2008 Subject: Readline read_history and write_history addition In-Reply-To: <6d74b0d20801211027v621580b2k6584eb3b24bf8320@mail.gmail.com> References: <57526e770801182310r2e44c662wd513465d71e67bda@mail.gmail.com> <6d74b0d20801191109m4c484a44x96e83abb528b2277@mail.gmail.com> <57526e770801191543u71ad5c52r2edd09387c8fe870@mail.gmail.com> <6d74b0d20801211027v621580b2k6584eb3b24bf8320@mail.gmail.com> Message-ID: <57526e770801212034g790f1671p38d47b681bd687bb@mail.gmail.com> On Jan 21, 2008 10:27 AM, Judah Jacobson wrote: > > > On Jan 19, 2008 11:09 AM, Judah Jacobson wrote: > > > > > > On Jan 18, 2008 11:10 PM, Alexander Dunlap wrote: > > > > Hello all, > > > > > > > > I'd like to propose the addition of read_history and write_history > > > > bindings to the readline library. I believe I've followed the > > > > instructions on the Haskell wiki appropriately and I've set up a > > > > ticket (with a patch) at > > > > http://hackage.haskell.org/trac/ghc/ticket/2053. > > > > > > > > Essentially, the patch adds simple bindings so that Haskell programs > > > > can use Readline's read_history and write_history functions. This will > > > > be useful for the implementation of > > > > http://hackage.haskell.org/trac/ghc/ticket/2050 (add persistent > > > > history to GHCi) and potentially other applications. > > > > > > > > Thanks for your time and consideration. > > > > > > > > Alex > > > > > > That patch looks good to me. While we're at it, can we also add the > > > following related functions, which are used to control the maximum > > > size of the history file? (They're also provided by editline.) > > > > > > void clear_history(void); > > > void stifle_history(int); > > > int unstifle_history(void); > > > int history_is_stifled(void); > > > > > One more suggestion, from Robert Dockins (author of the Shellac and > Shellac-readline packages): > > > The only concern I have is that this patch doesn't seem to > > be handling errors properly. read_history and write_history should return > > errno, but this binding has them returning (). These functions do file > > operations and therefore can fail; we want (be able) to know when that > > happens. > > I think we should just throw an error if those functions return a > nonzero value; for example, we already do that in the functions > readInitFile and parseAndBind. > > Thanks, > -Judah > I'm reluctant to use the throw an error solution because these functions failing does not have to be the end of the world (or even necessarily handled by the application). If the history file can't be found, the user just doesn't get their history restored (in fact, this may not even be a problem: if the user hasn't used the application before, readHistory will fail silently on the first run and then work fine after the history has been saved at the end of the first session). Similarly, writing or appending to the history file is generally not an essential task and can fail without terminating the program. (I know there's catch, but I don't think the programmer even has to worry about it that much.) I think that just returning a value for success and a value for failure would be appropriate. However, I'm not sure how we would implement it without using error. The usual Haskell solution would be to use Maybe, but what would we have Just of, since the functions don't return real values? Is Just () an accepted idiom? (I've never seen it, but I haven't seen all the Haskell there is to see, either.) Thanks. Alex From s.clover at gmail.com Tue Jan 22 00:00:51 2008 From: s.clover at gmail.com (Sterling Clover) Date: Tue Jan 22 00:00:45 2008 Subject: Readline read_history and write_history addition In-Reply-To: <57526e770801212034g790f1671p38d47b681bd687bb@mail.gmail.com> References: <57526e770801182310r2e44c662wd513465d71e67bda@mail.gmail.com> <6d74b0d20801191109m4c484a44x96e83abb528b2277@mail.gmail.com> <57526e770801191543u71ad5c52r2edd09387c8fe870@mail.gmail.com> <6d74b0d20801211027v621580b2k6584eb3b24bf8320@mail.gmail.com> <57526e770801212034g790f1671p38d47b681bd687bb@mail.gmail.com> Message-ID: <2BF2D3FF-089E-4A6F-83D4-C162D4F696B9@gmail.com> It seems to me that the proper solution would be to throw the proper exception for the errno, warning of such an exception clearly in the documentation. If the user of the library wants to swallow the exception themselves and continue with a catch or bracket statement, they should have that option, but they should also have the flexibility to handle exceptions in a particular way, should they need that functionality. There's no reason a library binding should conceal any potentially useful functionality of the underlying library. If the errors that were returned were unique, Either String Bool might be an option, but as we've got a built-in standard for handling precisely the sorts of IO errors that are returned, it seems silly not to use it. --S On Jan 21, 2008, at 11:34 PM, Alexander Dunlap wrote: > On Jan 21, 2008 10:27 AM, Judah Jacobson > wrote: >> >> One more suggestion, from Robert Dockins (author of the Shellac and >> Shellac-readline packages): >> >>> The only concern I have is that this patch doesn't seem to >>> be handling errors properly. read_history and write_history >>> should return >>> errno, but this binding has them returning (). These functions >>> do file >>> operations and therefore can fail; we want (be able) to know when >>> that >>> happens. >> >> I think we should just throw an error if those functions return a >> nonzero value; for example, we already do that in the functions >> readInitFile and parseAndBind. >> >> Thanks, >> -Judah >> > > I'm reluctant to use the throw an error solution because these > functions failing does not have to be the end of the world (or even > necessarily handled by the application). If the history file can't be > found, the user just doesn't get their history restored (in fact, this > may not even be a problem: if the user hasn't used the application > before, readHistory will fail silently on the first run and then work > fine after the history has been saved at the end of the first > session). Similarly, writing or appending to the history file is > generally not an essential task and can fail without terminating the > program. (I know there's catch, but I don't think the programmer even > has to worry about it that much.) I think that just returning a value > for success and a value for failure would be appropriate. > > However, I'm not sure how we would implement it without using error. > The usual Haskell solution would be to use Maybe, but what would we > have Just of, since the functions don't return real values? Is Just () > an accepted idiom? (I've never seen it, but I haven't seen all the > Haskell there is to see, either.) > > Thanks. > Alex > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries From alexander.dunlap at gmail.com Tue Jan 22 00:17:05 2008 From: alexander.dunlap at gmail.com (Alexander Dunlap) Date: Tue Jan 22 00:16:59 2008 Subject: Readline read_history and write_history addition In-Reply-To: <57526e770801212115g650dffdcm7c7677df5e299fe5@mail.gmail.com> References: <57526e770801182310r2e44c662wd513465d71e67bda@mail.gmail.com> <6d74b0d20801191109m4c484a44x96e83abb528b2277@mail.gmail.com> <57526e770801191543u71ad5c52r2edd09387c8fe870@mail.gmail.com> <6d74b0d20801211027v621580b2k6584eb3b24bf8320@mail.gmail.com> <57526e770801212034g790f1671p38d47b681bd687bb@mail.gmail.com> <2BF2D3FF-089E-4A6F-83D4-C162D4F696B9@gmail.com> <57526e770801212115g650dffdcm7c7677df5e299fe5@mail.gmail.com> Message-ID: <57526e770801212117w7589e9f1i252b830e6dba855@mail.gmail.com> On Jan 21, 2008 9:15 PM, Alexander Dunlap wrote: > > On Jan 21, 2008 9:00 PM, Sterling Clover wrote: > > It seems to me that the proper solution would be to throw the proper > > exception for the errno, warning of such an exception clearly in the > > documentation. If the user of the library wants to swallow the > > exception themselves and continue with a catch or bracket statement, > > they should have that option, but they should also have the > > flexibility to handle exceptions in a particular way, should they > > need that functionality. There's no reason a library binding should > > conceal any potentially useful functionality of the underlying > > library. If the errors that were returned were unique, Either String > > Bool might be an option, but as we've got a built-in standard for > > handling precisely the sorts of IO errors that are returned, it seems > > silly not to use it. > > > > --S > > > > On Jan 21, 2008, at 11:34 PM, Alexander Dunlap wrote: > > > > > On Jan 21, 2008 10:27 AM, Judah Jacobson > > > wrote: > > >> > > > > >> One more suggestion, from Robert Dockins (author of the Shellac and > > >> Shellac-readline packages): > > >> > > >>> The only concern I have is that this patch doesn't seem to > > >>> be handling errors properly. read_history and write_history > > >>> should return > > >>> errno, but this binding has them returning (). These functions > > >>> do file > > >>> operations and therefore can fail; we want (be able) to know when > > >>> that > > >>> happens. > > >> > > >> I think we should just throw an error if those functions return a > > >> nonzero value; for example, we already do that in the functions > > >> readInitFile and parseAndBind. > > >> > > >> Thanks, > > >> -Judah > > >> > > > > > > I'm reluctant to use the throw an error solution because these > > > functions failing does not have to be the end of the world (or even > > > necessarily handled by the application). If the history file can't be > > > found, the user just doesn't get their history restored (in fact, this > > > may not even be a problem: if the user hasn't used the application > > > before, readHistory will fail silently on the first run and then work > > > fine after the history has been saved at the end of the first > > > session). Similarly, writing or appending to the history file is > > > generally not an essential task and can fail without terminating the > > > program. (I know there's catch, but I don't think the programmer even > > > has to worry about it that much.) I think that just returning a value > > > for success and a value for failure would be appropriate. > > > > > > However, I'm not sure how we would implement it without using error. > > > The usual Haskell solution would be to use Maybe, but what would we > > > have Just of, since the functions don't return real values? Is Just () > > > an accepted idiom? (I've never seen it, but I haven't seen all the > > > Haskell there is to see, either.) > > > > > > Thanks. > > > Alex > > > _______________________________________________ > > > 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 > > > > Okay, I was unaware that that was the accepted way to handle errors > for IO operations. If that's the standard, I guess we ought to follow > it. Attached is a revised patch, including the requested > historyMaxEntries function and a couple others for completeness. > > Alex Sorry. I forgot to attach the patch. Here it is. Alex -------------- next part -------------- A non-text attachment was scrubbed... Name: readline-2053-history-4.patch Type: application/octet-stream Size: 9415 bytes Desc: not available Url : http://www.haskell.org/pipermail/libraries/attachments/20080121/4010fe58/readline-2053-history-4-0001.obj From lemming at henning-thielemann.de Tue Jan 22 01:39:28 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Tue Jan 22 01:39:51 2008 Subject: Readline read_history and write_history addition In-Reply-To: <57526e770801212034g790f1671p38d47b681bd687bb@mail.gmail.com> References: <57526e770801182310r2e44c662wd513465d71e67bda@mail.gmail.com> <6d74b0d20801191109m4c484a44x96e83abb528b2277@mail.gmail.com> <57526e770801191543u71ad5c52r2edd09387c8fe870@mail.gmail.com> <6d74b0d20801211027v621580b2k6584eb3b24bf8320@mail.gmail.com> <57526e770801212034g790f1671p38d47b681bd687bb@mail.gmail.com> Message-ID: On Mon, 21 Jan 2008, Alexander Dunlap wrote: > I'm reluctant to use the throw an error solution because these > functions failing does not have to be the end of the world (or even > necessarily handled by the application). http://www.haskell.org/haskellwiki/Exception http://www.haskell.org/haskellwiki/Error From Christian.Maeder at dfki.de Tue Jan 22 04:09:21 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Tue Jan 22 04:09:12 2008 Subject: Integrating editline with ghc In-Reply-To: <6d74b0d20801210935iffcadd4j1d942b44c2cae776@mail.gmail.com> References: <6d74b0d20801161305na9e0732m2a6bae7098ec531d@mail.gmail.com> <478F1DB8.1080807@dfki.de> <6d74b0d20801180909p38e51531sffcf53d1c41decdd@mail.gmail.com> <47947687.6020604@dfki.de> <6d74b0d20801210935iffcadd4j1d942b44c2cae776@mail.gmail.com> Message-ID: <4795B2C1.4090406@dfki.de> Judah Jacobson wrote: > On OS X 10.4, I have readline.h,v 1.11 as the libedit readline > compatibility header. Can you please try linking a simple program > that uses System.Console.Editline.Readline on your Solaris machine and > see if it throws up any link errors? If so, I may be able to fix > that. I wasn't able to install your editline-0.1 package under Solaris. Our installed files are: /usr/local/lib/libeditline.so -> libeditline.so.0.0.0 /usr/local/lib/libeditline.so.0 -> libeditline.so.0.0.0 /usr/local/lib/libeditline.so.0.0.0 /usr/local/lib/libeditline.a /usr/local/lib/libeditline.la /usr/local/include/editline.h Christian checking for gcc option to accept ANSI C... none needed checking for tputs in -lncurses... yes checking for el_init in -ledit... no checking for readline in -ledit... no checking how to run the C preprocessor... gcc -E checking for egrep... egrep checking for ANSI C header files... no checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking editline/readline.h usability... no checking editline/readline.h presence... no checking for editline/readline.h... no checking readline/readline.h usability... yes checking readline/readline.h presence... yes checking for readline/readline.h... yes configure: error: editline not found, so this package cannot be built From ahey at iee.org Tue Jan 22 04:32:04 2008 From: ahey at iee.org (Adrian Hey) Date: Tue Jan 22 04:31:56 2008 Subject: Quick Hackage question In-Reply-To: <6d74b0d20801211747wcb463e0w84fe88d79c7f8d54@mail.gmail.com> References: <47950A06.4020303@iee.org> <1200954579.5883.44.camel@intothevoid> <6d74b0d20801211457wb0ef86dr2e6da81096f1acee@mail.gmail.com> <1200963184.5639.479.camel@localhost> <6d74b0d20801211747wcb463e0w84fe88d79c7f8d54@mail.gmail.com> Message-ID: <4795B814.6010807@iee.org> Judah Jacobson wrote: > That makes sense; but if the packages aren't built on the server, will > we still be able to display the Haddock docs? Presumably it doesn't have to do a full build just to generate the Haddock, which is the immediate problem. Users can't tell much about a package without this. Is it just errors being thrown by Haddock that's stopping this? If so, it seems to me that obvious solution is just to link to whatever html haddock generated, regardless. Regards -- Adrian Hey From chak at cse.unsw.edu.au Tue Jan 22 04:41:26 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Tue Jan 22 04:41:17 2008 Subject: Integrating editline with ghc In-Reply-To: <47906B7A.6050407@dfki.de> References: <6d74b0d20801161305na9e0732m2a6bae7098ec531d@mail.gmail.com> <478F1DB8.1080807@dfki.de> <3089E693-CBAE-463B-97EC-328DAC4E36E5@cse.unsw.edu.au> <47906B7A.6050407@dfki.de> Message-ID: <6BD28026-7344-4A99-9E8D-A55C318BF10E@cse.unsw.edu.au> Christian Maeder: > Manuel M T Chakravarty wrote: >> Christian Maeder: >>> 1. a _new_ readline package that only contains the interface that >>> can be >>> implemented using libeditline _or_ libreadline. If this package is >>> call >>> "readline" (with a new version number) most libraries i.e. like >>> Shellac >>> would not need modifications. >> >> I disagree. Readline should stay as it is. (Why force existing >> readline users who use functionality not supported by editline's >> emulation layer to change the package they are using?) > > Your point is also supported by Yitz Gale, my point by Malcolm. > > Where are the users that use the functionality not supported by > editline's emulation layer? (Shout now or be quiet ever after) Are you seriously suggesting that we mess up users who do not read the various mailing lists constantly to defend the APIs they are using? Manuel From chak at cse.unsw.edu.au Tue Jan 22 04:49:21 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Tue Jan 22 04:49:11 2008 Subject: Integrating editline with ghc In-Reply-To: <4790A474.2060607@gmail.com> References: <6d74b0d20801161305na9e0732m2a6bae7098ec531d@mail.gmail.com> <478F1DB8.1080807@dfki.de> <20080117104733.47ea65ad.Malcolm.Wallace@cs.york.ac.uk> <8AE12C50-BB0F-4914-85F2-C21FC60D7F10@cse.unsw.edu.au> <4790A474.2060607@gmail.com> Message-ID: Simon Marlow: > Manuel M T Chakravarty wrote: >> Malcolm Wallace: >>> Christian Maeder wrote: >>> >>>> 1. a _new_ readline package that only contains the interface that >>>> can >>>> be implemented using libeditline _or_ libreadline. If this >>>> package is >>>> call "readline" (with a new version number) most libraries i.e. >>>> like >>>> Shellac would not need modifications. >>> >>> I totally agree. Backwards compatibility for all the programs out >>> there >>> that already use the readline package (but really don't care >>> whether it >>> is actually readline or editline) is vital. I would hate to see all >>> client code forced to use CPP macros and cabal magic to select the >>> right >>> package and module imports. We can avoid such a retrograde step by >>> explicitly making 'readline' the backend-agnostic package, which >>> re-exports functionality from either the real readline or editline, >>> depending on which is available. >> I don't think we should touch the existing readline package. It's >> a binding to readline and whether everybody likes its license or >> not doesn't matter. Some people just want to use readline, and >> they should be able to continue to do this by importing the library >> called System.Console.Readline. >> In addition System.Console.Editline should be a binding to >> editline. (Again if somebody want editline and nothing else, >> that's what they import.) >> Finally, we'd like a module (let's call it EditReadline) whose >> interface coincides with the readline emulation layer of editline >> (ie, ). This module should use editline where >> it is available and otherwise readline (if that is available). We >> can argue about where in the hierarchy EditReadline should be >> located (and whether we want to call it EditReadline or something >> else). Following Judah's proposal, it could be >> System.Console.Editline.Readline (essentially following the C >> header structure), but it could alternatively be >> System.Console.EditReadline (or something else). > > I think it would be a bad idea to provide EditReadline as > described. The reason being that this would be a package with a > variant license: its license is conditional on how it is built, > which makes it that much harder for clients to understand what > licensing restrictions apply, and to license themselves > appropriately. (the alternative is to make EditReadline GPL, but > that defeats the purpose). > > > I don't even think we've considered variant licenses in Cabal > before, and my inclination would be to disallow or at least > vigorously discourage it. I don't like this either. > So I suggest we just keep readline as it is, and packages that want > to use editline can switch at their discretion, using > System.Console.Editline.Readline to make porting easier. In GHC I > imagine we'll just switch to using editline. That's fine if all platforms that by default have readline also have editline. I just checked, Fedora 8 does have both. How about other Linux distros? What is the situation on Solaris? Manuel From Christian.Maeder at dfki.de Tue Jan 22 04:52:41 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Tue Jan 22 04:52:35 2008 Subject: Integrating editline with ghc In-Reply-To: <6BD28026-7344-4A99-9E8D-A55C318BF10E@cse.unsw.edu.au> References: <6d74b0d20801161305na9e0732m2a6bae7098ec531d@mail.gmail.com> <478F1DB8.1080807@dfki.de> <3089E693-CBAE-463B-97EC-328DAC4E36E5@cse.unsw.edu.au> <47906B7A.6050407@dfki.de> <6BD28026-7344-4A99-9E8D-A55C318BF10E@cse.unsw.edu.au> Message-ID: <4795BCE9.6080205@dfki.de> Manuel M T Chakravarty wrote: > Christian Maeder: >> Manuel M T Chakravarty wrote: >>> Christian Maeder: >>>> 1. a _new_ readline package that only contains the interface that >>>> can be >>>> implemented using libeditline _or_ libreadline. If this package is call >>>> "readline" (with a new version number) most libraries i.e. like Shellac >>>> would not need modifications. >>> >>> I disagree. Readline should stay as it is. (Why force existing >>> readline users who use functionality not supported by editline's >>> emulation layer to change the package they are using?) >> >> Your point is also supported by Yitz Gale, my point by Malcolm. >> >> Where are the users that use the functionality not supported by >> editline's emulation layer? (Shout now or be quiet ever after) > > Are you seriously suggesting that we mess up users who do not read the > various mailing lists constantly to defend the APIs they are using? I only wanted to find out which user group would need to change readline to editline and (if following my suggestion) which group readline to GPL-readline in cabal files, and which of the two user groups is bigger. Since it's not clear yet, what portion of readline can be emulated by editline this is difficult to estimate. Christian From duncan.coutts at worc.ox.ac.uk Tue Jan 22 05:17:31 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Jan 22 05:17:18 2008 Subject: Quick Hackage question In-Reply-To: <4795B814.6010807@iee.org> References: <47950A06.4020303@iee.org> <1200954579.5883.44.camel@intothevoid> <6d74b0d20801211457wb0ef86dr2e6da81096f1acee@mail.gmail.com> <1200963184.5639.479.camel@localhost> <6d74b0d20801211747wcb463e0w84fe88d79c7f8d54@mail.gmail.com> <4795B814.6010807@iee.org> Message-ID: <1200997051.5639.482.camel@localhost> On Tue, 2008-01-22 at 09:32 +0000, Adrian Hey wrote: > Judah Jacobson wrote: > > That makes sense; but if the packages aren't built on the server, will > > we still be able to display the Haddock docs? > > Presumably it doesn't have to do a full build just to generate the > Haddock, which is the immediate problem. Users can't tell much about > a package without this. That's right. All it needs is to be able to configure. > Is it just errors being thrown by Haddock that's stopping this? > If so, it seems to me that obvious solution is just to link to > whatever html haddock generated, regardless. Haddock generates nothing if there are parse errors in the markup. Duncan From ahey at iee.org Tue Jan 22 06:04:31 2008 From: ahey at iee.org (Adrian Hey) Date: Tue Jan 22 06:04:20 2008 Subject: Quick Hackage question In-Reply-To: <1200997051.5639.482.camel@localhost> References: <47950A06.4020303@iee.org> <1200954579.5883.44.camel@intothevoid> <6d74b0d20801211457wb0ef86dr2e6da81096f1acee@mail.gmail.com> <1200963184.5639.479.camel@localhost> <6d74b0d20801211747wcb463e0w84fe88d79c7f8d54@mail.gmail.com> <4795B814.6010807@iee.org> <1200997051.5639.482.camel@localhost> Message-ID: <4795CDBF.3060103@iee.org> Duncan Coutts wrote: > On Tue, 2008-01-22 at 09:32 +0000, Adrian Hey wrote: >> Judah Jacobson wrote: >>> That makes sense; but if the packages aren't built on the server, will >>> we still be able to display the Haddock docs? >> Presumably it doesn't have to do a full build just to generate the >> Haddock, which is the immediate problem. Users can't tell much about >> a package without this. > > That's right. All it needs is to be able to configure. So is that what's going wrong with packages that aren't haddocked? I guess if some dependencies are missing this might be the case. Maybe a cabal mod would be possible to still enable building of haddock. or just run haddock some other way? or just upload haddock separately, as Judah suggests? (not so keen on this option as it may contain even more broken links). I'm just trying to find out if lack of haddock is deliberate policy, or a problem with hackage, or cabal, or uploaded packages or what, and what (if anything) package authors can do to get their packages properly documented in hackage. >> Is it just errors being thrown by Haddock that's stopping this? >> If so, it seems to me that obvious solution is just to link to >> whatever html haddock generated, regardless. > > Haddock generates nothing if there are parse errors in the markup. But in 99% of cases people will have checked this before they upload, so I don't think this can be what's going wrong. Thanks -- Adrian Hey From gale at sefer.org Tue Jan 22 06:40:50 2008 From: gale at sefer.org (Yitzchak Gale) Date: Tue Jan 22 06:40:37 2008 Subject: Integrating editline with ghc In-Reply-To: <4795BCE9.6080205@dfki.de> References: <6d74b0d20801161305na9e0732m2a6bae7098ec531d@mail.gmail.com> <478F1DB8.1080807@dfki.de> <3089E693-CBAE-463B-97EC-328DAC4E36E5@cse.unsw.edu.au> <47906B7A.6050407@dfki.de> <6BD28026-7344-4A99-9E8D-A55C318BF10E@cse.unsw.edu.au> <4795BCE9.6080205@dfki.de> Message-ID: <2608b8a80801220340h1cb7d244m17e3eebf89c23c45@mail.gmail.com> Christian Maeder wrote: >>> Where are the users that use the functionality not supported by >>> editline's emulation layer? (Shout now or be quiet ever after) > I only wanted to find out which user group would need to change readline > to editline and (if following my suggestion) which group readline to > GPL-readline in cabal files, and which of the two user groups is bigger. > > Since it's not clear yet, what portion of readline can be emulated by > editline this is difficult to estimate. It is always impossible to estimate this, because users are not required to register anyplace, and they are not required to read this or any other discussion list. We should not cause people's programs to break silently by changing a fundamental API, unless there is no alternative. In this case there is a reasonable alternative. Anyone who wants to change over to editline - native or readline-compatible - can easily do so, at their leisure. Anyone who wants things to stay the way they are can do nothing. Do you see any problem with that approach? I think that in most cases, people are happy with readline and will not need to change. Nevertheless, making editline available in this way is critically important, because certain projects are difficult or impossible without it. And of course, it's a great improvement for the Mac platform. So your work on this is highly appreciated. Thanks, Yitz From simonmarhaskell at gmail.com Tue Jan 22 06:52:21 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Tue Jan 22 06:52:16 2008 Subject: Integrating editline with ghc In-Reply-To: <4794D21F.6080201@dfki.de> References: <6d74b0d20801161305na9e0732m2a6bae7098ec531d@mail.gmail.com> <478F1DB8.1080807@dfki.de> <6d74b0d20801180909p38e51531sffcf53d1c41decdd@mail.gmail.com> <47947687.6020604@dfki.de> <2608b8a80801210518k6c59d34cl893b2a081739af91@mail.gmail.com> <4794A883.2070903@dfki.de> <4794C037.90609@gmail.com> <4794D21F.6080201@dfki.de> Message-ID: <4795D8F5.2000405@gmail.com> Christian Maeder wrote: > Simon Marlow wrote: >> It would be a bad idea to remove functionality from the readline >> package. It's a binding to the GNU readline library, and as such it does >> a fine job. > > I only want to move (not remove). I don't think it's necessary to remove (or move) anything from readline at all. That would break clients unnecessarily. By all means add a new module that exports the lowest-common-denominator API. >> For convenience, we would like there to be an API that can be supported >> by both readline and editline. It would be a bad idea for this to be a >> package, because (as I mentioned earlier on libraries@) that package >> would have a variant license, depending on whether the API-provider was >> readline or editline at build-time (or perhaps in the future link-time >> or run-time). If you chose between readline and editline, then you have >> to make an explicit choice in your .cabal file - making a package that >> abstracts this choice is not good, unless said package is explicitly GPL'd. > > Actually, the license is not (so) important for me. I basically want the > convenience to link against libedit on Macs and against libreadline on > other unix system, because these libs are usually there without further ado. But other people really do care about licenses, and it's vitally important that each package has a clearly-defined license. Under my proposal you would be able to do exactly what you want. The difference is that you can't hide the choice between libedit and libreadline in a package of its own, unless that package is GPL. >> So the compatible API could be in a module that is exposed by *both* >> readline and editline, say System.Console.ReadlineCompat. So your >> source code wouldn't have to change to switch from one to the other, >> just your .cabal file. > > Things ghc does not support, users have to do. This isn't about GHC, it's about the readline/editline packages! Cheers, Simon From ross at soi.city.ac.uk Tue Jan 22 07:20:07 2008 From: ross at soi.city.ac.uk (Ross Paterson) Date: Tue Jan 22 07:20:01 2008 Subject: Quick Hackage question In-Reply-To: <4795CDBF.3060103@iee.org> References: <47950A06.4020303@iee.org> <1200954579.5883.44.camel@intothevoid> <6d74b0d20801211457wb0ef86dr2e6da81096f1acee@mail.gmail.com> <1200963184.5639.479.camel@localhost> <6d74b0d20801211747wcb463e0w84fe88d79c7f8d54@mail.gmail.com> <4795B814.6010807@iee.org> <1200997051.5639.482.camel@localhost> <4795CDBF.3060103@iee.org> Message-ID: <20080122122007.GA10821@soi.city.ac.uk> On Tue, Jan 22, 2008 at 11:04:31AM +0000, Adrian Hey wrote: > So is that what's going wrong with packages that aren't haddocked? Often they just haven't been processed yet. It's not yet a fully automated process, though that is the aim. There's an extra delay at the moment because I'm switching it to the new version of haddock, and have struck a few glitches that I'll post about shortly. (COrdering and AvlTree are fine, though.) > I guess if some dependencies are missing this might be the case. At present Cabal has no way to specify a dependency on a foreign library, so that could cause a build failure, but the docs can still be generated. However if a package can't be built, it can't be installed, and any packages that depend on it cannot be configured, so no docs for those. > I'm just trying to find out if lack of haddock is deliberate policy, > or a problem with hackage, or cabal, or uploaded packages or what, and > what (if anything) package authors can do to get their packages properly > documented in hackage. No deliberate policy, and nothing you should or can do. The docs will appear shortly. > But in 99% of cases people will have checked this before they > upload, so I don't think this can be what's going wrong. You'd think people would check this before releasing, but 99% is an overestimate. From Christian.Maeder at dfki.de Tue Jan 22 07:29:53 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Tue Jan 22 07:29:45 2008 Subject: Integrating editline with ghc In-Reply-To: <2608b8a80801220340h1cb7d244m17e3eebf89c23c45@mail.gmail.com> References: <6d74b0d20801161305na9e0732m2a6bae7098ec531d@mail.gmail.com> <478F1DB8.1080807@dfki.de> <3089E693-CBAE-463B-97EC-328DAC4E36E5@cse.unsw.edu.au> <47906B7A.6050407@dfki.de> <6BD28026-7344-4A99-9E8D-A55C318BF10E@cse.unsw.edu.au> <4795BCE9.6080205@dfki.de> <2608b8a80801220340h1cb7d244m17e3eebf89c23c45@mail.gmail.com> Message-ID: <4795E1C1.9020506@dfki.de> Yitzchak Gale wrote: > We should not cause people's programs to break silently by > changing a fundamental API, unless there is no alternative. > In this case there is a reasonable alternative. Anyone who wants > to change over to editline - native or readline-compatible - can > easily do so, at their leisure. Anyone who wants things to stay > the way they are can do nothing. 1. Things don't break silently (I hope), they break during compilation. 2. With every new ghc major version (or library version) there is a list of user visible changes. 3. if ghci is going to use editline (at least on Macs by default) then readline would not need to be a core package und users might need to install package readline explicitely. (Then at least everybody using readline has to do something manually, at least users on Macs who complain most if something does not run out of the box.) > Do you see any problem with that approach? No, I've only pointed out the alternative, I hope. I don't know what fits the needs of the majority most. Let's vote? Christian From robdockins at fastmail.fm Tue Jan 22 08:22:06 2008 From: robdockins at fastmail.fm (Robert Dockins) Date: Tue Jan 22 07:54:09 2008 Subject: Readline read_history and write_history addition In-Reply-To: <2BF2D3FF-089E-4A6F-83D4-C162D4F696B9@gmail.com> References: <57526e770801182310r2e44c662wd513465d71e67bda@mail.gmail.com> <57526e770801212034g790f1671p38d47b681bd687bb@mail.gmail.com> <2BF2D3FF-089E-4A6F-83D4-C162D4F696B9@gmail.com> Message-ID: <200801220822.06632.robdockins@fastmail.fm> On Tuesday 22 January 2008 12:00:51 am Sterling Clover wrote: > It seems to me that the proper solution would be to throw the proper > exception for the errno, warning of such an exception clearly in the > documentation. If the user of the library wants to swallow the > exception themselves and continue with a catch or bracket statement, > they should have that option, but they should also have the > flexibility to handle exceptions in a particular way, should they > need that functionality. There's no reason a library binding should > conceal any potentially useful functionality of the underlying > library. If the errors that were returned were unique, Either String > Bool might be an option, but as we've got a built-in standard for > handling precisely the sorts of IO errors that are returned, it seems > silly not to use it. I agree. For reference, the way I have handled this myself up to now is: foreign import ccall "readline/history.h read_history" read_history :: CString -> IO Errno doReadHistory :: FilePath -> IO () doReadHistory path = do err <- withCString path read_history if err == eOK then return () else ioError $ errnoToIOError "System.Console.Shell.Backend.Readline.doReadHistory" err Nothing (Just path) I think it's a pretty good solution. > --S > > On Jan 21, 2008, at 11:34 PM, Alexander Dunlap wrote: > > On Jan 21, 2008 10:27 AM, Judah Jacobson > > > > wrote: > >> One more suggestion, from Robert Dockins (author of the Shellac and > >> > >> Shellac-readline packages): > >>> The only concern I have is that this patch doesn't seem to > >>> be handling errors properly. read_history and write_history > >>> should return > >>> errno, but this binding has them returning (). These functions > >>> do file > >>> operations and therefore can fail; we want (be able) to know when > >>> that > >>> happens. > >> > >> I think we should just throw an error if those functions return a > >> nonzero value; for example, we already do that in the functions > >> readInitFile and parseAndBind. > >> > >> Thanks, > >> -Judah > > > > I'm reluctant to use the throw an error solution because these > > functions failing does not have to be the end of the world (or even > > necessarily handled by the application). If the history file can't be > > found, the user just doesn't get their history restored (in fact, this > > may not even be a problem: if the user hasn't used the application > > before, readHistory will fail silently on the first run and then work > > fine after the history has been saved at the end of the first > > session). Similarly, writing or appending to the history file is > > generally not an essential task and can fail without terminating the > > program. (I know there's catch, but I don't think the programmer even > > has to worry about it that much.) I think that just returning a value > > for success and a value for failure would be appropriate. > > > > However, I'm not sure how we would implement it without using error. > > The usual Haskell solution would be to use Maybe, but what would we > > have Just of, since the functions don't return real values? Is Just () > > an accepted idiom? (I've never seen it, but I haven't seen all the > > Haskell there is to see, either.) > > > > Thanks. > > Alex > > _______________________________________________ > > 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 simonmarhaskell at gmail.com Tue Jan 22 09:04:16 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Tue Jan 22 09:04:06 2008 Subject: filepath In-Reply-To: <475E9D16.2070809@gmail.com> References: <20071209133413.GA20930@matrix.chaos.earth.li> <404396ef0712091317n5531bf6l8e2ef2f7c768a642@mail.gmail.com> <20071209222359.GB31745@matrix.chaos.earth.li> <475E9D16.2070809@gmail.com> Message-ID: <4795F7E0.60509@gmail.com> Simon Marlow wrote: > Ian Lynagh wrote: >> On Sun, Dec 09, 2007 at 09:17:56PM +0000, Neil Mitchell wrote: >>>> Prelude System.FilePath> splitFileName "foo" >>>> ("","foo") >>> I'd say this was expected. In a similar way, takeDirectory "foo" gives >>> "", not "./". >> >> I'd expect takeDirectory "foo" to be "." and dropFileName "foo" to be >> "./" too. > > Right, me too. > > But this is more of a pervasive design choice. It looks like > System.FilePath consistently treats "" as a valid FilePath meaning "the > current directory", and this would mean changing that policy. > > As far as System.Directory is concerned, "" is not a valid FilePath > (i.e. you can't say getDirectoryContents ""), and the current directory > is denoted by ".". So it would seem sensible for System.FilePath to > behave in the same way. [ reviving an old thread ] I've just come across this again. It's quite inconvenient that takeDirectory "foo" == "" because it means that you can't say doesDirectoryExist (takeDirectory f) in other words, takeDirectory doesn't return a valid directory, at least as far as the OS is concerned. Neil - is it possible to change this? Cheers, Simon From ndmitchell at gmail.com Tue Jan 22 09:18:35 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Tue Jan 22 09:18:21 2008 Subject: filepath In-Reply-To: <4795F7E0.60509@gmail.com> References: <20071209133413.GA20930@matrix.chaos.earth.li> <404396ef0712091317n5531bf6l8e2ef2f7c768a642@mail.gmail.com> <20071209222359.GB31745@matrix.chaos.earth.li> <475E9D16.2070809@gmail.com> <4795F7E0.60509@gmail.com> Message-ID: <404396ef0801220618k7cfe57d6u88ce4f10a6c30989@mail.gmail.com> Hi Simon > I've just come across this again. It's quite inconvenient that > > takeDirectory "foo" == "" > > because it means that you can't say > > doesDirectoryExist (takeDirectory f) Yes, I came across this the other day. And am leaning towards agreeing with you. I think its reasonable if splitFileName keeps the same behaviour, and dropFileName as well, but takeDirectory follows the new behaviour. So: takeDirectory "foo" = "." takeDirectory "foo/bar" = "foo" dropFileName "foo" = "" dropFilename "foo/bar" = "foo/" Does that sound like a plan that suits everyone? Thanks Neil From gale at sefer.org Tue Jan 22 09:24:24 2008 From: gale at sefer.org (Yitzchak Gale) Date: Tue Jan 22 09:24:11 2008 Subject: Integrating editline with ghc In-Reply-To: <4795E1C1.9020506@dfki.de> References: <6d74b0d20801161305na9e0732m2a6bae7098ec531d@mail.gmail.com> <478F1DB8.1080807@dfki.de> <3089E693-CBAE-463B-97EC-328DAC4E36E5@cse.unsw.edu.au> <47906B7A.6050407@dfki.de> <6BD28026-7344-4A99-9E8D-A55C318BF10E@cse.unsw.edu.au> <4795BCE9.6080205@dfki.de> <2608b8a80801220340h1cb7d244m17e3eebf89c23c45@mail.gmail.com> <4795E1C1.9020506@dfki.de> Message-ID: <2608b8a80801220624g4f3b7f6m1bc6ebdbba48e3e5@mail.gmail.com> Christian Maeder wrote: > 3. if ghci is going to use editline... then readline would not > need to be a core package und users might need to > install package readline explicitly. OK, I get it. Even if we leave readline as it is, so that the package system will theoretically not force the person to take action, in practice action will be needed the next time the person upgrades GHC. So you would like to minimize overall work of changing packages over all users. Even so, I think it is more important to minimize confusion over users who are not aware of this whole discussion, and may have minimal knowledge of the package system. They don't want to have to figure things out - they just want it to keep working as before. The need to re-install some package due to the shrinking GHC library core is an annoyance all GHC users are aware of by now. You figure out what has disappeared, and you install it. Changing the semantics of the readline package would add to the confusion, I believe. Also, I think in general we should do what makes the most sense within the package system itself. GHC library core shrinkage is an external issue, though I agree that in practice it will affect everyone. So I am still in favor of keeping readline as it is. Thanks, Yitz From simonmarhaskell at gmail.com Tue Jan 22 09:38:59 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Tue Jan 22 09:38:50 2008 Subject: filepath In-Reply-To: <404396ef0801220618k7cfe57d6u88ce4f10a6c30989@mail.gmail.com> References: <20071209133413.GA20930@matrix.chaos.earth.li> <404396ef0712091317n5531bf6l8e2ef2f7c768a642@mail.gmail.com> <20071209222359.GB31745@matrix.chaos.earth.li> <475E9D16.2070809@gmail.com> <4795F7E0.60509@gmail.com> <404396ef0801220618k7cfe57d6u88ce4f10a6c30989@mail.gmail.com> Message-ID: <47960003.3090702@gmail.com> Neil Mitchell wrote: > Hi Simon > >> I've just come across this again. It's quite inconvenient that >> >> takeDirectory "foo" == "" >> >> because it means that you can't say >> >> doesDirectoryExist (takeDirectory f) > > Yes, I came across this the other day. And am leaning towards agreeing with you. > > I think its reasonable if splitFileName keeps the same behaviour, and > dropFileName as well, but takeDirectory follows the new behaviour. So: > > takeDirectory "foo" = "." > takeDirectory "foo/bar" = "foo" > > dropFileName "foo" = "" > dropFilename "foo/bar" = "foo/" > > Does that sound like a plan that suits everyone? That seems strange, actually. I would expect, perhaps naively, that takeDirectory == fst . splitFileName dropFileName == takeDirectory is there a good reason for these not to be true? Cheers, Simon From Malcolm.Wallace at cs.york.ac.uk Tue Jan 22 10:05:42 2008 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Tue Jan 22 10:27:02 2008 Subject: Integrating editline with ghc In-Reply-To: <2608b8a80801220624g4f3b7f6m1bc6ebdbba48e3e5@mail.gmail.com> References: <6d74b0d20801161305na9e0732m2a6bae7098ec531d@mail.gmail.com> <478F1DB8.1080807@dfki.de> <3089E693-CBAE-463B-97EC-328DAC4E36E5@cse.unsw.edu.au> <47906B7A.6050407@dfki.de> <6BD28026-7344-4A99-9E8D-A55C318BF10E@cse.unsw.edu.au> <4795BCE9.6080205@dfki.de> <2608b8a80801220340h1cb7d244m17e3eebf89c23c45@mail.gmail.com> <4795E1C1.9020506@dfki.de> <2608b8a80801220624g4f3b7f6m1bc6ebdbba48e3e5@mail.gmail.com> Message-ID: <20080122150542.6aa711dc.Malcolm.Wallace@cs.york.ac.uk> > I think it is more important to minimize confusion > over users who are not aware of this whole discussion, > and may have minimal knowledge of the package system. > They don't want to have to figure things out - they just > want it to keep working as before. I think I am persuaded that this is the most important goal: stability of the API and package interface, for existing clients of readline. If individual projects would like to migrate from using readline to using editline, then those are the ones that should pay the small amount of pain (in using CPP, package configurations, etc) to manage the change. Anyone else should be totally unaffected. Regards, Malcolm From gale at sefer.org Tue Jan 22 10:36:32 2008 From: gale at sefer.org (Yitzchak Gale) Date: Tue Jan 22 10:36:19 2008 Subject: Readline read_history and write_history addition In-Reply-To: <200801220822.06632.robdockins@fastmail.fm> References: <57526e770801182310r2e44c662wd513465d71e67bda@mail.gmail.com> <57526e770801212034g790f1671p38d47b681bd687bb@mail.gmail.com> <2BF2D3FF-089E-4A6F-83D4-C162D4F696B9@gmail.com> <200801220822.06632.robdockins@fastmail.fm> Message-ID: <2608b8a80801220736q2cf695e2w81bb93f1b80d446a@mail.gmail.com> Sterling Clover wrote: >> ...as we've got a built-in standard for >> handling precisely the sorts of IO errors that are returned, it seems >> silly not to use it. IO exceptions wreak havoc on programs using any instance of MonadIO other than IO itself. At best, you need a major reorganization of your entire program. At worst, it can make it completely impossible to write a library. The built-in standard that you are referring to is fine for when something happens that makes it impossible for the program to continue - out of memory, hard disk failure, etc. But in cases where it is possible to return a meaningful value and continue, why be so disruptive? As Robert Dockins pointed out, it is very easy for those who prefer an IO exception to throw one themselves. The opposite can be difficult or impossible. Thanks, Yitz From Christian.Maeder at dfki.de Tue Jan 22 10:55:58 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Tue Jan 22 10:55:48 2008 Subject: Integrating editline with ghc In-Reply-To: <20080122150542.6aa711dc.Malcolm.Wallace@cs.york.ac.uk> References: <6d74b0d20801161305na9e0732m2a6bae7098ec531d@mail.gmail.com> <478F1DB8.1080807@dfki.de> <3089E693-CBAE-463B-97EC-328DAC4E36E5@cse.unsw.edu.au> <47906B7A.6050407@dfki.de> <6BD28026-7344-4A99-9E8D-A55C318BF10E@cse.unsw.edu.au> <4795BCE9.6080205@dfki.de> <2608b8a80801220340h1cb7d244m17e3eebf89c23c45@mail.gmail.com> <4795E1C1.9020506@dfki.de> <2608b8a80801220624g4f3b7f6m1bc6ebdbba48e3e5@mail.gmail.com> <20080122150542.6aa711dc.Malcolm.Wallace@cs.york.ac.uk> Message-ID: <4796120E.8060101@dfki.de> Malcolm Wallace wrote: > I think I am persuaded that this is the most important goal: stability > of the API and package interface, for existing clients of readline. If > individual projects would like to migrate from using readline to using > editline, then those are the ones that should pay the small amount of > pain (in using CPP, package configurations, etc) to manage the change. > > Anyone else should be totally unaffected. I would like to know from package maintainers if there packages can be easily ported from libreadline to libedit. The best indication for this would be if the package is also happy with a restricted interface of readline (i.e. readline-compat) or requires the full GNU readline. At least testing this compatibility makes sense using a readline package with a temporarily reduced interface (without the need to change the packages depending on readline.) Christian From Christian.Maeder at dfki.de Tue Jan 22 11:28:46 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Tue Jan 22 11:28:37 2008 Subject: Integrating editline with ghc In-Reply-To: <4796120E.8060101@dfki.de> References: <6d74b0d20801161305na9e0732m2a6bae7098ec531d@mail.gmail.com> <478F1DB8.1080807@dfki.de> <3089E693-CBAE-463B-97EC-328DAC4E36E5@cse.unsw.edu.au> <47906B7A.6050407@dfki.de> <6BD28026-7344-4A99-9E8D-A55C318BF10E@cse.unsw.edu.au> <4795BCE9.6080205@dfki.de> <2608b8a80801220340h1cb7d244m17e3eebf89c23c45@mail.gmail.com> <4795E1C1.9020506@dfki.de> <2608b8a80801220624g4f3b7f6m1bc6ebdbba48e3e5@mail.gmail.com> <20080122150542.6aa711dc.Malcolm.Wallace@cs.york.ac.uk> <4796120E.8060101@dfki.de> Message-ID: <479619BE.5080002@dfki.de> (my previous mail went to the bugs list by accident) Christian Maeder wrote: > I would like to know from package maintainers if there packages can be > easily ported from libreadline to libedit. > > The best indication for this would be if the package is also happy with > a restricted interface of readline (i.e. readline-compat) or requires > the full GNU readline. > > At least testing this compatibility makes sense using a readline package > with a temporarily reduced interface (without the need to change the > packages depending on readline.) In short, consider a split up of the readline package into readline-basics and readline-exts (both with GPL licence). Unfortunately it is not possible to have the package readline to be the union of readline-basics and readline-exts. So readline-basic (or readline-compat) would be a duplication of a reduced readline package. For porting packages from libreadline to libedit it would be sufficient to replace readline-basics with editline (and change the licence) in *.cabal files. Packages depending on more then readline-basics cannot be ported. I'm only worried if any package maintainer would bother to change the build-depends from readline to readline-basic (if not forced to change it anyway, i.e. to readline-basic and readline-ext). Alternatively, if the interface of readline is reduced to that of readline-basic, package maintainers could hope that their package is still okay and if not (after compilation errors) add readline-ext to their build-depends. Is this really such a crazy idea? Christian From bringert at cs.chalmers.se Tue Jan 22 11:31:01 2008 From: bringert at cs.chalmers.se (=?ISO-8859-1?Q?Bj=F6rn_Bringert?=) Date: Tue Jan 22 11:29:24 2008 Subject: Network.CGI changes In-Reply-To: <20080121120147.GP11635@a5.repetae.net> References: <20080121001407.GA3695@a5.repetae.net> <47945CE6.6080409@imn.htwk-leipzig.de> <20080121120147.GP11635@a5.repetae.net> Message-ID: <47961A45.2090706@cs.chalmers.se> Hi Frederik, (I'm CC:ing the libraries list, so that anyone who wants to have Network.CGI.Compat back in the cgi package can shout.) That exact module actually used to exist in the cgi package as well (it implemented the complete API of the old Network.CGI), but after a few releases I removed it since it didn't seem to have any users. That was quite a long time ago, and you are the first person to complain. The purpose of cgi-compat is actually not to provide Network.CGI.Compat, but rather to be installable on older GHC versions, hence the main module name Network.NewCGI. I'm not sure if there is sufficient demand for adding Network.CGI.Compat back into the cgi package. The old Network.CGI seemed to have very few users, due to to it's restrictions. You can always get Network.CGI.Compat from here, and include it in your program: http://www.cs.chalmers.se/~bringert/darcs/cgi-compat/Network/CGI/Compat.hs /Bj?rn Frederik Eaton wrote: > Dear Johannes, > > Thanks, that works for me. > > Bjorn, perhaps it would be easier to put these five lines in a module > (Network.CGI.Compat?) in the new package, rather than having people > maintain and download a separate cgi-compat package? Perhaps the two > other functions in the old CGI interface can be implemented in terms > of the new API as well? > > Best wishes, > > Frederik > > On Mon, Jan 21, 2008 at 09:50:46AM +0100, Johannes Waldmann wrote: >> If you need the old "wrapper" function, then use something like this: >> >> wrapper :: ([(String,String)] -> IO Html) -> IO () >> wrapper f = runCGI $ do >> >> e <- getInputs >> a <- lift $ f $ e >> output $ renderHtml a >> >> best regards, Johannes Waldmann. >> > From frederik at a5.repetae.net Tue Jan 22 12:28:34 2008 From: frederik at a5.repetae.net (Frederik Eaton) Date: Tue Jan 22 12:28:25 2008 Subject: Network.CGI changes In-Reply-To: <47961A45.2090706@cs.chalmers.se> References: <20080121001407.GA3695@a5.repetae.net> <47945CE6.6080409@imn.htwk-leipzig.de> <20080121120147.GP11635@a5.repetae.net> <47961A45.2090706@cs.chalmers.se> Message-ID: <20080122172834.GV11635@a5.repetae.net> Hi Bjorn, Well, I don't know what the solution is. As I have said, I think it would be best to keep Network.CGI.Compat. That way, users of the old module just have to change the module name, plus they don't have to hack cgi-compat to get it to compile when cgi is already working. A typical project of mine uses 10 or more packages, and something that makes me reluctant to use Haskell is the experience that after a few years I will end up having to maintain separate versions of significant numbers of those packages if I want something I wrote to stay working. Haskell is supposed to be good for writing large projects, but large projects need stable libraries or they become a maintenance nightmare. It's rather worrying to see that people seem to think that if I don't have time to participate actively in the mailing lists or upload stuff to hackage, then my code doesn't exist... Maybe there is a high cost to keeping Network.CGI.Compat in the cgi package, but I don't see any reason other than an aesthetics, which seems like less of a priority than backwards compatibility. Frederik On Tue, Jan 22, 2008 at 05:31:01PM +0100, Bj?rn Bringert wrote: > Hi Frederik, > > (I'm CC:ing the libraries list, so that anyone who wants to have Network.CGI.Compat back in > the cgi package can shout.) > > That exact module actually used to exist in the cgi package as well (it implemented the > complete API of the old Network.CGI), but after a few releases I removed it since it didn't > seem to have any users. That was quite a long time ago, and you are the first person to > complain. > > The purpose of cgi-compat is actually not to provide Network.CGI.Compat, but rather to be > installable on older GHC versions, hence the main module name Network.NewCGI. > > I'm not sure if there is sufficient demand for adding Network.CGI.Compat back into the cgi > package. The old Network.CGI seemed to have very few users, due to to it's restrictions. > You can always get Network.CGI.Compat from here, and include it in your program: > http://www.cs.chalmers.se/~bringert/darcs/cgi-compat/Network/CGI/Compat.hs > > /Bj?rn > > Frederik Eaton wrote: > >Dear Johannes, > >Thanks, that works for me. > >Bjorn, perhaps it would be easier to put these five lines in a module > >(Network.CGI.Compat?) in the new package, rather than having people > >maintain and download a separate cgi-compat package? Perhaps the two > >other functions in the old CGI interface can be implemented in terms > >of the new API as well? > >Best wishes, > >Frederik > >On Mon, Jan 21, 2008 at 09:50:46AM +0100, Johannes Waldmann wrote: > >>If you need the old "wrapper" function, then use something like this: > >> > >>wrapper :: ([(String,String)] -> IO Html) -> IO () > >>wrapper f = runCGI $ do > >> > >> e <- getInputs > >> a <- lift $ f $ e > >> output $ renderHtml a > >> > >>best regards, Johannes Waldmann. > >> > -- http://ofb.net/~frederik/ From igloo at earth.li Tue Jan 22 17:13:26 2008 From: igloo at earth.li (Ian Lynagh) Date: Tue Jan 22 17:13:12 2008 Subject: Readline read_history and write_history addition In-Reply-To: <57526e770801212034g790f1671p38d47b681bd687bb@mail.gmail.com> References: <57526e770801182310r2e44c662wd513465d71e67bda@mail.gmail.com> <6d74b0d20801191109m4c484a44x96e83abb528b2277@mail.gmail.com> <57526e770801191543u71ad5c52r2edd09387c8fe870@mail.gmail.com> <6d74b0d20801211027v621580b2k6584eb3b24bf8320@mail.gmail.com> <57526e770801212034g790f1671p38d47b681bd687bb@mail.gmail.com> Message-ID: <20080122221326.GA20619@matrix.chaos.earth.li> On Mon, Jan 21, 2008 at 08:34:50PM -0800, Alexander Dunlap wrote: > > However, I'm not sure how we would implement it without using error. > The usual Haskell solution would be to use Maybe, but what would we > have Just of, since the functions don't return real values? Is Just () > an accepted idiom? Bool would be nicer than that, but presumably these functions can fail in a number of ways, so better still would be Maybe Exception or Maybe IOError. I think in my opinion throwing an exception is best, though. People using MonadIO can convert this into the variant that doesn't throw an exception by replacing readlineFunction args with something like (try $ readlineFunction args) >> return () Thanks Ian From gale at sefer.org Tue Jan 22 18:49:34 2008 From: gale at sefer.org (Yitzchak Gale) Date: Tue Jan 22 18:49:24 2008 Subject: Readline read_history and write_history addition In-Reply-To: <20080122221326.GA20619@matrix.chaos.earth.li> References: <57526e770801182310r2e44c662wd513465d71e67bda@mail.gmail.com> <6d74b0d20801191109m4c484a44x96e83abb528b2277@mail.gmail.com> <57526e770801191543u71ad5c52r2edd09387c8fe870@mail.gmail.com> <6d74b0d20801211027v621580b2k6584eb3b24bf8320@mail.gmail.com> <57526e770801212034g790f1671p38d47b681bd687bb@mail.gmail.com> <20080122221326.GA20619@matrix.chaos.earth.li> Message-ID: <2608b8a80801221549k41b193cq303a3847f98554e1@mail.gmail.com> Ian Lynagh wrote: > People using MonadIO can convert this into the variant that doesn't > throw an exception by replacing > readlineFunction args > with something like > (try $ readlineFunction args) >> return () That's in the IO monad, so not always available. Here's an example: In a library, you have a function that starts up an external system, runs a calculation, then shuts down the external system. Like this: bracketSystem :: MonadIO m => m a -> m a bracketSystem x = do startUpSystem ret <- x shutDownSystem return ret Now you would really like to wrap that in bracket to make sure that "shutDownSystem" is called even when an IO exception is thrown. But unfortunately, bracket is currently not available for MonadIO, nor is there any way to emulate it AFIK. (This is a "maybe" for HaskellPrime: http://hackage.haskell.org/trac/haskell-prime/ticket/110) So the best you can do is make sure not to do anything inside "x" that is likely to throw an IO exception. That way, you'll only be left with zombies and other mess when the hard disk fills up, or other rare and serious conditions. If we start throwing IO exceptions for common and minor occurrences like no readline history available, libraries like this become impossible to write in Haskell. And code that has already been written becomes unusable. Thanks, Yitz From igloo at earth.li Tue Jan 22 19:51:11 2008 From: igloo at earth.li (Ian Lynagh) Date: Tue Jan 22 19:50:58 2008 Subject: Readline read_history and write_history addition In-Reply-To: <2608b8a80801221549k41b193cq303a3847f98554e1@mail.gmail.com> References: <57526e770801182310r2e44c662wd513465d71e67bda@mail.gmail.com> <6d74b0d20801191109m4c484a44x96e83abb528b2277@mail.gmail.com> <57526e770801191543u71ad5c52r2edd09387c8fe870@mail.gmail.com> <6d74b0d20801211027v621580b2k6584eb3b24bf8320@mail.gmail.com> <57526e770801212034g790f1671p38d47b681bd687bb@mail.gmail.com> <20080122221326.GA20619@matrix.chaos.earth.li> <2608b8a80801221549k41b193cq303a3847f98554e1@mail.gmail.com> Message-ID: <20080123005111.GA25334@matrix.chaos.earth.li> On Wed, Jan 23, 2008 at 01:49:34AM +0200, Yitzchak Gale wrote: > Ian Lynagh wrote: > > People using MonadIO can convert this into the variant that doesn't > > throw an exception by replacing > > readlineFunction args > > with something like > > (try $ readlineFunction args) >> return () > > That's in the IO monad, so not always available. Everywhere you can write readlineFunction args you can write (try $ readlineFunction args) >> return () The only way you can have problems is if there is a library (that you don't control), which exports a (MonadIO m => m a) that internally calls readlineFunction args and doesn't catch exceptions. Personally I'd say that that is a bug in that other library, and it ought to be catching the exception and either ignoring it, returning some sort of sum type, or also constraining m to be in some sort of MonadError monad. > If we start throwing IO exceptions for common and minor > occurrences like no readline history available Pretty much any actual IO you do has this problem, e.g. readFile on a non-existent file. Thanks Ian From judah.jacobson at gmail.com Tue Jan 22 20:48:08 2008 From: judah.jacobson at gmail.com (Judah Jacobson) Date: Tue Jan 22 20:47:53 2008 Subject: Readline read_history and write_history addition In-Reply-To: <2608b8a80801221549k41b193cq303a3847f98554e1@mail.gmail.com> References: <57526e770801182310r2e44c662wd513465d71e67bda@mail.gmail.com> <6d74b0d20801191109m4c484a44x96e83abb528b2277@mail.gmail.com> <57526e770801191543u71ad5c52r2edd09387c8fe870@mail.gmail.com> <6d74b0d20801211027v621580b2k6584eb3b24bf8320@mail.gmail.com> <57526e770801212034g790f1671p38d47b681bd687bb@mail.gmail.com> <20080122221326.GA20619@matrix.chaos.earth.li> <2608b8a80801221549k41b193cq303a3847f98554e1@mail.gmail.com> Message-ID: <6d74b0d20801221748p5926bfaauf725e818374134b6@mail.gmail.com> On Jan 22, 2008 3:49 PM, Yitzchak Gale wrote: > > In a library, you have a function that starts up an > external system, runs a calculation, then shuts > down the external system. Like this: > > bracketSystem :: MonadIO m => m a -> m a > bracketSystem x = do > startUpSystem > ret <- x > shutDownSystem > return ret > > Now you would really like to wrap that in bracket > to make sure that "shutDownSystem" is called even > when an IO exception is thrown. But unfortunately, > bracket is currently not available for MonadIO, > nor is there any way to emulate it AFIK. > (This is a "maybe" for HaskellPrime: > http://hackage.haskell.org/trac/haskell-prime/ticket/110) Following is what I've been using to solve that problem. I can add it to that HaskellPrime ticket if people think it's useful. ============== module IO1 where import Control.Monad.State import Control.Monad.Error import Control.Exception import System.IO class MonadIO m => MonadIO1 m where liftIO1 :: (forall b . IO b -> IO b) -> m a -> m a instance MonadIO1 IO where liftIO1 = id instance MonadIO1 m => MonadIO1 (StateT s m) where liftIO1 f = mapStateT (liftIO1 f) instance (Error e, MonadIO1 m) => MonadIO1 (ErrorT e m) where liftIO1 f = mapErrorT (liftIO1 f) -- and so on for ReaderT, ListT, etc. block1, unblock1 :: MonadIO1 m => m a -> m a block1 = liftIO1 block unblock1 = liftIO1 unblock bracket1 :: MonadIO1 m => m a -> (a -> IO b) -> (a -> m c) -> m c bracket1 before after thing = block1 $ do a <- before r <- liftIO1 (handle (\e -> do {after a; throw e})) (unblock1 (thing a)) liftIO (after a) return r -- example: bracket file operations in an arbitrary monad withFile1 :: MonadIO1 m => FilePath -> IOMode -> (Handle -> m a) -> m a withFile1 name mode = bracket1 (liftIO (openFile name mode)) hClose ============== Note that in bracket1, the "after" action must run in IO. In practice, that hasn't been a problem for me. In fact, since the "after" clause might run in response to an asynchronous exception, I don't see how it could be sequenced with an arbitrary monad, anyway. Best wishes, -Judah From lemming at henning-thielemann.de Wed Jan 23 01:54:41 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed Jan 23 01:54:26 2008 Subject: Exceptions vs. Errors (Re: Readline read_history and write_history addition) In-Reply-To: <2608b8a80801221549k41b193cq303a3847f98554e1@mail.gmail.com> References: <57526e770801182310r2e44c662wd513465d71e67bda@mail.gmail.com> <6d74b0d20801191109m4c484a44x96e83abb528b2277@mail.gmail.com> <57526e770801191543u71ad5c52r2edd09387c8fe870@mail.gmail.com> <6d74b0d20801211027v621580b2k6584eb3b24bf8320@mail.gmail.com> <57526e770801212034g790f1671p38d47b681bd687bb@mail.gmail.com> <20080122221326.GA20619@matrix.chaos.earth.li> <2608b8a80801221549k41b193cq303a3847f98554e1@mail.gmail.com> Message-ID: On Wed, 23 Jan 2008, Yitzchak Gale wrote: > If we start throwing IO exceptions for common and minor > occurrences like no readline history available, libraries like > this become impossible to write in Haskell. And code > that has already been written becomes unusable. It seems that this discussion has no longer to do with readline but with correct exception handling in Haskell. Did someone follow my links to the Haskell wiki articles Error and Exception? Haskell libraries mix these terms in an unfortunate way. Events like "no history available" are precisely the things that are called "exceptions" (not errors) - situations that cannot be avoided by the programmer but must be handled. An approved method to handle these cases are 'try' constructs. Now if 'bracket' does not work for general MonadIO then it should be generalized. From gale at sefer.org Wed Jan 23 05:39:52 2008 From: gale at sefer.org (Yitzchak Gale) Date: Wed Jan 23 05:39:35 2008 Subject: Exceptions vs. Errors (Re: Readline read_history and write_history addition) In-Reply-To: References: <57526e770801182310r2e44c662wd513465d71e67bda@mail.gmail.com> <6d74b0d20801191109m4c484a44x96e83abb528b2277@mail.gmail.com> <57526e770801191543u71ad5c52r2edd09387c8fe870@mail.gmail.com> <6d74b0d20801211027v621580b2k6584eb3b24bf8320@mail.gmail.com> <57526e770801212034g790f1671p38d47b681bd687bb@mail.gmail.com> <20080122221326.GA20619@matrix.chaos.earth.li> <2608b8a80801221549k41b193cq303a3847f98554e1@mail.gmail.com> Message-ID: <2608b8a80801230239x3c6a992ax63f3af84f01899d3@mail.gmail.com> Henning Thielemann wrote: > http://www.haskell.org/haskellwiki/Exception > http://www.haskell.org/haskellwiki/Error The exact usage of the terms "error" and "exception" varies between programming languages. Your descriptions on the wiki follow Java usage, where Error and Exception are separate subclasses of Throwable. In Python, "exception" means the program flow construct, and "error" means a condition in which an exception is raised due to something going "wrong", so StandardError is a subclass of Exception. There are other conventions. In Haskell, the usage is, let's just say, unusual. :) Perhaps some technolinguist will have a good time studying it some day. I wrote: >> If we start throwing IO exceptions for common and minor >> occurrences like no readline history available, libraries like >> this become impossible to write in Haskell. And code >> that has already been written becomes unusable. > ...situations that cannot be avoided by the programmer > but must be handled. An approved method to handle these > cases are 'try' constructs. Approved? The question is: when is it appropriate to use this technique in Haskell? Every function that can return more than one possible value has "situations that must be handled", but usually we will not throw exceptions. > Now if 'bracket' does not work for general > MonadIO then it should be generalized. 'bracket', 'try', and 'catch' do need to be generalized. Realistically, that will not happen for a long time, if ever. The reality is that Haskell's IO exception facilities have some rough edges. They work great for asynchronous errors, which is what they were designed for. In general, whether or not IO exceptions are appropriate in Haskell is heavily dependent upon programming style. The only situation in which they are certainly called for is an asynchronous error. Perhaps also a non-error that satisfies all of the following conditions: E1) The function is strongly in the IO monad. E2) The condition is rare. E3) Sometimes the correct action would be to exit the program with an error message. In any other case, throwing an IO exception is an abuse that might ruin someone's program. If an IO exception is appropriate for the style of a particular program, it is easy for that program to provide one. When writing Haskell bindings for a library written in an imperative language, there is always a tension between providing a more idiomatic Haskell interface and faithfully reproducing the calling semantics of the library. When a C function returns an int to indicate various possible outcomes, that doesn't necessarily mean that it must throw an IO exception in Haskell, even if the author called the int an "error code". E2 and E3 do not hold for in the case of readline history - if were to throw an IO exception in the case of empty history, it would be obligatory for every program using it to wrap the function in a try. There is no way to express that in Haskell; you would have to write that requirement in a comment. That itself is evidence that the semantics of this language construct have been abused. (As contrasted with Java, for example, where ignoring the possible exception would cause the program to be rejected.) Regards, Yitz From lemming at henning-thielemann.de Wed Jan 23 06:14:07 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed Jan 23 06:13:52 2008 Subject: Exceptions vs. Errors (Re: Readline read_history and write_history addition) In-Reply-To: <2608b8a80801230239x3c6a992ax63f3af84f01899d3@mail.gmail.com> References: <57526e770801182310r2e44c662wd513465d71e67bda@mail.gmail.com> <6d74b0d20801191109m4c484a44x96e83abb528b2277@mail.gmail.com> <57526e770801191543u71ad5c52r2edd09387c8fe870@mail.gmail.com> <6d74b0d20801211027v621580b2k6584eb3b24bf8320@mail.gmail.com> <57526e770801212034g790f1671p38d47b681bd687bb@mail.gmail.com> <20080122221326.GA20619@matrix.chaos.earth.li> <2608b8a80801221549k41b193cq303a3847f98554e1@mail.gmail.com> <2608b8a80801230239x3c6a992ax63f3af84f01899d3@mail.gmail.com> Message-ID: On Wed, 23 Jan 2008, Yitzchak Gale wrote: > Henning Thielemann wrote: > > http://www.haskell.org/haskellwiki/Exception > > http://www.haskell.org/haskellwiki/Error > > The exact usage of the terms "error" and "exception" varies > between programming languages. Your descriptions on > the wiki follow Java usage, where Error and Exception > are separate subclasses of Throwable. It's also terminology of Modula-3, from where Java inherits its exception mechanism. And probably its the same terminology in the ancestors of Modula-3. > In Haskell, the usage is, let's just say, unusual. :) Perhaps some > technolinguist will have a good time studying it some day. It would be good if Haskell libraries would separate the two issues, with whatever wording. > I wrote: > >> If we start throwing IO exceptions for common and minor > >> occurrences like no readline history available, libraries like > >> this become impossible to write in Haskell. And code > >> that has already been written becomes unusable. > > > ...situations that cannot be avoided by the programmer > > but must be handled. An approved method to handle these > > cases are 'try' constructs. > > Approved? The question is: when is it appropriate to > use this technique in Haskell? Every function that can > return more than one possible value has "situations > that must be handled", but usually we will not throw > exceptions. You know, in Haskell we do not need a built-in exception handling facility because we can handle it with the elements of the language. Returning an exceptional value or throwing an exception is the same. We can only hide the exception propagation by appropriate binding of actions. > > Now if 'bracket' does not work for general > > MonadIO then it should be generalized. > > 'bracket', 'try', and 'catch' do need to be generalized. > Realistically, that will not happen for a long time, if ever. Why not? We could design standard IO functions with improved API, with exceptions explicitly declared in the type. (One could also get rid of 'hFunction' names and use module name qualification instead.) In the future, when it becomes more usual to install a custom set of packages from Hackage instead of installing a large set of base libraries, people can more easily decide to use this library instead of System.IO. I think ByteString was long awaited and thus was adopted quickly by many programmers. I hope this happens for other solutions, too. > The reality is that Haskell's IO exception facilities have some > rough edges. I remember that I read somewhere that the Haskell veterans regret to having put so much things into IO, whenever they didn't know where to place them correctly. Exceptions are one such thing. Manipulating array in-place is another example. Putting 'fail' method into the Monad class is also acknowledged as a misconception today, and (I hope) most people agree, that there should be a separate class MonadError. Solutions already exist. STArray monad and runST can replace IOArray and unsafePerformIO in a safe way. Control.Monad.Error (which should be called Control.Monad.Exception with a distinct type for exceptions instead of Either) with ErrorT already allows to express in a type safe way what exceptions an action can throw. Maybe one day we succeed keeping exceptions completely out of IO and have them implemented by ErrorT/ExceptionT. From gale at sefer.org Wed Jan 23 06:23:06 2008 From: gale at sefer.org (Yitzchak Gale) Date: Wed Jan 23 06:22:50 2008 Subject: Exceptions vs. Errors (Re: Readline read_history and write_history addition) In-Reply-To: References: <57526e770801182310r2e44c662wd513465d71e67bda@mail.gmail.com> <6d74b0d20801191109m4c484a44x96e83abb528b2277@mail.gmail.com> <57526e770801191543u71ad5c52r2edd09387c8fe870@mail.gmail.com> <6d74b0d20801211027v621580b2k6584eb3b24bf8320@mail.gmail.com> <57526e770801212034g790f1671p38d47b681bd687bb@mail.gmail.com> <20080122221326.GA20619@matrix.chaos.earth.li> <2608b8a80801221549k41b193cq303a3847f98554e1@mail.gmail.com> <2608b8a80801230239x3c6a992ax63f3af84f01899d3@mail.gmail.com> Message-ID: <2608b8a80801230323o187b4b91v86a46736e32b03b5@mail.gmail.com> Hi Henning, I am going to make an "exception" here to my usual policy of not top-posting. Because I agree with everything you wrote. :) -Yitz On Jan 23, 2008 1:14 PM, Henning Thielemann wrote: > > On Wed, 23 Jan 2008, Yitzchak Gale wrote: > > > Henning Thielemann wrote: > > > http://www.haskell.org/haskellwiki/Exception > > > http://www.haskell.org/haskellwiki/Error > > > > The exact usage of the terms "error" and "exception" varies > > between programming languages. Your descriptions on > > the wiki follow Java usage, where Error and Exception > > are separate subclasses of Throwable. > > It's also terminology of Modula-3, from where Java inherits its exception > mechanism. And probably its the same terminology in the ancestors of > Modula-3. > > > In Haskell, the usage is, let's just say, unusual. :) Perhaps some > > technolinguist will have a good time studying it some day. > > It would be good if Haskell libraries would separate the two issues, with > whatever wording. > > > I wrote: > > >> If we start throwing IO exceptions for common and minor > > >> occurrences like no readline history available, libraries like > > >> this become impossible to write in Haskell. And code > > >> that has already been written becomes unusable. > > > > > ...situations that cannot be avoided by the programmer > > > but must be handled. An approved method to handle these > > > cases are 'try' constructs. > > > > Approved? The question is: when is it appropriate to > > use this technique in Haskell? Every function that can > > return more than one possible value has "situations > > that must be handled", but usually we will not throw > > exceptions. > > You know, in Haskell we do not need a built-in exception handling facility > because we can handle it with the elements of the language. Returning an > exceptional value or throwing an exception is the same. We can only hide > the exception propagation by appropriate binding of actions. > > > > Now if 'bracket' does not work for general > > > MonadIO then it should be generalized. > > > > 'bracket', 'try', and 'catch' do need to be generalized. > > Realistically, that will not happen for a long time, if ever. > > Why not? We could design standard IO functions with improved API, with > exceptions explicitly declared in the type. (One could also get rid of > 'hFunction' names and use module name qualification instead.) In the > future, when it becomes more usual to install a custom set of packages > from Hackage instead of installing a large set of base libraries, people > can more easily decide to use this library instead of System.IO. > I think ByteString was long awaited and thus was adopted quickly by many > programmers. I hope this happens for other solutions, too. > > > The reality is that Haskell's IO exception facilities have some > > rough edges. > > I remember that I read somewhere that the Haskell veterans regret to > having put so much things into IO, whenever they didn't know where to > place them correctly. Exceptions are one such thing. Manipulating array > in-place is another example. Putting 'fail' method into the Monad class is > also acknowledged as a misconception today, and (I hope) most people > agree, that there should be a separate class MonadError. > Solutions already exist. STArray monad and runST can replace IOArray and > unsafePerformIO in a safe way. Control.Monad.Error (which should be called > Control.Monad.Exception with a distinct type for exceptions instead of > Either) with ErrorT already allows to express in a type safe way what > exceptions an action can throw. Maybe one day we succeed keeping > exceptions completely out of IO and have them implemented by > ErrorT/ExceptionT. > From ketil+haskell at ii.uib.no Wed Jan 23 06:32:20 2008 From: ketil+haskell at ii.uib.no (Ketil Malde) Date: Wed Jan 23 06:32:16 2008 Subject: Exceptions vs. Errors (Re: Readline read_history and write_history addition) In-Reply-To: <2608b8a80801230239x3c6a992ax63f3af84f01899d3@mail.gmail.com> (Yitzchak Gale's message of "Wed\, 23 Jan 2008 12\:39\:52 +0200") References: <57526e770801182310r2e44c662wd513465d71e67bda@mail.gmail.com> <6d74b0d20801191109m4c484a44x96e83abb528b2277@mail.gmail.com> <57526e770801191543u71ad5c52r2edd09387c8fe870@mail.gmail.com> <6d74b0d20801211027v621580b2k6584eb3b24bf8320@mail.gmail.com> <57526e770801212034g790f1671p38d47b681bd687bb@mail.gmail.com> <20080122221326.GA20619@matrix.chaos.earth.li> <2608b8a80801221549k41b193cq303a3847f98554e1@mail.gmail.com> <2608b8a80801230239x3c6a992ax63f3af84f01899d3@mail.gmail.com> Message-ID: <87wsq0ixq3.fsf@nmd9999.imr.no> "Yitzchak Gale" writes: > The exact usage of the terms "error" and "exception" varies > between programming languages. Your descriptions on > the wiki follow Java usage, where Error and Exception > are separate subclasses of Throwable. In Python, "exception" > means the program flow construct, and "error" means a > condition in which an exception is raised due to something > going "wrong", so StandardError is a subclass of Exception. > There are other conventions. To me, (what you describe as) the Python terminology seems to be the least confusing. E.g., dividing by zero and failed pattern matches are (run-time!) errors, which raise exceptions. I wouldn't say (like the wiki) that an uncaught exception is an error. > E1) The function is strongly in the IO monad. > E2) The condition is rare. > E3) Sometimes the correct action would be to exit the program > with an error message. I like these criteria. I'd even suggest replacing "Sometimes" with "Commonly" in E3. And add that there should be no obvious, general way to deal with the error (but then there probably wouldn't be an error in the first place). > E2 and E3 do not hold for in the case of readline > history - if were to throw an IO exception in the case > of empty history, it would be obligatory for every program > using it to wrap the function in a try. I don't know readline, but it looks like a clear candidate for (Maybe History). -k -- If I haven't seen further, it is by standing in the footprints of giants From gale at sefer.org Wed Jan 23 06:34:03 2008 From: gale at sefer.org (Yitzchak Gale) Date: Wed Jan 23 06:33:47 2008 Subject: Exceptions vs. Errors (Re: Readline read_history and write_history addition) In-Reply-To: <2608b8a80801230239x3c6a992ax63f3af84f01899d3@mail.gmail.com> References: <57526e770801182310r2e44c662wd513465d71e67bda@mail.gmail.com> <6d74b0d20801191109m4c484a44x96e83abb528b2277@mail.gmail.com> <57526e770801191543u71ad5c52r2edd09387c8fe870@mail.gmail.com> <6d74b0d20801211027v621580b2k6584eb3b24bf8320@mail.gmail.com> <57526e770801212034g790f1671p38d47b681bd687bb@mail.gmail.com> <20080122221326.GA20619@matrix.chaos.earth.li> <2608b8a80801221549k41b193cq303a3847f98554e1@mail.gmail.com> <2608b8a80801230239x3c6a992ax63f3af84f01899d3@mail.gmail.com> Message-ID: <2608b8a80801230334x44676cfaw42f0a6c2c8279812@mail.gmail.com> I wrote: >> unfortunately, bracket is currently not available for MonadIO, >> nor is there any way to emulate it AFIK. >> (This is a "maybe" for HaskellPrime: >> http://hackage.haskell.org/trac/haskell-prime/ticket/110) Judah Jacobson wrote: > Following is what I've been using to solve that problem. I can add it > to that HaskellPrime ticket if people think it's useful. Very nice! I think you should not only add it to the ticket (if that is still relevant, I am not sure what is going on with Haskell' right now), but you should also submit a patch for the mtl library. We need a better name than IO1, though. > Note that in bracket1, the "after" action must run in IO. In > practice, that hasn't been a problem for me. In fact, since the > "after" clause might run in response to an asynchronous exception, I > don't see how it could be sequenced with an arbitrary monad, anyway. Agreed. The real fix would be to provide a lower-level primitive for block and unblock. The concurrency paper "Asynchronous exceptions in Haskell" states (sec. 4.2) that the reason for the type block :: IO a -> IO a rather than the more obvious block :: IO () is clumsiness and fragility. That may be so. But that type is too high-level for a primitive. In GHC, the implementation of block is: block (IO io) = IO $ blockAsyncExceptions# io It should really be: block x = do IO blockAsyncExceptions# ret <- x IO unblockAsyncExceptions# return ret in which case we could then supply implementations for other monads as well. Regards, Yitz From gale at sefer.org Wed Jan 23 07:35:27 2008 From: gale at sefer.org (Yitzchak Gale) Date: Wed Jan 23 07:35:11 2008 Subject: Readline read_history and write_history addition In-Reply-To: <20080123005111.GA25334@matrix.chaos.earth.li> References: <57526e770801182310r2e44c662wd513465d71e67bda@mail.gmail.com> <6d74b0d20801191109m4c484a44x96e83abb528b2277@mail.gmail.com> <57526e770801191543u71ad5c52r2edd09387c8fe870@mail.gmail.com> <6d74b0d20801211027v621580b2k6584eb3b24bf8320@mail.gmail.com> <57526e770801212034g790f1671p38d47b681bd687bb@mail.gmail.com> <20080122221326.GA20619@matrix.chaos.earth.li> <2608b8a80801221549k41b193cq303a3847f98554e1@mail.gmail.com> <20080123005111.GA25334@matrix.chaos.earth.li> Message-ID: <2608b8a80801230435u6a18fb7bh1046cc446120d75@mail.gmail.com> Ian Lynagh wrote: > The only way you can have problems is if there is a library (that you > don't control), which exports a (MonadIO m => m a) that internally calls > readlineFunction args > and doesn't catch exceptions. Personally I'd say that that is a bug > in that other library, and it ought to be catching the exception and > either ignoring it, returning some sort of sum type, or also > constraining m to be in some sort of MonadError monad. Agreed. I think that in this situation our function should have a type that allows the type system to check that. >> If we start throwing IO exceptions for common and minor >> occurrences like no readline history available > Pretty much any actual IO you do has this problem, e.g. readFile on > a non-existent file. Those are asynchronous phenomena. It is reasonable for some programs to ignore them completely, assuming that they are being taken care of on the outside, and allowing the program to fail when they are not. So an IO exception is appropriate. Regards, Yitz From igloo at earth.li Wed Jan 23 07:57:24 2008 From: igloo at earth.li (Ian Lynagh) Date: Wed Jan 23 07:57:27 2008 Subject: Readline read_history and write_history addition In-Reply-To: <2608b8a80801230435u6a18fb7bh1046cc446120d75@mail.gmail.com> References: <57526e770801182310r2e44c662wd513465d71e67bda@mail.gmail.com> <6d74b0d20801191109m4c484a44x96e83abb528b2277@mail.gmail.com> <57526e770801191543u71ad5c52r2edd09387c8fe870@mail.gmail.com> <6d74b0d20801211027v621580b2k6584eb3b24bf8320@mail.gmail.com> <57526e770801212034g790f1671p38d47b681bd687bb@mail.gmail.com> <20080122221326.GA20619@matrix.chaos.earth.li> <2608b8a80801221549k41b193cq303a3847f98554e1@mail.gmail.com> <20080123005111.GA25334@matrix.chaos.earth.li> <2608b8a80801230435u6a18fb7bh1046cc446120d75@mail.gmail.com> Message-ID: <20080123125724.GA2912@matrix.chaos.earth.li> On Wed, Jan 23, 2008 at 02:35:27PM +0200, Yitzchak Gale wrote: > Ian Lynagh wrote: > > >> If we start throwing IO exceptions for common and minor > >> occurrences like no readline history available > > > Pretty much any actual IO you do has this problem, e.g. readFile on > > a non-existent file. > > Those are asynchronous phenomena. I'm not sure what you mean by that? It's a synchronous exception. Thanks Ian From gale at sefer.org Wed Jan 23 08:19:12 2008 From: gale at sefer.org (Yitzchak Gale) Date: Wed Jan 23 08:18:55 2008 Subject: Readline read_history and write_history addition In-Reply-To: <20080123125724.GA2912@matrix.chaos.earth.li> References: <57526e770801182310r2e44c662wd513465d71e67bda@mail.gmail.com> <6d74b0d20801191109m4c484a44x96e83abb528b2277@mail.gmail.com> <57526e770801191543u71ad5c52r2edd09387c8fe870@mail.gmail.com> <6d74b0d20801211027v621580b2k6584eb3b24bf8320@mail.gmail.com> <57526e770801212034g790f1671p38d47b681bd687bb@mail.gmail.com> <20080122221326.GA20619@matrix.chaos.earth.li> <2608b8a80801221549k41b193cq303a3847f98554e1@mail.gmail.com> <20080123005111.GA25334@matrix.chaos.earth.li> <2608b8a80801230435u6a18fb7bh1046cc446120d75@mail.gmail.com> <20080123125724.GA2912@matrix.chaos.earth.li> Message-ID: <2608b8a80801230519v72388283xf35f1de120571ca2@mail.gmail.com> > > Those are asynchronous phenomena. > I'm not sure what you mean by that? > It's a synchronous exception. Sorry. I meant external. In the following sense: The semantics of the program explicitly involve it in a larger external system, in a way that it might make sense to allow exceptions to propagate out to the external system. With readline history, it is clear that we must handle all conditions internally, so this condition is not met. Since E1-3 are also not met, we should not throw IO exceptions. -Yitz From simonmarhaskell at gmail.com Wed Jan 23 08:53:47 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Wed Jan 23 08:53:41 2008 Subject: Exceptions vs. Errors (Re: Readline read_history and write_history addition) In-Reply-To: References: <57526e770801182310r2e44c662wd513465d71e67bda@mail.gmail.com> <6d74b0d20801191109m4c484a44x96e83abb528b2277@mail.gmail.com> <57526e770801191543u71ad5c52r2edd09387c8fe870@mail.gmail.com> <6d74b0d20801211027v621580b2k6584eb3b24bf8320@mail.gmail.com> <57526e770801212034g790f1671p38d47b681bd687bb@mail.gmail.com> <20080122221326.GA20619@matrix.chaos.earth.li> <2608b8a80801221549k41b193cq303a3847f98554e1@mail.gmail.com> <2608b8a80801230239x3c6a992ax63f3af84f01899d3@mail.gmail.com> Message-ID: <479746EB.7020906@gmail.com> Henning Thielemann wrote: > You know, in Haskell we do not need a built-in exception handling facility > because we can handle it with the elements of the language. Returning an > exceptional value or throwing an exception is the same. We can only hide > the exception propagation by appropriate binding of actions. I don't consider exceptions in the IO monad to be a "built-in" concept. This is because, if we wanted to, we could implement IO exceptions purely in Haskell on top of a primitive IO monad without exceptions (indeed, that's what Hugs and other systems do, and what GHC did in the past). If you are implementing a Haskell system, you don't need to provide any primitive functionality to support exceptions, it can all be done in the implementation of the IO monad. Exceptions are no more built-in than the Either type. In practice, you might want to implement exceptions at a lower level for performance reasons, which is what GHC does. Cheers, Simon From simonmarhaskell at gmail.com Wed Jan 23 09:07:56 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Wed Jan 23 09:07:46 2008 Subject: Exceptions vs. Errors (Re: Readline read_history and write_history addition) In-Reply-To: <2608b8a80801230334x44676cfaw42f0a6c2c8279812@mail.gmail.com> References: <57526e770801182310r2e44c662wd513465d71e67bda@mail.gmail.com> <6d74b0d20801191109m4c484a44x96e83abb528b2277@mail.gmail.com> <57526e770801191543u71ad5c52r2edd09387c8fe870@mail.gmail.com> <6d74b0d20801211027v621580b2k6584eb3b24bf8320@mail.gmail.com> <57526e770801212034g790f1671p38d47b681bd687bb@mail.gmail.com> <20080122221326.GA20619@matrix.chaos.earth.li> <2608b8a80801221549k41b193cq303a3847f98554e1@mail.gmail.com> <2608b8a80801230239x3c6a992ax63f3af84f01899d3@mail.gmail.com> <2608b8a80801230334x44676cfaw42f0a6c2c8279812@mail.gmail.com> Message-ID: <47974A3C.3000403@gmail.com> Yitzchak Gale wrote: > The real fix would be to provide a lower-level primitive > for block and unblock. The concurrency paper "Asynchronous > exceptions in Haskell" states (sec. 4.2) that the reason for the type > > block :: IO a -> IO a > > rather than the more obvious > > block :: IO () > > is clumsiness and fragility. That may be so. But that type > is too high-level for a primitive. In GHC, the implementation > of block is: > > block (IO io) = IO $ blockAsyncExceptions# io > > It should really be: > > block x = do > IO blockAsyncExceptions# > ret <- x > IO unblockAsyncExceptions# > return ret > > in which case we could then supply implementations for > other monads as well. blockAsyncExceptions# has some tricks to restore tail-recursion in some cases (see the paper). But apart from losing that optimisation, I can't think of any reasons why the above couldn't work - one thing you have to worry about is what happens when x raises an exeption, but I think that is handled by the way we save and restore the blocked state in catch. Cheers, Simon From ross at soi.city.ac.uk Wed Jan 23 10:12:12 2008 From: ross at soi.city.ac.uk (Ross Paterson) Date: Wed Jan 23 10:12:07 2008 Subject: [Haskell] ANNOUNCE: Haddock version 2.0.0.0 In-Reply-To: References: Message-ID: <20080123151212.GA5232@soi.city.ac.uk> On Tue, Jan 08, 2008 at 01:28:50PM +0100, David Waern wrote: > * Format of module attributes has changed. The only way of specifiying > module attributes is via a new OPTIONS_HADDOCK pragma. Example: > {-# OPTIONS_HADDOCK hide, prune #-} Unfortunately the old-style attributes are widely used: over 400 modules in hackage, including 100 shipped with GHC. The vast majority of these are #hide, which ideally should be unnecessary if the modules are not exposed. However some packages expose modules for use in the internals of other packages, but don't want to show those modules in the documentation. For example, most of the GHC.* modules in the base package, which are used in the internals of many of the packages split from base. If I add the new-style attributes to the base package, it hides those modules in the documentation for base, but packages that depend on base seem to generate links to locations in those hidden modules, e.g. uses of IO point at GHC.IOBase.IO. Also, the new haddock rejects some modules the old one accepted. For example, it doesn't like extra doc comments that aren't attached to anything. It also rejects data Pair = Pair {-# UNPACK #-} !Int -- ^ first field {-# UNPACK #-} !Int -- ^ second field From david.waern at gmail.com Wed Jan 23 11:57:18 2008 From: david.waern at gmail.com (David Waern) Date: Wed Jan 23 11:57:01 2008 Subject: [Haskell] ANNOUNCE: Haddock version 2.0.0.0 In-Reply-To: <20080123151212.GA5232@soi.city.ac.uk> References: <20080123151212.GA5232@soi.city.ac.uk> Message-ID: 2008/1/23, Ross Paterson : > On Tue, Jan 08, 2008 at 01:28:50PM +0100, David Waern wrote: > > * Format of module attributes has changed. The only way of specifiying > > module attributes is via a new OPTIONS_HADDOCK pragma. Example: > > {-# OPTIONS_HADDOCK hide, prune #-} > > Unfortunately the old-style attributes are widely used: over 400 modules > in hackage, including 100 shipped with GHC. The vast majority of these > are #hide, which ideally should be unnecessary if the modules are not > exposed. However some packages expose modules for use in the internals of > other packages, but don't want to show those modules in the documentation. > For example, most of the GHC.* modules in the base package, which are used > in the internals of many of the packages split from base. I actually added support for old-style attributes to GHC so that most packages wouldn't need updating, but unfortunately that patch didn't make it into 6.8.2. I agree that Haddock should use the exposed-packages field from Cabal, and that it would work for most packages. For the packages that still need explicit attributes, we can either update them manually, or perhaps beg for my patch to be included in 6.8.3. > If I add the new-style attributes to the base package, it hides those > modules in the documentation for base, but packages that depend on base > seem to generate links to locations in those hidden modules, e.g. uses > of IO point at GHC.IOBase.IO. That's definitely a bug, I'm adding it to the TODO file. > Also, the new haddock rejects some modules the old one accepted.I > For example, it doesn't like extra doc comments that aren't attached > to anything. Hmm, it is possible that the parser has (accidentally) become a bit stricter. > It also rejects > > data Pair = Pair {-# UNPACK #-} !Int -- ^ first field > {-# UNPACK #-} !Int -- ^ second field Ah, yes, this has been reported before but it hasn't been investigated yet. Thanks for the feedback, it is much appreciated. David From valery.vv at gmail.com Wed Jan 23 12:20:19 2008 From: valery.vv at gmail.com (Valery V. Vorotyntsev) Date: Wed Jan 23 12:20:14 2008 Subject: Arrow without `>>>' Message-ID: Hi, friends, I've built GHC from darcs, and... Could anybody tell me, what's the purpose of Arrow[1] not having `>>>' method? 1. http://darcs.haskell.org/packages/base/Control/Arrow.hs $ ghci GHCi, version 6.9.20080104: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. Prelude> :m + Control.Arrow Prelude Control.Arrow> :i Arrow class (Control.Category.Category a) => Arrow a where arr :: (b -> c) -> a b c pure :: (b -> c) -> a b c first :: a b c -> a (b, d) (c, d) second :: a b c -> a (d, b) (d, c) (***) :: a b c -> a b' c' -> a (b, b') (c, c') (&&&) :: a b c -> a b c' -> a b (c, c') -- Defined in Control.Arrow instance Arrow (->) -- Defined in Control.Arrow instance (Monad m) => Arrow (Kleisli m) -- Defined in Control.Arrow Prelude Control.Arrow> Leaving GHCi. I can't build[2] arrows-0.3 package without `>>>' in Arrow. 2. vvv@fun:~/src/arrows$ darcs w { hunk ./Control/Arrow/Operations.hs 36 +import Control.Category ((>>>)) hunk ./Control/Arrow/Transformer/CoState.hs 23 +import Control.Category ((>>>)) } vvv@fun:~/src/arrows$ runhaskell Setup build Preprocessing library arrows-0.3... Building arrows-0.3... [ 3 of 12] Compiling Control.Arrow.Transformer.CoState ( Control/Arrow/Transformer/CoState.hs, dist/build/Control/Arrow/Transformer/CoState.o ) Control/Arrow/Transformer/CoState.hs:29:7: `>>>' is not a (visible) method of class `Arrow' The question arises "should I?", but this is one of lambdabot's[3] depencies. 3. http://code.haskell.org/lambdabot/ Thanks a lot! -- vvv From ross at soi.city.ac.uk Wed Jan 23 12:26:40 2008 From: ross at soi.city.ac.uk (Ross Paterson) Date: Wed Jan 23 12:26:37 2008 Subject: [Haskell] ANNOUNCE: Haddock version 2.0.0.0 In-Reply-To: References: <20080123151212.GA5232@soi.city.ac.uk> Message-ID: <20080123172640.GB5232@soi.city.ac.uk> On Wed, Jan 23, 2008 at 05:57:18PM +0100, David Waern wrote: > 2008/1/23, Ross Paterson : > > If I add the new-style attributes to the base package, it hides those > > modules in the documentation for base, but packages that depend on base > > seem to generate links to locations in those hidden modules, e.g. uses > > of IO point at GHC.IOBase.IO. > > That's definitely a bug, I'm adding it to the TODO file. That one is a show-stopper for HackageDB. > > Also, the new haddock rejects some modules the old one accepted. > > For example, it doesn't like extra doc comments that aren't attached > > to anything. > > Hmm, it is possible that the parser has (accidentally) become a bit stricter. Some examples of things people do that were harmless before: -- | module header -- | extra comment describing module module MyModule where import Stuff -- ^ we might use this type MyInt = Int -- ^ comment From david.waern at gmail.com Wed Jan 23 13:10:34 2008 From: david.waern at gmail.com (David Waern) Date: Wed Jan 23 13:10:16 2008 Subject: [Haskell] ANNOUNCE: Haddock version 2.0.0.0 In-Reply-To: <20080123172640.GB5232@soi.city.ac.uk> References: <20080123151212.GA5232@soi.city.ac.uk> <20080123172640.GB5232@soi.city.ac.uk> Message-ID: 2008/1/23, Ross Paterson : > On Wed, Jan 23, 2008 at 05:57:18PM +0100, David Waern wrote: > > 2008/1/23, Ross Paterson : > > > If I add the new-style attributes to the base package, it hides those > > > modules in the documentation for base, but packages that depend on base > > > seem to generate links to locations in those hidden modules, e.g. uses > > > of IO point at GHC.IOBase.IO. > > > > That's definitely a bug, I'm adding it to the TODO file. > > That one is a show-stopper for HackageDB. Right, we have to prioritize this one. > > > Also, the new haddock rejects some modules the old one accepted. > > > For example, it doesn't like extra doc comments that aren't attached > > > to anything. > > > > Hmm, it is possible that the parser has (accidentally) become a bit stricter. > > Some examples of things people do that were harmless before: > > -- | module header > > -- | extra comment describing module > module MyModule where > > import Stuff -- ^ we might use this > > type MyInt = Int -- ^ comment I've added this as a bug to TODO, but I'm not sure how to fix it easily. David From dave at zednenem.com Wed Jan 23 13:32:12 2008 From: dave at zednenem.com (David Menendez) Date: Wed Jan 23 13:32:09 2008 Subject: Arrow without `>>>' In-Reply-To: References: Message-ID: <49a77b7a0801231032j54755252t922693b6cd81acbe@mail.gmail.com> On Jan 23, 2008 12:20 PM, Valery V. Vorotyntsev wrote: > I've built GHC from darcs, and... > Could anybody tell me, what's the purpose of Arrow[1] not having `>>>' > method? It's derived from the Category superclass. -- Dave Menendez -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20080123/012bc73e/attachment.htm From valery.vv at gmail.com Thu Jan 24 08:10:39 2008 From: valery.vv at gmail.com (Valery V. Vorotyntsev) Date: Thu Jan 24 08:10:35 2008 Subject: Arrow without `>>>' In-Reply-To: <49a77b7a0801231032j54755252t922693b6cd81acbe@mail.gmail.com> References: <49a77b7a0801231032j54755252t922693b6cd81acbe@mail.gmail.com> Message-ID: On 1/23/08, David Menendez wrote: > On Jan 23, 2008 12:20 PM, Valery V. Vorotyntsev wrote: > > I've built GHC from darcs, and... > > Could anybody tell me, what's the purpose of Arrow[1] not having `>>>' > > method? > > It's derived from the Category superclass. Yes, it is. The right question: how to build `arrows' in such circumstances? Here go 2 changes I made to `CoState.hs' accompanied by the error messages. :) Unfortunately, I'm not arrow-capable enough to make _proper_ changes to the code and satisfy GHC... Any help? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Change #1: $ darcs w Control/Arrow/Transformer/CoState.hs What's new in "Control/Arrow/Transformer/CoState.hs": { hunk ./Control/Arrow/Transformer/CoState.hs 23 +import Control.Category ((>>>)) } -------------------------------------------------- Error #1: Control/Arrow/Transformer/CoState.hs:29:7: `>>>' is not a (visible) method of class `Arrow' Failed, modules loaded: Control.Arrow.Operations. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Change #2: $ darcs diff -u Control/Arrow/Transformer/CoState.hs --- old-arrows/Control/Arrow/Transformer/CoState.hs 2008-01-24 14:54:29.852296559 +0200 +++ new-arrows/Control/Arrow/Transformer/CoState.hs 2008-01-24 14:54:29.852296559 +0200 @@ -20,12 +20,13 @@ import Control.Arrow import Control.Arrow.Operations +import Control.Category ((>>>)) newtype CoStateArrow s a b c = CST (a (s -> b) (s -> c)) instance Arrow a => Arrow (CoStateArrow s a) where arr f = CST (arr (f .)) - CST f >>> CST g = CST (f >>> g) +-- CST f >>> CST g = CST (f >>> g) first (CST f) = CST (arr unzipMap >>> first f >>> arr zipMap) zipMap :: (s -> a, s -> b) -> (s -> (a,b)) -------------------------------------------------- Error#2: Control/Arrow/Transformer/CoState.hs:27:0: Could not deduce (Control.Category.Category (CoStateArrow s a)) from the context (Arrow a) arising from the superclasses of an instance declaration at Control/Arrow/Transformer/CoState.hs:27:0 Possible fix: add (Control.Category.Category (CoStateArrow s a)) to the context of the instance declaration or add an instance declaration for (Control.Category.Category (CoStateArrow s a)) In the instance declaration for `Arrow (CoStateArrow s a)' Failed, modules loaded: Control.Arrow.Operations. Thank you. -- vvv From ross at soi.city.ac.uk Thu Jan 24 08:21:16 2008 From: ross at soi.city.ac.uk (Ross Paterson) Date: Thu Jan 24 08:20:59 2008 Subject: Arrow without `>>>' In-Reply-To: References: <49a77b7a0801231032j54755252t922693b6cd81acbe@mail.gmail.com> Message-ID: <20080124132116.GA12902@soi.city.ac.uk> On Thu, Jan 24, 2008 at 03:10:39PM +0200, Valery V. Vorotyntsev wrote: > On 1/23/08, David Menendez wrote: > > On Jan 23, 2008 12:20 PM, Valery V. Vorotyntsev wrote: > > > I've built GHC from darcs, and... > > > Could anybody tell me, what's the purpose of Arrow[1] not having `>>>' > > > method? > > > > It's derived from the Category superclass. > > Yes, it is. > > The right question: how to build `arrows' in such circumstances? To build with the darcs version of the base library (built with GHC), you'll need the darcs version of the arrows library, which I think is right now: darcs get http://darcs.haskell.org/packages/arrows From valery.vv at gmail.com Thu Jan 24 08:34:44 2008 From: valery.vv at gmail.com (Valery V. Vorotyntsev) Date: Thu Jan 24 08:34:24 2008 Subject: Arrow without `>>>' In-Reply-To: <20080124132116.GA12902@soi.city.ac.uk> References: <49a77b7a0801231032j54755252t922693b6cd81acbe@mail.gmail.com> <20080124132116.GA12902@soi.city.ac.uk> Message-ID: On 1/24/08, Ross Paterson wrote: > > The right question: how to build `arrows' in such circumstances? > > To build with the darcs version of the base library (built with GHC), > you'll need the darcs version of the arrows library, which I think is > right now: > > darcs get http://darcs.haskell.org/packages/arrows Yes, after pulling the latest change from repo installation went smoothly. Thank you very much, Ross! -- vvv From judah.jacobson at gmail.com Thu Jan 24 11:44:45 2008 From: judah.jacobson at gmail.com (Judah Jacobson) Date: Thu Jan 24 11:44:26 2008 Subject: Integrating editline with ghc In-Reply-To: References: <6d74b0d20801161305na9e0732m2a6bae7098ec531d@mail.gmail.com> <478F1DB8.1080807@dfki.de> <20080117104733.47ea65ad.Malcolm.Wallace@cs.york.ac.uk> <8AE12C50-BB0F-4914-85F2-C21FC60D7F10@cse.unsw.edu.au> <4790A474.2060607@gmail.com> Message-ID: <6d74b0d20801240844u21486d82k979b6733b1aa5de9@mail.gmail.com> On Jan 22, 2008 1:49 AM, Manuel M T Chakravarty wrote: > Simon Marlow: > > > I think it would be a bad idea to provide EditReadline as > > described. The reason being that this would be a package with a > > variant license: its license is conditional on how it is built, > > which makes it that much harder for clients to understand what > > licensing restrictions apply, and to license themselves > > appropriately. (the alternative is to make EditReadline GPL, but > > that defeats the purpose). > > > > > > I don't even think we've considered variant licenses in Cabal > > before, and my inclination would be to disallow or at least > > vigorously discourage it. > > I don't like this either. > > > So I suggest we just keep readline as it is, and packages that want > > to use editline can switch at their discretion, using > > System.Console.Editline.Readline to make porting easier. In GHC I > > imagine we'll just switch to using editline. > > That's fine if all platforms that by default have readline also have > editline. I just checked, Fedora 8 does have both. How about other > Linux distros? What is the situation on Solaris? A few distros (including Solaris) have libedit version 1.*, which appears to be too old to provide enough functionality to replace readline. From what I can tell, libedit-1 provides the header , whereas libedit-2 provides as well as either or . (OS X 10.4 and 10.5 have 2.6 and 2.9, respectively.) >From Christian, who helped me figure out what was going on: > It looks pretty bad with libedit under non-macs. It's also not on our > fedora7 machines. Under Solaris I did not find histedit.h > > Surely http://www.thrysoee.dk/editline/libedit-20070831-2.10.tar.gz > could be installed on the platforms or supplied with ghc as a static > library. With libedit dynamically linked user programs will hardly run, > though, on non-macs. -Judah From isaacdupree at charter.net Thu Jan 24 13:56:06 2008 From: isaacdupree at charter.net (Isaac Dupree) Date: Thu Jan 24 13:55:45 2008 Subject: Exceptions vs. Errors (Re: Readline read_history and write_history addition) In-Reply-To: <47974A3C.3000403@gmail.com> References: <57526e770801182310r2e44c662wd513465d71e67bda@mail.gmail.com> <6d74b0d20801191109m4c484a44x96e83abb528b2277@mail.gmail.com> <57526e770801191543u71ad5c52r2edd09387c8fe870@mail.gmail.com> <6d74b0d20801211027v621580b2k6584eb3b24bf8320@mail.gmail.com> <57526e770801212034g790f1671p38d47b681bd687bb@mail.gmail.com> <20080122221326.GA20619@matrix.chaos.earth.li> <2608b8a80801221549k41b193cq303a3847f98554e1@mail.gmail.com> <2608b8a80801230239x3c6a992ax63f3af84f01899d3@mail.gmail.com> <2608b8a80801230334x44676cfaw42f0a6c2c8279812@mail.gmail.com> <47974A3C.3000403@gmail.com> Message-ID: <4798DF46.9090009@charter.net> >> It should really be: >> >> block x = do >> IO blockAsyncExceptions# >> ret <- x >> IO unblockAsyncExceptions# >> return ret >> >> in which case we could then supply implementations for >> other monads as well. > > blockAsyncExceptions# has some tricks to restore tail-recursion in some > cases (see the paper). But apart from losing that optimisation, I can't > think of any reasons why the above couldn't work - one thing you have to > worry about is what happens when x raises an exeption, but I think that > is handled by the way we save and restore the blocked state in catch. what about if the monad is a transformed one with its own error handling methods (e.g. ErrorT IO) and so (IO blockAsyncExceptions#) is run but (IO unblockAsyncExceptions#) is not? Is that a problem? ~Isaac From bringert at cs.chalmers.se Thu Jan 24 17:03:58 2008 From: bringert at cs.chalmers.se (Bjorn Bringert) Date: Thu Jan 24 17:03:56 2008 Subject: Network.CGI changes In-Reply-To: <20080122172834.GV11635@a5.repetae.net> References: <20080121001407.GA3695@a5.repetae.net> <47945CE6.6080409@imn.htwk-leipzig.de> <20080121120147.GP11635@a5.repetae.net> <47961A45.2090706@cs.chalmers.se> <20080122172834.GV11635@a5.repetae.net> Message-ID: <8FE20F95-A020-4099-9DBB-5237622C8BBB@cs.chalmers.se> Hi Frederik, I agree with your comments about the headaches of Haskell library stability. I made the change because it seemed like the old library had no users. I should put my money where my mouth is, Network.CGI.Compat is now back in the cgi package. /Bjorn On Jan 22, 2008, at 18:28 , Frederik Eaton wrote: > Hi Bjorn, > > Well, I don't know what the solution is. As I have said, I think it > would be best to keep Network.CGI.Compat. That way, users of the old > module just have to change the module name, plus they don't have to > hack cgi-compat to get it to compile when cgi is already working. > > A typical project of mine uses 10 or more packages, and something that > makes me reluctant to use Haskell is the experience that after a few > years I will end up having to maintain separate versions of > significant numbers of those packages if I want something I wrote to > stay working. Haskell is supposed to be good for writing large > projects, but large projects need stable libraries or they become a > maintenance nightmare. It's rather worrying to see that people seem to > think that if I don't have time to participate actively in the mailing > lists or upload stuff to hackage, then my code doesn't exist... > > Maybe there is a high cost to keeping Network.CGI.Compat in the cgi > package, but I don't see any reason other than an aesthetics, which > seems like less of a priority than backwards compatibility. > > Frederik > > On Tue, Jan 22, 2008 at 05:31:01PM +0100, Bj?rn Bringert wrote: >> Hi Frederik, >> >> (I'm CC:ing the libraries list, so that anyone who wants to have >> Network.CGI.Compat back in >> the cgi package can shout.) >> >> That exact module actually used to exist in the cgi package as >> well (it implemented the >> complete API of the old Network.CGI), but after a few releases I >> removed it since it didn't >> seem to have any users. That was quite a long time ago, and you >> are the first person to >> complain. >> >> The purpose of cgi-compat is actually not to provide >> Network.CGI.Compat, but rather to be >> installable on older GHC versions, hence the main module name >> Network.NewCGI. >> >> I'm not sure if there is sufficient demand for adding >> Network.CGI.Compat back into the cgi >> package. The old Network.CGI seemed to have very few users, due to >> to it's restrictions. >> You can always get Network.CGI.Compat from here, and include it in >> your program: >> http://www.cs.chalmers.se/~bringert/darcs/cgi-compat/Network/CGI/ >> Compat.hs >> >> /Bj?rn >> >> Frederik Eaton wrote: >>> Dear Johannes, >>> Thanks, that works for me. >>> Bjorn, perhaps it would be easier to put these five lines in a >>> module >>> (Network.CGI.Compat?) in the new package, rather than having people >>> maintain and download a separate cgi-compat package? Perhaps the two >>> other functions in the old CGI interface can be implemented in terms >>> of the new API as well? >>> Best wishes, >>> Frederik >>> On Mon, Jan 21, 2008 at 09:50:46AM +0100, Johannes Waldmann wrote: >>>> If you need the old "wrapper" function, then use something like >>>> this: >>>> >>>> wrapper :: ([(String,String)] -> IO Html) -> IO () >>>> wrapper f = runCGI $ do >>>> >>>> e <- getInputs >>>> a <- lift $ f $ e >>>> output $ renderHtml a >>>> >>>> best regards, Johannes Waldmann. >>>> >> > > -- > http://ofb.net/~frederik/ From frederik at a5.repetae.net Fri Jan 25 02:53:20 2008 From: frederik at a5.repetae.net (Frederik Eaton) Date: Fri Jan 25 02:53:06 2008 Subject: Network.CGI changes In-Reply-To: <8FE20F95-A020-4099-9DBB-5237622C8BBB@cs.chalmers.se> References: <20080121001407.GA3695@a5.repetae.net> <47945CE6.6080409@imn.htwk-leipzig.de> <20080121120147.GP11635@a5.repetae.net> <47961A45.2090706@cs.chalmers.se> <20080122172834.GV11635@a5.repetae.net> <8FE20F95-A020-4099-9DBB-5237622C8BBB@cs.chalmers.se> Message-ID: <20080125075320.GX11635@a5.repetae.net> Hi Bjorn, Thank you, that is good to hear. Thank you for giving us the better API as well. Frederik On Thu, Jan 24, 2008 at 11:03:58PM +0100, Bjorn Bringert wrote: > Hi Frederik, > > I agree with your comments about the headaches of Haskell library stability. I made the > change because it seemed like the old library had no users. I should put my money where my > mouth is, Network.CGI.Compat is now back in the cgi package. > > /Bjorn > > On Jan 22, 2008, at 18:28 , Frederik Eaton wrote: > > >Hi Bjorn, > > > >Well, I don't know what the solution is. As I have said, I think it > >would be best to keep Network.CGI.Compat. That way, users of the old > >module just have to change the module name, plus they don't have to > >hack cgi-compat to get it to compile when cgi is already working. > > > >A typical project of mine uses 10 or more packages, and something that > >makes me reluctant to use Haskell is the experience that after a few > >years I will end up having to maintain separate versions of > >significant numbers of those packages if I want something I wrote to > >stay working. Haskell is supposed to be good for writing large > >projects, but large projects need stable libraries or they become a > >maintenance nightmare. It's rather worrying to see that people seem to > >think that if I don't have time to participate actively in the mailing > >lists or upload stuff to hackage, then my code doesn't exist... > > > >Maybe there is a high cost to keeping Network.CGI.Compat in the cgi > >package, but I don't see any reason other than an aesthetics, which > >seems like less of a priority than backwards compatibility. > > > >Frederik > > > >On Tue, Jan 22, 2008 at 05:31:01PM +0100, Bj?rn Bringert wrote: > >>Hi Frederik, > >> > >>(I'm CC:ing the libraries list, so that anyone who wants to have Network.CGI.Compat back > >>in > >>the cgi package can shout.) > >> > >>That exact module actually used to exist in the cgi package as well (it implemented the > >>complete API of the old Network.CGI), but after a few releases I removed it since it > >>didn't > >>seem to have any users. That was quite a long time ago, and you are the first person to > >>complain. > >> > >>The purpose of cgi-compat is actually not to provide Network.CGI.Compat, but rather to be > >>installable on older GHC versions, hence the main module name Network.NewCGI. > >> > >>I'm not sure if there is sufficient demand for adding Network.CGI.Compat back into the > >>cgi > >>package. The old Network.CGI seemed to have very few users, due to to it's restrictions. > >>You can always get Network.CGI.Compat from here, and include it in your program: > >>http://www.cs.chalmers.se/~bringert/darcs/cgi-compat/Network/CGI/Compat.hs > >> > >>/Bj?rn > >> > >>Frederik Eaton wrote: > >>>Dear Johannes, > >>>Thanks, that works for me. > >>>Bjorn, perhaps it would be easier to put these five lines in a module > >>>(Network.CGI.Compat?) in the new package, rather than having people > >>>maintain and download a separate cgi-compat package? Perhaps the two > >>>other functions in the old CGI interface can be implemented in terms > >>>of the new API as well? > >>>Best wishes, > >>>Frederik > >>>On Mon, Jan 21, 2008 at 09:50:46AM +0100, Johannes Waldmann wrote: > >>>>If you need the old "wrapper" function, then use something like this: > >>>> > >>>>wrapper :: ([(String,String)] -> IO Html) -> IO () > >>>>wrapper f = runCGI $ do > >>>> > >>>> e <- getInputs > >>>> a <- lift $ f $ e > >>>> output $ renderHtml a > >>>> > >>>>best regards, Johannes Waldmann. > >>>> > >> > > > >-- > >http://ofb.net/~frederik/ > -- http://ofb.net/~frederik/ From simonmarhaskell at gmail.com Fri Jan 25 04:10:37 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Fri Jan 25 04:10:21 2008 Subject: Exceptions vs. Errors (Re: Readline read_history and write_history addition) In-Reply-To: <4798DF46.9090009@charter.net> References: <57526e770801182310r2e44c662wd513465d71e67bda@mail.gmail.com> <6d74b0d20801191109m4c484a44x96e83abb528b2277@mail.gmail.com> <57526e770801191543u71ad5c52r2edd09387c8fe870@mail.gmail.com> <6d74b0d20801211027v621580b2k6584eb3b24bf8320@mail.gmail.com> <57526e770801212034g790f1671p38d47b681bd687bb@mail.gmail.com> <20080122221326.GA20619@matrix.chaos.earth.li> <2608b8a80801221549k41b193cq303a3847f98554e1@mail.gmail.com> <2608b8a80801230239x3c6a992ax63f3af84f01899d3@mail.gmail.com> <2608b8a80801230334x44676cfaw42f0a6c2c8279812@mail.gmail.com> <47974A3C.3000403@gmail.com> <4798DF46.9090009@charter.net> Message-ID: <4799A78D.1070902@gmail.com> Isaac Dupree wrote: > >>> It should really be: >>> >>> block x = do >>> IO blockAsyncExceptions# >>> ret <- x >>> IO unblockAsyncExceptions# >>> return ret >>> >>> in which case we could then supply implementations for >>> other monads as well. >> >> blockAsyncExceptions# has some tricks to restore tail-recursion in >> some cases (see the paper). But apart from losing that optimisation, >> I can't think of any reasons why the above couldn't work - one thing >> you have to worry about is what happens when x raises an exeption, but >> I think that is handled by the way we save and restore the blocked >> state in catch. > > what about if the monad is a transformed one with its own error handling > methods (e.g. ErrorT IO) and so (IO blockAsyncExceptions#) is run but > (IO unblockAsyncExceptions#) is not? Is that a problem? Yes, in that case you'd need an exception handler in the above code to ensure that unblockAsyncExceptions# was called. Cheers, Simon From frederik at a5.repetae.net Fri Jan 25 06:15:29 2008 From: frederik at a5.repetae.net (Frederik Eaton) Date: Fri Jan 25 06:15:08 2008 Subject: [htoolkit-users] HSQL defunct? In-Reply-To: References: <20060817001711.GD3356@a5.repetae.net> <20060817004940.GE3356@a5.repetae.net> <20060817211056.GR3356@a5.repetae.net> <44EEC0F7.3010302@cs.chalmers.se> <20070303173504.GA14521@a5.repetae.net> <4606A979.10408@cs.chalmers.se> <20080120044658.GA10424@a5.repetae.net> <4792D69D.7070103@serpentine.com> Message-ID: <20080125111529.GA26837@a5.repetae.net> Hello all, I don't mind maintaining HSQL, if no one else will do it, but I'm not really an ideal person since I don't use the library in my current work. Any other takers? I'll wait a few days and see if someone else is interested... Best regards, Frederik On Sun, Jan 20, 2008 at 11:18:12AM +0100, Krasimir Angelov wrote: > Hi Frederik and Bryan, > > The latest darcs repository for HSQL is here: > > http://darcs.haskell.org/HSQL/ > > I have to admit that I didn't have enough energy to maintain the HSQL > in the last two years. If someone voluntee to take the HSQL maintaince > then he is highly welcome. There are some new features like prepared > statements and large binary objects that aren't completed/tested yet > and this should be done before the next official release. > > Best regards, > Krasimir > > > > On 1/20/08, Bryan O'Sullivan wrote: > > Frederik Eaton wrote: > > > > > Is there going to be a new maintainer for HSQL? I have submitted a > > > number of patches to fix some painful bugs. It's been almost a year > > > since my previous enquiry and the last release was December 15, 2005, > > > over two years ago: > > > > I think that if it's sat moribund for this long, you could reasonably > > declare yourself the maintainer by fiat. Some OSS communities have a > > formal process for declaring packages as orphaned, but I don't think > > we're big enough for that. > > > > If you don't mind the idea of taking the HSQL package over, perhaps you > > should follow the same steps Don did with the X11 package: > > > > * declare your intention to take over in a message to libraries@ > > * wait a week for someone to pop up with an objection > > * if nobody does, upload a new release with your fixes to Hackage > > > > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by: Microsoft > > Defy all challenges. Microsoft(R) Visual Studio 2008. > > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > > _______________________________________________ > > htoolkit-users mailing list > > htoolkit-users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/htoolkit-users > > > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries > -- http://ofb.net/~frederik/ From ross at soi.city.ac.uk Fri Jan 25 21:16:44 2008 From: ross at soi.city.ac.uk (Ross Paterson) Date: Fri Jan 25 21:16:26 2008 Subject: Quick Hackage question In-Reply-To: <6d74b0d20801211747wcb463e0w84fe88d79c7f8d54@mail.gmail.com> References: <47950A06.4020303@iee.org> <1200954579.5883.44.camel@intothevoid> <6d74b0d20801211457wb0ef86dr2e6da81096f1acee@mail.gmail.com> <1200963184.5639.479.camel@localhost> <6d74b0d20801211747wcb463e0w84fe88d79c7f8d54@mail.gmail.com> Message-ID: <20080126021644.GA30053@soi.city.ac.uk> On Mon, Jan 21, 2008 at 05:47:18PM -0800, Judah Jacobson wrote: > On Jan 21, 2008 4:53 PM, Duncan Coutts wrote: > > In the medium term, expecting the hackage server to be able to build > > each package is unrealistic. It will never have all the system libs and > > eventually will probably not have the cpu time to even build them all. > > The solution is to have separate building and have hackage just report > > the results. > > That makes sense; but if the packages aren't built on the server, will > we still be able to display the Haddock docs? Maybe there should be > some way for the person uploading a package to also upload its Haddock > files? Yes, Duncan's scheme will provide lots of useful information, but it might not be a replacement for building the docs under controlled conditions (though not necessarily on the server). The docs we want on the server have different links from the local ones people would usually want to generate. It would also require a great deal of care to ensure that docs produced remotely could be trusted. From ross at soi.city.ac.uk Fri Jan 25 21:44:42 2008 From: ross at soi.city.ac.uk (Ross Paterson) Date: Fri Jan 25 21:44:21 2008 Subject: Quick Hackage question In-Reply-To: <6d74b0d20801211457wb0ef86dr2e6da81096f1acee@mail.gmail.com> References: <47950A06.4020303@iee.org> <1200954579.5883.44.camel@intothevoid> <6d74b0d20801211457wb0ef86dr2e6da81096f1acee@mail.gmail.com> Message-ID: <20080126024442.GB30053@soi.city.ac.uk> On Mon, Jan 21, 2008 at 02:57:03PM -0800, Judah Jacobson wrote: > Would it be possible to get better reporting of errors that prevent > Haddock docs from being built? Some packages without docs list a > build log, but many others don't. They should be up-to-date now, with an indication of success or failure (and a log in the latter case, though in a different place on the page from previously). Note that only packages containing libraries are built. > For example, the editline package was posted about 5-6 days ago, and > still doesn't have haddock links (probably because libedit isn't > installed on the hackage server). It would be nice to see the build > errors, if any, so that I could request for any missing libraries to > be installed. Your package failed to build, because editline.h is not in a subdirectory on Debian systems (like the one used for the build). You'd need to check for plain editline.h too. But then it fails the sign of read_history test, presumably because it's an old version (1.12). From duncan.coutts at worc.ox.ac.uk Sat Jan 26 09:35:56 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sat Jan 26 09:35:31 2008 Subject: Quick Hackage question In-Reply-To: <20080126021644.GA30053@soi.city.ac.uk> References: <47950A06.4020303@iee.org> <1200954579.5883.44.camel@intothevoid> <6d74b0d20801211457wb0ef86dr2e6da81096f1acee@mail.gmail.com> <1200963184.5639.479.camel@localhost> <6d74b0d20801211747wcb463e0w84fe88d79c7f8d54@mail.gmail.com> <20080126021644.GA30053@soi.city.ac.uk> Message-ID: <1201358156.5639.584.camel@localhost> On Sat, 2008-01-26 at 02:16 +0000, Ross Paterson wrote: > On Mon, Jan 21, 2008 at 05:47:18PM -0800, Judah Jacobson wrote: > > On Jan 21, 2008 4:53 PM, Duncan Coutts wrote: > > > In the medium term, expecting the hackage server to be able to build > > > each package is unrealistic. It will never have all the system libs and > > > eventually will probably not have the cpu time to even build them all. > > > The solution is to have separate building and have hackage just report > > > the results. > > > > That makes sense; but if the packages aren't built on the server, will > > we still be able to display the Haddock docs? Maybe there should be > > some way for the person uploading a package to also upload its Haddock > > files? > > Yes, Duncan's scheme will provide lots of useful information, but it might > not be a replacement for building the docs under controlled conditions > (though not necessarily on the server). The docs we want on the server > have different links from the local ones people would usually want to > generate. It would also require a great deal of care to ensure that > docs produced remotely could be trusted. Yes, I think that's right for the short and medium term. Offloading package builds is a good deal easier than offloading building of documentation. Duncan From chak at cse.unsw.edu.au Sun Jan 27 00:41:37 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Sun Jan 27 00:41:12 2008 Subject: Integrating editline with ghc In-Reply-To: <6d74b0d20801240844u21486d82k979b6733b1aa5de9@mail.gmail.com> References: <6d74b0d20801161305na9e0732m2a6bae7098ec531d@mail.gmail.com> <478F1DB8.1080807@dfki.de> <20080117104733.47ea65ad.Malcolm.Wallace@cs.york.ac.uk> <8AE12C50-BB0F-4914-85F2-C21FC60D7F10@cse.unsw.edu.au> <4790A474.2060607@gmail.com> <6d74b0d20801240844u21486d82k979b6733b1aa5de9@mail.gmail.com> Message-ID: <141A525E-1A53-4C66-B1DB-20656FD50088@cse.unsw.edu.au> Am 25.01.2008 um 03:44 schrieb Judah Jacobson: > On Jan 22, 2008 1:49 AM, Manuel M T Chakravarty > wrote: >> Simon Marlow: >> >>> I think it would be a bad idea to provide EditReadline as >>> described. The reason being that this would be a package with a >>> variant license: its license is conditional on how it is built, >>> which makes it that much harder for clients to understand what >>> licensing restrictions apply, and to license themselves >>> appropriately. (the alternative is to make EditReadline GPL, but >>> that defeats the purpose). >>> >>> I don't even think we've considered variant licenses in Cabal >>> before, and my inclination would be to disallow or at least >>> vigorously discourage it. >> >> I don't like this either. >> >>> So I suggest we just keep readline as it is, and packages that want >>> to use editline can switch at their discretion, using >>> System.Console.Editline.Readline to make porting easier. In GHC I >>> imagine we'll just switch to using editline. >> >> That's fine if all platforms that by default have readline also have >> editline. I just checked, Fedora 8 does have both. How about other >> Linux distros? What is the situation on Solaris? > > A few distros (including Solaris) have libedit version 1.*, which > appears to be too old to provide enough functionality to replace > readline. From what I can tell, libedit-1 provides the header > , whereas libedit-2 provides as well as > either or . (OS X 10.4 and > 10.5 have 2.6 and 2.9, respectively.) > > From Christian, who helped me figure out what was going on: >> It looks pretty bad with libedit under non-macs. It's also not on our >> fedora7 machines. Under Solaris I did not find histedit.h >> >> Surely http://www.thrysoee.dk/editline/libedit-20070831-2.10.tar.gz >> could be installed on the platforms or supplied with ghc as a static >> library. With libedit dynamically linked user programs will hardly >> run, >> though, on non-macs. To summarise, * I don't think it is feasible to entirely drop readline from ghci (as some widely used Linux distributions, eg, Fedora 7 and Solaris doesn't support sufficiently recent versions of editline). * We don't seem to want a package with a variant license plus might have trouble specifying one with Cabal. My conclusion: * The readline package stays as it is (stays GPL). * We add the new editline package (as a boot package) including Editline.Readline as the compatibility layer (is BSD3). * GHC uses configure magic to pick editline when available and readline otherwise. * Any other software can, at their discretion, choose to support only readline, or only editline, or use configure magic similar to GHC. This is a bit of extra hassle, but that may be a good thing as it forces developers to become aware of the licensing issues they get into. Simon, what do you think? Manuel From duncan.coutts at worc.ox.ac.uk Sun Jan 27 07:25:02 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Jan 27 07:24:35 2008 Subject: Integrating editline with ghc In-Reply-To: <141A525E-1A53-4C66-B1DB-20656FD50088@cse.unsw.edu.au> References: <6d74b0d20801161305na9e0732m2a6bae7098ec531d@mail.gmail.com> <478F1DB8.1080807@dfki.de> <20080117104733.47ea65ad.Malcolm.Wallace@cs.york.ac.uk> <8AE12C50-BB0F-4914-85F2-C21FC60D7F10@cse.unsw.edu.au> <4790A474.2060607@gmail.com> <6d74b0d20801240844u21486d82k979b6733b1aa5de9@mail.gmail.com> <141A525E-1A53-4C66-B1DB-20656FD50088@cse.unsw.edu.au> Message-ID: <1201436702.5639.617.camel@localhost> On Sun, 2008-01-27 at 16:41 +1100, Manuel M T Chakravarty wrote: > To summarise, > > * I don't think it is feasible to entirely drop readline from ghci (as > some widely used Linux distributions, eg, Fedora 7 and Solaris doesn't > support sufficiently recent versions of editline). Indeed. I tried to build the editline package that was just uploaded to hackage and discovered that Gentoo does not package the editline C library at all. Duncan From igloo at earth.li Sun Jan 27 18:06:33 2008 From: igloo at earth.li (Ian Lynagh) Date: Sun Jan 27 18:06:04 2008 Subject: Integrating editline with ghc In-Reply-To: <141A525E-1A53-4C66-B1DB-20656FD50088@cse.unsw.edu.au> References: <6d74b0d20801161305na9e0732m2a6bae7098ec531d@mail.gmail.com> <478F1DB8.1080807@dfki.de> <20080117104733.47ea65ad.Malcolm.Wallace@cs.york.ac.uk> <8AE12C50-BB0F-4914-85F2-C21FC60D7F10@cse.unsw.edu.au> <4790A474.2060607@gmail.com> <6d74b0d20801240844u21486d82k979b6733b1aa5de9@mail.gmail.com> <141A525E-1A53-4C66-B1DB-20656FD50088@cse.unsw.edu.au> Message-ID: <20080127230633.GA10144@matrix.chaos.earth.li> On Sun, Jan 27, 2008 at 04:41:37PM +1100, Manuel M T Chakravarty wrote: > > My conclusion: > > * The readline package stays as it is (stays GPL). I definitely agree with this. > * We add the new editline package (as a boot package) including > Editline.Readline as the compatibility layer (is BSD3). And this. > * GHC uses configure magic to pick editline when available and > readline otherwise. I think GHC should just always use editline. We already need to support using an in-tree editline for Windows, so we can also use it on other platforms where editline isn't easily available or is too old. Also supporting readline just makes the build system more complicated for little extra benefit, and also means that there are more configurations to bitrot. Thanks Ian From ndmitchell at gmail.com Sun Jan 27 18:17:50 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Sun Jan 27 18:17:18 2008 Subject: filepath In-Reply-To: <47960003.3090702@gmail.com> References: <20071209133413.GA20930@matrix.chaos.earth.li> <404396ef0712091317n5531bf6l8e2ef2f7c768a642@mail.gmail.com> <20071209222359.GB31745@matrix.chaos.earth.li> <475E9D16.2070809@gmail.com> <4795F7E0.60509@gmail.com> <404396ef0801220618k7cfe57d6u88ce4f10a6c30989@mail.gmail.com> <47960003.3090702@gmail.com> Message-ID: <404396ef0801271517p21af9001t4d9501a147f6e197@mail.gmail.com> Hi > That seems strange, actually. I would expect, perhaps naively, that > > takeDirectory == fst . splitFileName > dropFileName == takeDirectory > > is there a good reason for these not to be true? The original motivation was that: uncurry (++) . splitFileName === id And hence dropFileName = fst . splitFileName However, in practice I think its more useful to use takeDirectory, since usually the trailing slash gets in the way. Those were the original reasons, but it is possible they were bad reasons from the beginning. Thanks Neil From duncan.coutts at worc.ox.ac.uk Sun Jan 27 18:45:30 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Jan 27 18:44:59 2008 Subject: Integrating editline with ghc In-Reply-To: <1201436702.5639.617.camel@localhost> References: <6d74b0d20801161305na9e0732m2a6bae7098ec531d@mail.gmail.com> <478F1DB8.1080807@dfki.de> <20080117104733.47ea65ad.Malcolm.Wallace@cs.york.ac.uk> <8AE12C50-BB0F-4914-85F2-C21FC60D7F10@cse.unsw.edu.au> <4790A474.2060607@gmail.com> <6d74b0d20801240844u21486d82k979b6733b1aa5de9@mail.gmail.com> <141A525E-1A53-4C66-B1DB-20656FD50088@cse.unsw.edu.au> <1201436702.5639.617.camel@localhost> Message-ID: <1201477531.5639.629.camel@localhost> On Sun, 2008-01-27 at 12:25 +0000, Duncan Coutts wrote: > On Sun, 2008-01-27 at 16:41 +1100, Manuel M T Chakravarty wrote: > > > To summarise, > > > > * I don't think it is feasible to entirely drop readline from ghci (as > > some widely used Linux distributions, eg, Fedora 7 and Solaris doesn't > > support sufficiently recent versions of editline). > > Indeed. I tried to build the editline package that was just uploaded to > hackage and discovered that Gentoo does not package the editline C > library at all. I spoke too soon. It is packaged as libedit (I was looking for editline). Duncan From judah.jacobson at gmail.com Sun Jan 27 19:06:41 2008 From: judah.jacobson at gmail.com (Judah Jacobson) Date: Sun Jan 27 19:06:11 2008 Subject: Integrating editline with ghc In-Reply-To: <1201477531.5639.629.camel@localhost> References: <6d74b0d20801161305na9e0732m2a6bae7098ec531d@mail.gmail.com> <478F1DB8.1080807@dfki.de> <20080117104733.47ea65ad.Malcolm.Wallace@cs.york.ac.uk> <8AE12C50-BB0F-4914-85F2-C21FC60D7F10@cse.unsw.edu.au> <4790A474.2060607@gmail.com> <6d74b0d20801240844u21486d82k979b6733b1aa5de9@mail.gmail.com> <141A525E-1A53-4C66-B1DB-20656FD50088@cse.unsw.edu.au> <1201436702.5639.617.camel@localhost> <1201477531.5639.629.camel@localhost> Message-ID: <6d74b0d20801271606p80a0116i1c262b7d9a90108a@mail.gmail.com> On Jan 27, 2008 3:45 PM, Duncan Coutts wrote: > > On Sun, 2008-01-27 at 12:25 +0000, Duncan Coutts wrote: > > On Sun, 2008-01-27 at 16:41 +1100, Manuel M T Chakravarty wrote: > > > > > To summarise, > > > > > > * I don't think it is feasible to entirely drop readline from ghci (as > > > some widely used Linux distributions, eg, Fedora 7 and Solaris doesn't > > > support sufficiently recent versions of editline). > > > > Indeed. I tried to build the editline package that was just uploaded to > > hackage and discovered that Gentoo does not package the editline C > > library at all. > > I spoke too soon. It is packaged as libedit (I was looking for > editline). I should probably note that on a few distros, the package named "editline" is the older, version 1.* of the library (which provides much less functionality), whereas "libedit" is version 2.* which is necessary for building my editline package. -Judah From chak at cse.unsw.edu.au Sun Jan 27 21:23:31 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Sun Jan 27 21:23:02 2008 Subject: Integrating editline with ghc In-Reply-To: <20080127230633.GA10144@matrix.chaos.earth.li> References: <6d74b0d20801161305na9e0732m2a6bae7098ec531d@mail.gmail.com> <478F1DB8.1080807@dfki.de> <20080117104733.47ea65ad.Malcolm.Wallace@cs.york.ac.uk> <8AE12C50-BB0F-4914-85F2-C21FC60D7F10@cse.unsw.edu.au> <4790A474.2060607@gmail.com> <6d74b0d20801240844u21486d82k979b6733b1aa5de9@mail.gmail.com> <141A525E-1A53-4C66-B1DB-20656FD50088@cse.unsw.edu.au> <20080127230633.GA10144@matrix.chaos.earth.li> Message-ID: <1D180534-AC98-43B8-A0AA-4A34D96338AB@cse.unsw.edu.au> Ian Lynagh: > On Sun, Jan 27, 2008 at 04:41:37PM +1100, Manuel M T Chakravarty > wrote: >> >> My conclusion: >> >> * The readline package stays as it is (stays GPL). > > I definitely agree with this. > >> * We add the new editline package (as a boot package) including >> Editline.Readline as the compatibility layer (is BSD3). > > And this. > >> * GHC uses configure magic to pick editline when available and >> readline otherwise. > > I think GHC should just always use editline. We already need to > support > using an in-tree editline for Windows, so we can also use it on other > platforms where editline isn't easily available or is too old. Also > supporting readline just makes the build system more complicated for > little extra benefit, and also means that there are more > configurations > to bitrot. Sure if you want to add another library into the tree that's an option. However, I am not so sure whether it's going to be as easy as with GMP. AFAIK libedit (which is the editline port used in Linux distributions - ) needs (n)curses. Their web page says somebody managed to compile on cygwin, but there is no mention of mingw. So, before committing to use editline/libedit on all platforms, it might be useful to make sure editline compiles fine everywhere. Manuel From judah.jacobson at gmail.com Sun Jan 27 22:55:35 2008 From: judah.jacobson at gmail.com (Judah Jacobson) Date: Sun Jan 27 22:55:03 2008 Subject: Integrating editline with ghc In-Reply-To: <1D180534-AC98-43B8-A0AA-4A34D96338AB@cse.unsw.edu.au> References: <6d74b0d20801161305na9e0732m2a6bae7098ec531d@mail.gmail.com> <478F1DB8.1080807@dfki.de> <20080117104733.47ea65ad.Malcolm.Wallace@cs.york.ac.uk> <8AE12C50-BB0F-4914-85F2-C21FC60D7F10@cse.unsw.edu.au> <4790A474.2060607@gmail.com> <6d74b0d20801240844u21486d82k979b6733b1aa5de9@mail.gmail.com> <141A525E-1A53-4C66-B1DB-20656FD50088@cse.unsw.edu.au> <20080127230633.GA10144@matrix.chaos.earth.li> <1D180534-AC98-43B8-A0AA-4A34D96338AB@cse.unsw.edu.au> Message-ID: <6d74b0d20801271955r43046ee6o80e9cf9c8932498@mail.gmail.com> On Jan 27, 2008 6:23 PM, Manuel M T Chakravarty wrote: > Ian Lynagh: > > > > > I think GHC should just always use editline. We already need to > > support > > using an in-tree editline for Windows, so we can also use it on other > > platforms where editline isn't easily available or is too old. Also > > supporting readline just makes the build system more complicated for > > little extra benefit, and also means that there are more > > configurations > > to bitrot. > > Sure if you want to add another library into the tree that's an > option. However, I am not so sure whether it's going to be as easy as > with GMP. AFAIK libedit (which is the editline port used in Linux > distributions - ) needs (n)curses. > Their web page says somebody managed to compile on cygwin, but there > is no mention of mingw. So, before committing to use editline/libedit > on all platforms, it might be useful to make sure editline compiles > fine everywhere. You may have seen this already, but it looks like libedit doesn't work on mingw: http://www.nabble.com/Re%3A-Integrating-editline-with-ghc-p14925360.html However, we already don't use readline on mingw, right? So I don't think that should be a strike against using editline exclusively. Also, a small correction: both readline and libedit only need termcap, not curses (which provides a termcap interface). -Judah From bulat.ziganshin at gmail.com Sun Jan 27 18:19:21 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Mon Jan 28 03:30:08 2008 Subject: Integrating editline with ghc In-Reply-To: <20080127230633.GA10144@matrix.chaos.earth.li> References: <6d74b0d20801161305na9e0732m2a6bae7098ec531d@mail.gmail.com> <478F1DB8.1080807@dfki.de> <20080117104733.47ea65ad.Malcolm.Wallace@cs.york.ac.uk> <8AE12C50-BB0F-4914-85F2-C21FC60D7F10@cse.unsw.edu.au> <4790A474.2060607@gmail.com> <6d74b0d20801240844u21486d82k979b6733b1aa5de9@mail.gmail.com> <141A525E-1A53-4C66-B1DB-20656FD50088@cse.unsw.edu.au> <20080127230633.GA10144@matrix.chaos.earth.li> Message-ID: <93353451.20080128021921@gmail.com> Hello Ian, Monday, January 28, 2008, 2:06:33 AM, you wrote: > I think GHC should just always use editline. We already need to support > using an in-tree editline for Windows, so we can also use it on other > platforms where editline isn't easily available or is too old. Also > supporting readline just makes the build system more complicated for > little extra benefit, and also means that there are more configurations > to bitrot. plus it will mean that sometime, without any notice, you used gpl'ed software - this may add more headache for commercial developers -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From simonmarhaskell at gmail.com Mon Jan 28 04:31:45 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Mon Jan 28 04:31:16 2008 Subject: Integrating editline with ghc In-Reply-To: <6d74b0d20801271955r43046ee6o80e9cf9c8932498@mail.gmail.com> References: <6d74b0d20801161305na9e0732m2a6bae7098ec531d@mail.gmail.com> <478F1DB8.1080807@dfki.de> <20080117104733.47ea65ad.Malcolm.Wallace@cs.york.ac.uk> <8AE12C50-BB0F-4914-85F2-C21FC60D7F10@cse.unsw.edu.au> <4790A474.2060607@gmail.com> <6d74b0d20801240844u21486d82k979b6733b1aa5de9@mail.gmail.com> <141A525E-1A53-4C66-B1DB-20656FD50088@cse.unsw.edu.au> <20080127230633.GA10144@matrix.chaos.earth.li> <1D180534-AC98-43B8-A0AA-4A34D96338AB@cse.unsw.edu.au> <6d74b0d20801271955r43046ee6o80e9cf9c8932498@mail.gmail.com> Message-ID: <479DA101.9040802@gmail.com> Judah Jacobson wrote: > On Jan 27, 2008 6:23 PM, Manuel M T Chakravarty wrote: >> Ian Lynagh: >>> I think GHC should just always use editline. We already need to >>> support >>> using an in-tree editline for Windows, so we can also use it on other >>> platforms where editline isn't easily available or is too old. Also >>> supporting readline just makes the build system more complicated for >>> little extra benefit, and also means that there are more >>> configurations >>> to bitrot. >> Sure if you want to add another library into the tree that's an >> option. However, I am not so sure whether it's going to be as easy as >> with GMP. AFAIK libedit (which is the editline port used in Linux >> distributions - ) needs (n)curses. >> Their web page says somebody managed to compile on cygwin, but there >> is no mention of mingw. So, before committing to use editline/libedit >> on all platforms, it might be useful to make sure editline compiles >> fine everywhere. > > You may have seen this already, but it looks like libedit doesn't work on mingw: > http://www.nabble.com/Re%3A-Integrating-editline-with-ghc-p14925360.html > > However, we already don't use readline on mingw, right? So I don't > think that should be a strike against using editline exclusively. Right, we don't compile GHCi against readline on Windows. I have built the readline package on Windows in the past, and even managed to get GHCi working with it, but it seems the MingW I have installed right now doesn't come with readline. IIRC readline on Windows didn't work very well in a normal Windows console. Windows console users already get up/down and primitive editing facilities courtesy of the built-in console support anyway. Personally I'd like to drop readline, if we can. As Ian says, if we leave both options in place that's another configuration variable to test, and something else to go wrong. If it means we have to drag editline into the tree, then that's fine by me - I'm thinking of dragging in gcc's libffi too (it's not GPL, FYI), so we're building up a little family of imported external libraries. Cheers, Simon From simonmarhaskell at gmail.com Mon Jan 28 06:28:23 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Mon Jan 28 06:28:41 2008 Subject: Proposal: Add variants of tails & inits not returning empty lists In-Reply-To: <20071214195326.GJ71713@elvis.mu.org> References: <20071214161738.GI71713@elvis.mu.org> <1433408180.20071214193442@gmail.com> <20071214195326.GJ71713@elvis.mu.org> Message-ID: <479DBC57.3070809@gmail.com> Maxime Henrion wrote: > Bulat Ziganshin wrote: >> Hello Maxime, >> >> Friday, December 14, 2007, 7:17:38 PM, you wrote: >> >>> I just opened a Trac ticket (#1979), to suggest the addition of the >> i have dozens of small funcs in my Utils.hs file. every experienced >> Haskeller has such set. are all these functions should be really added >> too? > > I am entirely open to discussion about whether these two functions > are useful enough to fit in the base libraries or not. I personally > feel that they are, seeing that I had to use them several times in > a relatively short period of time. I thus expect that many others > have needed to write those functions as well. This may very well > turn out to be a completely wrong :-). > > I guess one step towards is the answer would be knowing if you ever > needed those functions? For proposals like this, I think we need a significant number of people saying "yes please!", otherwise the default is for the code to go in without much discussion, and if we're not careful we end up adding things that are rarely useful. My data point: I've never used/needed inits1 or tails1, AFAIR, and I don't think "tail.inits" is too hard to write, so I vote against. Cheers, Simon From ndmitchell at gmail.com Mon Jan 28 06:44:02 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Mon Jan 28 06:43:28 2008 Subject: Proposal: Add variants of tails & inits not returning empty lists In-Reply-To: <479DBC57.3070809@gmail.com> References: <20071214161738.GI71713@elvis.mu.org> <1433408180.20071214193442@gmail.com> <20071214195326.GJ71713@elvis.mu.org> <479DBC57.3070809@gmail.com> Message-ID: <404396ef0801280344m59084ecq23cb9179e2e18fcd@mail.gmail.com> Hi > For proposals like this, I think we need a significant number of people > saying "yes please!", otherwise the default is for the code to go in > without much discussion, and if we're not careful we end up adding things > that are rarely useful. > > My data point: I've never used/needed inits1 or tails1, AFAIR, and I don't > think "tail.inits" is too hard to write, so I vote against. I vote against, unless new names can be found which give a more instant connection to the meaning. (I kind of said this in my original post, but should be a bit clearer I guess) Thanks Neil From john at repetae.net Mon Jan 28 15:46:30 2008 From: john at repetae.net (John Meacham) Date: Mon Jan 28 15:45:56 2008 Subject: Proposal: Add variants of tails & inits not returning empty lists In-Reply-To: <479DBC57.3070809@gmail.com> References: <20071214161738.GI71713@elvis.mu.org> <1433408180.20071214193442@gmail.com> <20071214195326.GJ71713@elvis.mu.org> <479DBC57.3070809@gmail.com> Message-ID: <20080128204629.GB26352@sliver.repetae.net> On Mon, Jan 28, 2008 at 11:28:23AM +0000, Simon Marlow wrote: > For proposals like this, I think we need a significant number of people > saying "yes please!", otherwise the default is for the code to go in > without much discussion, and if we're not careful we end up adding things > that are rarely useful. Maybe some sort of quorum is needed. Like, some percentage of interested parties must make their feelings known before a final decision is made. Or the default should be 'no' on new additions unless a lot of people chime in saying yes. John -- John Meacham - ?repetae.net?john? From chak at cse.unsw.edu.au Mon Jan 28 23:53:22 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Mon Jan 28 23:52:51 2008 Subject: Integrating editline with ghc In-Reply-To: <6d74b0d20801271955r43046ee6o80e9cf9c8932498@mail.gmail.com> References: <6d74b0d20801161305na9e0732m2a6bae7098ec531d@mail.gmail.com> <478F1DB8.1080807@dfki.de> <20080117104733.47ea65ad.Malcolm.Wallace@cs.york.ac.uk> <8AE12C50-BB0F-4914-85F2-C21FC60D7F10@cse.unsw.edu.au> <4790A474.2060607@gmail.com> <6d74b0d20801240844u21486d82k979b6733b1aa5de9@mail.gmail.com> <141A525E-1A53-4C66-B1DB-20656FD50088@cse.unsw.edu.au> <20080127230633.GA10144@matrix.chaos.earth.li> <1D180534-AC98-43B8-A0AA-4A34D96338AB@cse.unsw.edu.au> <6d74b0d20801271955r43046ee6o80e9cf9c8932498@mail.gmail.com> Message-ID: Judah Jacobson: > On Jan 27, 2008 6:23 PM, Manuel M T Chakravarty > wrote: >> Ian Lynagh: >>>> >>> I think GHC should just always use editline. We already need to >>> support >>> using an in-tree editline for Windows, so we can also use it on >>> other >>> platforms where editline isn't easily available or is too old. Also >>> supporting readline just makes the build system more complicated for >>> little extra benefit, and also means that there are more >>> configurations >>> to bitrot. >> >> Sure if you want to add another library into the tree that's an >> option. However, I am not so sure whether it's going to be as easy >> as >> with GMP. AFAIK libedit (which is the editline port used in Linux >> distributions - ) needs (n)curses. >> Their web page says somebody managed to compile on cygwin, but there >> is no mention of mingw. So, before committing to use editline/ >> libedit >> on all platforms, it might be useful to make sure editline compiles >> fine everywhere. > > You may have seen this already, but it looks like libedit doesn't > work on mingw: > http://www.nabble.com/Re%3A-Integrating-editline-with-ghc-p14925360.html > > However, we already don't use readline on mingw, right? So I don't > think that should be a strike against using editline exclusively. Ok, that simplifies matters. > Also, a small correction: both readline and libedit only need termcap, > not curses (which provides a termcap interface). At it says to link with gcc -o fileman fileman.c -ledit -lcurses and explicitly says "Note libcurses, as well as libedit, should be linked to Editline enabled programs". Manuel From judah.jacobson at gmail.com Tue Jan 29 00:10:28 2008 From: judah.jacobson at gmail.com (Judah Jacobson) Date: Tue Jan 29 00:09:54 2008 Subject: Integrating editline with ghc In-Reply-To: References: <6d74b0d20801161305na9e0732m2a6bae7098ec531d@mail.gmail.com> <8AE12C50-BB0F-4914-85F2-C21FC60D7F10@cse.unsw.edu.au> <4790A474.2060607@gmail.com> <6d74b0d20801240844u21486d82k979b6733b1aa5de9@mail.gmail.com> <141A525E-1A53-4C66-B1DB-20656FD50088@cse.unsw.edu.au> <20080127230633.GA10144@matrix.chaos.earth.li> <1D180534-AC98-43B8-A0AA-4A34D96338AB@cse.unsw.edu.au> <6d74b0d20801271955r43046ee6o80e9cf9c8932498@mail.gmail.com> Message-ID: <6d74b0d20801282110yb4c11bfo2d0156c088f555a2@mail.gmail.com> On Jan 28, 2008 8:53 PM, Manuel M T Chakravarty wrote: > Judah Jacobson: > > > On Jan 27, 2008 6:23 PM, Manuel M T Chakravarty > > wrote: > >> AFAIK libedit (which is the editline port used in Linux > >> distributions - ) needs (n)curses. > > > Also, a small correction: both readline and libedit only need termcap, > > not curses (which provides a termcap interface). > > At it says to link with > > gcc -o fileman fileman.c -ledit -lcurses > > and explicitly says "Note libcurses, as well as libedit, should be > linked to Editline enabled programs". Oh, sorry; I didn't see that. But when I looked through the source code and configure/build files of libedit, it seemed like it only needs libtermcap. I suspect that despite what it says on that site, either "-ledit -lcurses" or "-ledit -ltermcap" will work fine. Anyway, this is probably a moot point; I don't know of any modern systems that have termcap but not curses. (For example, on my system libtermcap.a is a symlink to libncurses.a.) Best, -Judah From twanvl at gmail.com Tue Jan 29 07:11:45 2008 From: twanvl at gmail.com (Twan van Laarhoven) Date: Tue Jan 29 07:11:00 2008 Subject: Proposal: Add concatMapM function (#2042) In-Reply-To: <478B90A4.4090807@gmail.com> References: <478B90A4.4090807@gmail.com> Message-ID: <479F1801.20801@gmail.com> Twan van Laarhoven wrote: > I have noticed that many projects include a 'concatMapM' function: > > concatMapM :: (Monad m) => (a -> m [b]) -> [a] -> m [b] > > Trac ticket: http://hackage.haskell.org/trac/ghc/ticket/2042 > Deadline for discussion: 2 weeks from now, January 28 Deadline <= now, so here is a summary of the discussion: 1. In favor: - Twan van Laarhoven - Isaac Dupree - Don Stewart - Neil Mitchell 2. Sidetracked with discussion of generalizations: - Yitzchak Gale - apfelmus - Ross Paterson 3. Opposed to any additions to the base library: - Bulat Ziganshin I think we should ignore the generalization to genericSuperDuperConcatMapMXYZ for now :). On the other hand, Bulat raises a valid point. Adding things to the base library might break some programs, although they will be easy enough to fix. But what do we do with Bulat's point in this specific case? I see two options: a. Don't add anything to the base libraries anymore, ever. b. Go ahead and add the function. Most users will see the change as they upgrade to ghc 6.10, which might break other minor things anyway. Twan From ndmitchell at gmail.com Tue Jan 29 07:18:44 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Tue Jan 29 07:18:08 2008 Subject: Proposal: Add concatMapM function (#2042) In-Reply-To: <479F1801.20801@gmail.com> References: <478B90A4.4090807@gmail.com> <479F1801.20801@gmail.com> Message-ID: <404396ef0801290418v4755f9f3n1ddd175c3e56d66e@mail.gmail.com> Hi > 1. In favor: > - Twan van Laarhoven > - Isaac Dupree > - Don Stewart > - Neil Mitchell > > 3. Opposed to any additions to the base library: > - Bulat Ziganshin I don't think 4 people is quite enough to overrule one persons objections, so I'd suggest that anyone reading this thread who does want this to go in (as it stands, without generalisation) should shout up now. I'd guess another couple of me-too's is enough to have a consensus. To add one more me-too, Matthew Naylor (http://www-users.cs.york.ac.uk/~mfn/) says: > (+1) Me too. Thanks Neil From conor at strictlypositive.org Tue Jan 29 07:25:23 2008 From: conor at strictlypositive.org (Conor McBride) Date: Tue Jan 29 07:24:35 2008 Subject: Proposal: Add concatMapM function (#2042) In-Reply-To: <479F1801.20801@gmail.com> References: <478B90A4.4090807@gmail.com> <479F1801.20801@gmail.com> Message-ID: <44D4CA01-6D1D-4A5C-B5D7-452A0D625A4C@strictlypositive.org> Hi On 29 Jan 2008, at 12:11, Twan van Laarhoven wrote: > I think we should ignore the generalization to > genericSuperDuperConcatMapMXYZ for now :). Why? Conor From ndmitchell at gmail.com Tue Jan 29 07:29:55 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Tue Jan 29 07:29:18 2008 Subject: Proposal: Add concatMapM function (#2042) In-Reply-To: <44D4CA01-6D1D-4A5C-B5D7-452A0D625A4C@strictlypositive.org> References: <478B90A4.4090807@gmail.com> <479F1801.20801@gmail.com> <44D4CA01-6D1D-4A5C-B5D7-452A0D625A4C@strictlypositive.org> Message-ID: <404396ef0801290429p174b707cjd14a9b7d138d68a2@mail.gmail.com> Hi > > I think we should ignore the generalization to > > genericSuperDuperConcatMapMXYZ for now :). > > Why? Orthogonality. It is silly to have have superConcatMapM, but not superMapM. If that wants doing it should be a separate proposal after this one. Thanks Neil From waldmann at imn.htwk-leipzig.de Tue Jan 29 07:40:47 2008 From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann) Date: Tue Jan 29 07:40:10 2008 Subject: Proposal: Add concatMapM function (#2042) In-Reply-To: <404396ef0801290429p174b707cjd14a9b7d138d68a2@mail.gmail.com> References: <478B90A4.4090807@gmail.com> <479F1801.20801@gmail.com> <44D4CA01-6D1D-4A5C-B5D7-452A0D625A4C@strictlypositive.org> <404396ef0801290429p174b707cjd14a9b7d138d68a2@mail.gmail.com> Message-ID: <479F1ECF.4000703@imn.htwk-leipzig.de> Neil Mitchell wrote: > Orthogonality. Indeed. If a proposed function's name is "fooBar", because it intends to be a combination of foo and bar, then "foo . bar" is already a perfect name. I think you'd recognize a useful abstraction by the fact that it has an obvious "stand-alone" name. Otherwise, it's not really an abstraction, is it? Best regards, Johannes Walmann. From conor at strictlypositive.org Tue Jan 29 07:53:41 2008 From: conor at strictlypositive.org (Conor McBride) Date: Tue Jan 29 07:52:55 2008 Subject: Proposal: Add concatMapM function (#2042) In-Reply-To: <404396ef0801290429p174b707cjd14a9b7d138d68a2@mail.gmail.com> References: <478B90A4.4090807@gmail.com> <479F1801.20801@gmail.com> <44D4CA01-6D1D-4A5C-B5D7-452A0D625A4C@strictlypositive.org> <404396ef0801290429p174b707cjd14a9b7d138d68a2@mail.gmail.com> Message-ID: <5155E4B6-6992-48F2-A33F-F599A066BE61@strictlypositive.org> Hi On 29 Jan 2008, at 12:29, Neil Mitchell wrote: > Hi > >>> I think we should ignore the generalization to >>> genericSuperDuperConcatMapMXYZ for now :). >> >> Why? > > Orthogonality. What's orthogonal to what, here? I'm trying to understand why the generalization is irrelevant (or merely unwelcome) to the discussion of whether or not the special case should be added to the library. > It is silly to have have superConcatMapM, but not > superMapM. If that wants doing it should be a separate proposal after > this one. If you peer at it closely, you'll notice that traverse is kind of like a generalized mapM. If you peer at it closely, you'll notice that concatMapM, apart from being unnecessarily specific to lists and unnecessarily specific to monads, is a newtype isotope of foldMap. Is it worth thinking a bit more about how to exploit the functionality that's already in the library? All the best Conor From nominolo at googlemail.com Tue Jan 29 07:53:42 2008 From: nominolo at googlemail.com (Thomas Schilling) Date: Tue Jan 29 07:54:41 2008 Subject: Proposal: Add concatMapM function (#2042) In-Reply-To: <404396ef0801290418v4755f9f3n1ddd175c3e56d66e@mail.gmail.com> References: <478B90A4.4090807@gmail.com> <479F1801.20801@gmail.com> <404396ef0801290418v4755f9f3n1ddd175c3e56d66e@mail.gmail.com> Message-ID: <1201611222.5858.1.camel@intothevoid> On Tue, 2008-01-29 at 12:18 +0000, Neil Mitchell wrote: > Hi > > > 1. In favor: > > - Twan van Laarhoven > > - Isaac Dupree > > - Don Stewart > > - Neil Mitchell > > > > 3. Opposed to any additions to the base library: > > - Bulat Ziganshin > Is concatMapM vs concat <$> mapM really such an improvement? Maybe the proposal should rather be to remove concatMap, for it is merely a 3-character shorter version of concat . map... > I don't think 4 people is quite enough to overrule one persons > objections, so I'd suggest that anyone reading this thread who does > want this to go in (as it stands, without generalisation) should shout > up now. I'd guess another couple of me-too's is enough to have a > consensus. > > To add one more me-too, Matthew Naylor > (http://www-users.cs.york.ac.uk/~mfn/) says: > > > (+1) Me too. > > Thanks > > Neil > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries From ndmitchell at gmail.com Tue Jan 29 08:08:54 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Tue Jan 29 08:08:17 2008 Subject: Proposal: Add concatMapM function (#2042) In-Reply-To: <1201611222.5858.1.camel@intothevoid> References: <478B90A4.4090807@gmail.com> <479F1801.20801@gmail.com> <404396ef0801290418v4755f9f3n1ddd175c3e56d66e@mail.gmail.com> <1201611222.5858.1.camel@intothevoid> Message-ID: <404396ef0801290508i57e4a495o6a2b299ffbb48a87@mail.gmail.com> Hi > Maybe the > proposal should rather be to remove concatMap, for it is merely a > 3-character shorter version of concat . map... Wrong, its a 5-character shorter version of (concat . map). It's those brackets that I appreciate the removal of. > Is concatMapM vs concat <$> mapM really such an improvement? Yes. It's 7 characters shorter than that. With 7 characters I could wipe my entire hard drive, those characters matter!! :-) Thanks Neil From igloo at earth.li Tue Jan 29 09:56:48 2008 From: igloo at earth.li (Ian Lynagh) Date: Tue Jan 29 09:56:13 2008 Subject: Proposal: Add concatMapM function (#2042) In-Reply-To: <404396ef0801290418v4755f9f3n1ddd175c3e56d66e@mail.gmail.com> References: <478B90A4.4090807@gmail.com> <479F1801.20801@gmail.com> <404396ef0801290418v4755f9f3n1ddd175c3e56d66e@mail.gmail.com> Message-ID: <20080129145648.GA14054@matrix.chaos.earth.li> On Tue, Jan 29, 2008 at 12:18:44PM +0000, Neil Mitchell wrote: > > > 1. In favor: > > - Twan van Laarhoven > > - Isaac Dupree > > - Don Stewart > > - Neil Mitchell > > > > 3. Opposed to any additions to the base library: > > - Bulat Ziganshin > > I don't think 4 people is quite enough to overrule one persons > objections, so I'd suggest that anyone reading this thread who does > want this to go in (as it stands, without generalisation) should shout > up now. I'd guess another couple of me-too's is enough to have a > consensus. I don't have much of an opinion about the particular function being discussed, but I'm strongly against freezing the base library at this point. Thanks Ian From lemming at henning-thielemann.de Tue Jan 29 10:35:28 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Tue Jan 29 10:34:50 2008 Subject: Proposal: Add concatMapM function (#2042) In-Reply-To: <479F1801.20801@gmail.com> References: <478B90A4.4090807@gmail.com> <479F1801.20801@gmail.com> Message-ID: On Tue, 29 Jan 2008, Twan van Laarhoven wrote: > Twan van Laarhoven wrote: > > I have noticed that many projects include a 'concatMapM' function: > > > > concatMapM :: (Monad m) => (a -> m [b]) -> [a] -> m [b] > > > > Trac ticket: http://hackage.haskell.org/trac/ghc/ticket/2042 > > Deadline for discussion: 2 weeks from now, January 28 > > Deadline <= now, so here is a summary of the discussion: > > 1. In favor: > - Twan van Laarhoven > - Isaac Dupree > - Don Stewart > - Neil Mitchell > > 2. Sidetracked with discussion of generalizations: > - Yitzchak Gale > - apfelmus > - Ross Paterson > > 3. Opposed to any additions to the base library: > - Bulat Ziganshin > > I think we should ignore the generalization to genericSuperDuperConcatMapMXYZ > for now :). On the other hand, Bulat raises a valid point. In consider Bulat's point as preservation of unfavorable coding style (namely unqualified anonymous import). This method does not scale well and you can motivate stop of any development this way. So I object to Bulat's argument, but not necessarily vote particularly for concatMapM, since I didn't need it so far - which can also mean, that I have always worked-around it without noticing it. I think a generalization to Traversal would be nice. This would make these classes certainly more useful. > Adding things to the > base library might break some programs, although they will be easy enough to > fix. But what do we do with Bulat's point in this specific case? I see two options: > > a. Don't add anything to the base libraries anymore, ever. The current state is: Prelude's list functions are imported automatically and unqualified and thus should not be extended. However Data.List functions must be imported explicitely and then should be imported qualified or by name. This does not only avoid name clashes but also simplifies reading programs. http://www.haskell.org/haskellwiki/Import_modules_properly > b. Go ahead and add the function. Most users will see the change as they > upgrade to ghc 6.10, which might break other minor things anyway. This would be a good opportunity to switch to a more friendly importing style. From lemming at henning-thielemann.de Tue Jan 29 10:42:30 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Tue Jan 29 10:41:51 2008 Subject: Proposal: Add concatMapM function (#2042) In-Reply-To: <1201611222.5858.1.camel@intothevoid> References: <478B90A4.4090807@gmail.com> <479F1801.20801@gmail.com> <404396ef0801290418v4755f9f3n1ddd175c3e56d66e@mail.gmail.com> <1201611222.5858.1.camel@intothevoid> Message-ID: On Tue, 29 Jan 2008, Thomas Schilling wrote: > On Tue, 2008-01-29 at 12:18 +0000, Neil Mitchell wrote: > > Hi > > > > > 1. In favor: > > > - Twan van Laarhoven > > > - Isaac Dupree > > > - Don Stewart > > > - Neil Mitchell > > > > > > 3. Opposed to any additions to the base library: > > > - Bulat Ziganshin > > > > Is concatMapM vs concat <$> mapM really such an improvement? Maybe the > proposal should rather be to remove concatMap, for it is merely a > 3-character shorter version of concat . map... "(concat . map f) xs" is 5 characters longer than "concatMap f xs" ! Alternatives concat $ map f xs concat (map f xs) What about zipWith concatMap vs. zipWith (\f -> concat . map f) So far I used concatMap a lot and thus I think it's addition was valuable. From bulat.ziganshin at gmail.com Tue Jan 29 11:06:01 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Tue Jan 29 11:31:50 2008 Subject: Proposal: Add concatMapM function (#2042) In-Reply-To: <479F1801.20801@gmail.com> References: <478B90A4.4090807@gmail.com> <479F1801.20801@gmail.com> Message-ID: <1836995806.20080129190601@gmail.com> Hello Twan, Tuesday, January 29, 2008, 3:11:45 PM, you wrote: > I think we should ignore the generalization to genericSuperDuperConcatMapMXYZ > for now :). On the other hand, Bulat raises a valid point. Adding things to the > base library might break some programs, although they will be easy enough to > fix. But what do we do with Bulat's point in this specific case? I see two options: i have several hundred one-liners in my Utils.hs. with such speed of adding these funcs to the base, you will add only these funcs the next 10 years. does this mean that haskell hackers will continue to mutate the language these next 10 years? :( i appeal to Haskell authorities - please agree with me in recognizing importance of language stability and take this decision. just a list of problems due to mutations in base library i've senn on the list in this few weeks: 1) hackage libs are compatible with only one version of ghc. in particular, when new version of ghc arrives, hackage is useless for it and this delays its adoption. some times later, this becomes pain for users of old ghc version. this also means that noone can just release his code as a library - he need to update it every year. moreover, this makes initiatives like cabal-install rather strange thing - that is advantage of automatic downloading/compilation if sometimes we need to edit cabal files? 2) unix ports are usually don't update to next ghc versions for a long time because this "breaks compilation of many things" 3) even shootout tests were not updated to 6.8 because it breaks compilation of these tests! 4) every week we see complaints from users who can't compile code written for previous ghc versions overall, i think that its hackers thinking - "required changes are trivial, so everyone can do it". there are many agents (non-haskellers, even non-programmers, automation tools) that can't do even trivial changes in haskell code/configs. and even for a experienced haskeller who was bothered to find info about required changes, this may be a good amount of work (when we change lot of modules/libs) and they have (like me) more restrictive requirements when we need to offer compatibility with many ghc versions so this is a headache without any real advantage. i propose to make new lib, supply it with the ghc, and include all new functionality here. at least this lib may be properly-versioned or not used at all -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From bulat.ziganshin at gmail.com Tue Jan 29 11:17:44 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Tue Jan 29 11:32:00 2008 Subject: Proposal: Add concatMapM function (#2042) In-Reply-To: <20080129145648.GA14054@matrix.chaos.earth.li> References: <478B90A4.4090807@gmail.com> <479F1801.20801@gmail.com> <404396ef0801290418v4755f9f3n1ddd175c3e56d66e@mail.gmail.com> <20080129145648.GA14054@matrix.chaos.earth.li> Message-ID: <1835178840.20080129191744@gmail.com> Hello Ian, Tuesday, January 29, 2008, 5:56:48 PM, you wrote: > I don't have much of an opinion about the particular function being > discussed, but I'm strongly against freezing the base library at this > point. reasons? when it should be freezed? as an example look at ghc itself - it's full of #ifdefs and borrowed libraries. is that organization is recommended haskell programming style? from my POV, base is dead body. it was possible to continue to split it into fragments while keeping backward compatibility and it was that i mean when proposed to do it. but this was not implemented in 6.8 so, i propose to does one of two things, either 1) freeze base and make new libs by *copying* code from there 2) add to ghc ability to reexport functions from other libs and make sure that new ghc will be compatible with old libs and vice versa anyway, i'm against adding new functions to base - please use library system with its versioning ability for this. why you want to inflate the only ghc library that can't be upgraded? :( btw, are you ever tried to compile old ghc versions with new ones - i bet that it will have the same compilation problems as my program :) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From bulat.ziganshin at gmail.com Tue Jan 29 11:53:44 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Tue Jan 29 11:54:13 2008 Subject: Proposal: Add concatMapM function (#2042) In-Reply-To: References: <478B90A4.4090807@gmail.com> <479F1801.20801@gmail.com> Message-ID: <236278152.20080129195344@gmail.com> Hello Henning, Tuesday, January 29, 2008, 6:35:28 PM, you wrote: > In consider Bulat's point as preservation of unfavorable coding style > (namely unqualified anonymous import). This method does not scale well and > you can motivate stop of any development this way. So I object to Bulat's > argument, but not necessarily vote particularly for concatMapM, since I > didn't need it so far - which can also mean, that I have always > worked-around it without noticing it. so you will prefer to add it immediately to 6.8.*? i wonder how much code you write and which tool you use. my tools can't automatically insert these imports and i don't have time to do this monkey work by hand - and anyway i consider as bad programming style trying to replace package manager with home-grown tricks. the actual problem is hard-wired base package -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From dons at galois.com Tue Jan 29 12:52:43 2008 From: dons at galois.com (Don Stewart) Date: Tue Jan 29 12:52:09 2008 Subject: Proposal: Add concatMapM function (#2042) In-Reply-To: <404396ef0801290418v4755f9f3n1ddd175c3e56d66e@mail.gmail.com> References: <478B90A4.4090807@gmail.com> <479F1801.20801@gmail.com> <404396ef0801290418v4755f9f3n1ddd175c3e56d66e@mail.gmail.com> Message-ID: <20080129175243.GA18863@scytale.galois.com> ndmitchell: > Hi > > > 1. In favor: > > - Twan van Laarhoven > > - Isaac Dupree > > - Don Stewart > > - Neil Mitchell > > > > 3. Opposed to any additions to the base library: > > - Bulat Ziganshin > > I don't think 4 people is quite enough to overrule one persons > objections, so I'd suggest that anyone reading this thread who does > want this to go in (as it stands, without generalisation) should shout > up now. I'd guess another couple of me-too's is enough to have a > consensus. > The problem is that the one objector is just fundamentally opposed to the very process of adding stuff to the base library, for this case and all others. Given that the consensus is that we *will* continue to improve the base library, this objection isn't relevant -- it doesn't address the proposal under consideration. Which leaves us with 4 in favour, and a few generalists. -- Don From ndmitchell at gmail.com Tue Jan 29 12:55:18 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Tue Jan 29 12:54:44 2008 Subject: Proposal: Add concatMapM function (#2042) In-Reply-To: <20080129175243.GA18863@scytale.galois.com> References: <478B90A4.4090807@gmail.com> <479F1801.20801@gmail.com> <404396ef0801290418v4755f9f3n1ddd175c3e56d66e@mail.gmail.com> <20080129175243.GA18863@scytale.galois.com> Message-ID: <404396ef0801290955x63ea705cj5562c23f5b30690a@mail.gmail.com> Hi > The problem is that the one objector is just fundamentally opposed to > the very process of adding stuff to the base library, for this case > and all others. True - I guess it must be objections to code, not to process to actually be a problem. > Which leaves us with 4 in favour, and a few generalists. 5, Matt Naylor as well. I really can't believe that everyone doesn't want this, I define concatMapM in so many programs.... Thanks Neil From waldmann at imn.htwk-leipzig.de Tue Jan 29 13:13:17 2008 From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann) Date: Tue Jan 29 13:12:48 2008 Subject: Proposal: Add concatMapM function (#2042) In-Reply-To: <20080129175243.GA18863@scytale.galois.com> References: <478B90A4.4090807@gmail.com> <479F1801.20801@gmail.com> <404396ef0801290418v4755f9f3n1ddd175c3e56d66e@mail.gmail.com> <20080129175243.GA18863@scytale.galois.com> Message-ID: <479F6CBD.3090009@imn.htwk-leipzig.de> >>> 3. Opposed to any additions to the base library: >>> - Bulat Ziganshin Add me to this list. "base" is not a convenience library, it should contain fundamentally important stuff. Cf. java.lang, which "Provides classes that are fundamental to the design of the Java programming language" http://java.sun.com/javase/6/docs/api/java/lang/package-summary.html The emphasis (I think) is on *design* of the *language*. Best regards, Johannes Waldmann. From dons at galois.com Tue Jan 29 13:17:49 2008 From: dons at galois.com (Don Stewart) Date: Tue Jan 29 13:17:20 2008 Subject: Proposal: Add concatMapM function (#2042) In-Reply-To: <479F6CBD.3090009@imn.htwk-leipzig.de> References: <478B90A4.4090807@gmail.com> <479F1801.20801@gmail.com> <404396ef0801290418v4755f9f3n1ddd175c3e56d66e@mail.gmail.com> <20080129175243.GA18863@scytale.galois.com> <479F6CBD.3090009@imn.htwk-leipzig.de> Message-ID: <20080129181749.GD18863@scytale.galois.com> waldmann: > > >>> 3. Opposed to any additions to the base library: > >>> - Bulat Ziganshin > > Add me to this list. > > "base" is not a convenience library, > it should contain fundamentally important stuff. I think the Prelude is our equivalent here. base itself is fundamental stuff, plus what we use a lot. > > Cf. java.lang, which "Provides classes that are fundamental > to the design of the Java programming language" > http://java.sun.com/javase/6/docs/api/java/lang/package-summary.html > > The emphasis (I think) is on *design* of the *language*. If the proposal is that nothing new be added to base, that needs to be done separately. And a case made for why what we have at the moment is fundamental, excluding all else. Remember, this is not a discussion about whether things are to be added to base -- we did that a year ago, and the library process is the result. -- Don From lemming at henning-thielemann.de Tue Jan 29 13:50:35 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Tue Jan 29 13:49:55 2008 Subject: Proposal: Add concatMapM function (#2042) In-Reply-To: <236278152.20080129195344@gmail.com> References: <478B90A4.4090807@gmail.com> <479F1801.20801@gmail.com> <236278152.20080129195344@gmail.com> Message-ID: On Tue, 29 Jan 2008, Bulat Ziganshin wrote: > Hello Henning, > > Tuesday, January 29, 2008, 6:35:28 PM, you wrote: > > > In consider Bulat's point as preservation of unfavorable coding style > > (namely unqualified anonymous import). This method does not scale well and > > you can motivate stop of any development this way. So I object to Bulat's > > argument, but not necessarily vote particularly for concatMapM, since I > > didn't need it so far - which can also mean, that I have always > > worked-around it without noticing it. > > so you will prefer to add it immediately to 6.8.*? Why a GHC version? I thought that we speak about the 'base' package. > i wonder how much code you write enough each day > and which tool you use. NEdit. I use almost only qualified imports and named imports and have my modules designed to be used in this way, write signatures for all top-level variables and use -Wall. > my tools can't automatically insert these imports and i don't have time > to do this monkey work by hand - and anyway i consider as bad > programming style trying to replace package manager with home-grown > tricks. What tricks? From lemming at henning-thielemann.de Tue Jan 29 13:54:18 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Tue Jan 29 13:53:38 2008 Subject: Proposal: Add concatMapM function (#2042) In-Reply-To: <479F6CBD.3090009@imn.htwk-leipzig.de> References: <478B90A4.4090807@gmail.com> <479F1801.20801@gmail.com> <404396ef0801290418v4755f9f3n1ddd175c3e56d66e@mail.gmail.com> <20080129175243.GA18863@scytale.galois.com> <479F6CBD.3090009@imn.htwk-leipzig.de> Message-ID: On Tue, 29 Jan 2008, Johannes Waldmann wrote: > > >>> 3. Opposed to any additions to the base library: > >>> - Bulat Ziganshin > > Add me to this list. > > "base" is not a convenience library, > it should contain fundamentally important stuff. > > Cf. java.lang, which "Provides classes that are fundamental > to the design of the Java programming language" > http://java.sun.com/javase/6/docs/api/java/lang/package-summary.html > > The emphasis (I think) is on *design* of the *language*. The question is - where to add it, if not to Data.List? We could setup new Data.List.Extras. But this would have the same problem like Data.List. Is the solution to move Data.List from 'base' to 'containers' or so, since the basic list functions are already in Prelude? From bulat.ziganshin at gmail.com Tue Jan 29 13:31:18 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Tue Jan 29 14:15:30 2008 Subject: Proposal: Add concatMapM function (#2042) In-Reply-To: <404396ef0801290955x63ea705cj5562c23f5b30690a@mail.gmail.com> References: <478B90A4.4090807@gmail.com> <479F1801.20801@gmail.com> <404396ef0801290418v4755f9f3n1ddd175c3e56d66e@mail.gmail.com> <20080129175243.GA18863@scytale.galois.com> <404396ef0801290955x63ea705cj5562c23f5b30690a@mail.gmail.com> Message-ID: <68334025.20080129213118@gmail.com> Hello Neil, Tuesday, January 29, 2008, 8:55:18 PM, you wrote: > 5, Matt Naylor as well. I really can't believe that everyone doesn't > want this, I define concatMapM in so many programs.... i'm against this exactly because i use (and define) it in my program. freearc was already broken with 6.8 due to introduction of 'forever' and i don't like it to broke with every new major ghc version (or even minor one as some purists prefer). i wonder whether noone here write software that may be compiled by people outside of haskell island? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From wnoise at ofb.net Tue Jan 29 14:23:46 2008 From: wnoise at ofb.net (Aaron Denney) Date: Tue Jan 29 14:23:19 2008 Subject: Proposal: Add concatMapM function (#2042) References: <478B90A4.4090807@gmail.com> <479F1801.20801@gmail.com> <1836995806.20080129190601@gmail.com> Message-ID: On 2008-01-29, Bulat Ziganshin wrote: > Hello Twan, > > Tuesday, January 29, 2008, 3:11:45 PM, you wrote: > >> I think we should ignore the generalization to genericSuperDuperConcatMapMXYZ >> for now :). On the other hand, Bulat raises a valid point. Adding things to the >> base library might break some programs, although they will be easy enough to >> fix. But what do we do with Bulat's point in this specific case? I see two options: > > i have several hundred one-liners in my Utils.hs. with such speed of > adding these funcs to the base, you will add only these funcs the next > 10 years. does this mean that haskell hackers will continue to mutate > the language these next 10 years? :( That's the whole point of "avoiding success" -- so we can continue to make changes. -- Aaron Denney -><- From bulat.ziganshin at gmail.com Tue Jan 29 14:51:50 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Tue Jan 29 14:54:01 2008 Subject: Proposal: Add concatMapM function (#2042) In-Reply-To: References: <478B90A4.4090807@gmail.com> <479F1801.20801@gmail.com> <404396ef0801290418v4755f9f3n1ddd175c3e56d66e@mail.gmail.com> <20080129175243.GA18863@scytale.galois.com> <479F6CBD.3090009@imn.htwk-leipzig.de> Message-ID: <259254796.20080129225150@gmail.com> Hello Henning, Tuesday, January 29, 2008, 9:54:18 PM, you wrote: > The question is - where to add it, if not to Data.List? We could setup new > Data.List.Extras. But this would have the same problem like Data.List. > Is the solution to move Data.List from 'base' to 'containers' or so, since > the basic list functions are already in Prelude? the whole problem is that base is hard-wired with ghc and CAN'T BE UPGRADED. so i propose to add new package for all those new funcs and freeze base to solve problem of ghc versions incompatibility -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From bulat.ziganshin at gmail.com Tue Jan 29 14:53:15 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Tue Jan 29 14:54:12 2008 Subject: Proposal: Add concatMapM function (#2042) In-Reply-To: References: <478B90A4.4090807@gmail.com> <479F1801.20801@gmail.com> <1836995806.20080129190601@gmail.com> Message-ID: <928979263.20080129225315@gmail.com> Hello Aaron, Tuesday, January 29, 2008, 10:23:46 PM, you wrote: >> i have several hundred one-liners in my Utils.hs. with such speed of >> adding these funcs to the base, you will add only these funcs the next >> 10 years. does this mean that haskell hackers will continue to mutate >> the language these next 10 years? :( > That's the whole point of "avoiding success" -- so we can continue to > make changes. well, you want haskell that remains hacker's tool, i want haskell used for development of real programs, such as darcs and ghc itself -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From wnoise at ofb.net Tue Jan 29 15:40:23 2008 From: wnoise at ofb.net (Aaron Denney) Date: Tue Jan 29 15:39:56 2008 Subject: Proposal: Add concatMapM function (#2042) References: <478B90A4.4090807@gmail.com> <479F1801.20801@gmail.com> <1836995806.20080129190601@gmail.com> <928979263.20080129225315@gmail.com> Message-ID: On 2008-01-29, Bulat Ziganshin wrote: > Hello Aaron, > > Tuesday, January 29, 2008, 10:23:46 PM, you wrote: > >>> i have several hundred one-liners in my Utils.hs. with such speed of >>> adding these funcs to the base, you will add only these funcs the next >>> 10 years. does this mean that haskell hackers will continue to mutate >>> the language these next 10 years? :( > >> That's the whole point of "avoiding success" -- so we can continue to >> make changes. > > well, you want haskell that remains hacker's tool, i want haskell used > for development of real programs, such as darcs and ghc itself "Researchers' tool", rather. Hackers write programs that import entire modules willy-nilly. Real program can afford to import selectively or qualified for future proofing. A thought: perhaps Haskell prime should have local definitions shadow imported ones, rather than conflicting. Mandating a warning might be worth it though. -- Aaron Denney -><- From bulat.ziganshin at gmail.com Tue Jan 29 15:58:23 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Tue Jan 29 16:13:37 2008 Subject: Proposal: Add concatMapM function (#2042) In-Reply-To: References: <478B90A4.4090807@gmail.com> <479F1801.20801@gmail.com> <1836995806.20080129190601@gmail.com> <928979263.20080129225315@gmail.com> Message-ID: <68390614.20080129235823@gmail.com> Hello Aaron, Tuesday, January 29, 2008, 11:40:23 PM, you wrote: >> well, you want haskell that remains hacker's tool, i want haskell used >> for development of real programs, such as darcs and ghc itself > "Researchers' tool", rather. Hackers write programs that import entire > modules willy-nilly. Real program can afford to import selectively or > qualified for future proofing. yes, "real programs" can even afford to be coded in C. i use haskell to speed up development, though -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From duncan.coutts at worc.ox.ac.uk Wed Jan 30 05:53:26 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Jan 30 05:52:49 2008 Subject: Proposal: Add concatMapM function (#2042) In-Reply-To: <5155E4B6-6992-48F2-A33F-F599A066BE61@strictlypositive.org> References: <478B90A4.4090807@gmail.com> <479F1801.20801@gmail.com> <44D4CA01-6D1D-4A5C-B5D7-452A0D625A4C@strictlypositive.org> <404396ef0801290429p174b707cjd14a9b7d138d68a2@mail.gmail.com> <5155E4B6-6992-48F2-A33F-F599A066BE61@strictlypositive.org> Message-ID: <1201690406.13130.2.camel@localhost> On Tue, 2008-01-29 at 12:53 +0000, Conor McBride wrote: > What's orthogonal to what, here? I'm trying > to understand why the generalization is > irrelevant (or merely unwelcome) to the > discussion of whether or not the special case > should be added to the library. I think the point is that it'd be a bit inconsistent if the only function in Control.Monad that was generalised to arbitrary Traversable, Monoid etc was concatMapM. The point continues that if we do indeed want to generalise all the functions in Data.List and/or Control.Monad then that should be a separate proposal. Duncan From haskell at list.mightyreason.com Wed Jan 30 06:23:26 2008 From: haskell at list.mightyreason.com (ChrisK) Date: Wed Jan 30 06:22:53 2008 Subject: Security Notice: Buffer overflow fixed in PCRE library Message-ID: <47A05E2E.2070401@list.mightyreason.com> The PCRE library has just fixed a buffer overflow (related to UTF-8 mode). There are several haskell wrappers for the pcre library. If you use a wrapper for the PCRE library (libpcre) then you may want to upgrade the underlying library. http://pcre.org/news.txt states: > News about PCRE releases > ------------------------ > > Release 7.6 28-Jan-08 > --------------------- > > The main reason for having this release so soon after 7.5 is because it fixes a > potential buffer overflow problem in pcre_compile() when run in UTF-8 mode. In > addition, the CMake configuration files have been brought up to date. Cheers, Chris From conor at strictlypositive.org Wed Jan 30 07:07:33 2008 From: conor at strictlypositive.org (Conor McBride) Date: Wed Jan 30 07:06:44 2008 Subject: Proposal: Add concatMapM function (#2042) In-Reply-To: <1201690406.13130.2.camel@localhost> References: <478B90A4.4090807@gmail.com> <479F1801.20801@gmail.com> <44D4CA01-6D1D-4A5C-B5D7-452A0D625A4C@strictlypositive.org> <404396ef0801290429p174b707cjd14a9b7d138d68a2@mail.gmail.com> <5155E4B6-6992-48F2-A33F-F599A066BE61@strictlypositive.org> <1201690406.13130.2.camel@localhost> Message-ID: Hi Duncan On 30 Jan 2008, at 10:53, Duncan Coutts wrote: > > On Tue, 2008-01-29 at 12:53 +0000, Conor McBride wrote: > >> What's orthogonal to what, here? I'm trying >> to understand why the generalization is >> irrelevant (or merely unwelcome) to the >> discussion of whether or not the special case >> should be added to the library. > > I think the point is that it'd be a bit inconsistent if the only > function in Control.Monad that was generalised to arbitrary > Traversable, > Monoid etc was concatMapM. This may be a reasonable distinction between concerns, but they're hardly orthogonal. The question of whether or not such generalizations are likely or desirable, sooner or later, is clearly relevant to the issue of how lame a duck concatMapM is likely to be, hence whether or not it should be added. > The point continues that if we do indeed want > to generalise all the functions in Data.List and/or Control.Monad then > that should be a separate proposal. An interesting question is the extent to which this has already happened. My issue with concatMapM has, all along, been that it is a special case of foldMap, given the appropriate instance of Data.Monoid. We don't have to contemplate adding a new super duper general thrudsplingblatter to the library, giving it a silly name the better to travesty the mere suggestion, because foldMap is already in the library: it's a question of learning to make more and better use of it. I guess I'm advocating a general policy of "more structures; fewer functions", exploiting the power of instance inference to deliver the usual structure-respecting whatever, rather than giving all the instances individual names. Less is more. Or maybe I'm just a grumpy old math-troll trying to hassle people away from getting on in the obvious manner with some obviously desirable functionality. You choose Conor From ross at soi.city.ac.uk Wed Jan 30 07:31:10 2008 From: ross at soi.city.ac.uk (Ross Paterson) Date: Wed Jan 30 07:30:32 2008 Subject: Proposal: Add concatMapM function (#2042) In-Reply-To: <479F1801.20801@gmail.com> References: <478B90A4.4090807@gmail.com> <479F1801.20801@gmail.com> Message-ID: <20080130123110.GA12822@soi.city.ac.uk> On Tue, Jan 29, 2008 at 01:11:45PM +0100, Twan van Laarhoven wrote: > I think we should ignore the generalization to > genericSuperDuperConcatMapMXYZ for now :). Why? I think the fact that this is a special case argues against inclusion in the core libraries. Also that it's a simple compound of existing functions. It seems there's a philosophical difference here, which has come up before (in the intercalate and &&& discussions, and probably others). Some feel that the purpose of the library is to make programs shorter, so it should have names for every common idiom and special case. On the other hand there's the view that the core libraries should be a smallish collection of general primitives with little overlap, so that programmers can become familiar with a powerful but manageable toolkit. Jon Fairbairn expanded on this viewpoint in a previous discussion. In this view, concatMap itself was a mistake, which must be retained for backward compatibility, but should not be used as a model for the future. If we are interested in accomodating both views, perhaps separate packages are the way to go. From igloo at earth.li Wed Jan 30 08:20:37 2008 From: igloo at earth.li (Ian Lynagh) Date: Wed Jan 30 08:19:58 2008 Subject: Proposal: Add concatMapM function (#2042) In-Reply-To: <1835178840.20080129191744@gmail.com> References: <478B90A4.4090807@gmail.com> <479F1801.20801@gmail.com> <404396ef0801290418v4755f9f3n1ddd175c3e56d66e@mail.gmail.com> <20080129145648.GA14054@matrix.chaos.earth.li> <1835178840.20080129191744@gmail.com> Message-ID: <20080130132036.GA13188@matrix.chaos.earth.li> Hi Bulat, On Tue, Jan 29, 2008 at 07:17:44PM +0300, Bulat Ziganshin wrote: > > Tuesday, January 29, 2008, 5:56:48 PM, you wrote: > > > I don't have much of an opinion about the particular function being > > discussed, but I'm strongly against freezing the base library at this > > point. > > reasons? I don't want to get into a long discussion about this, because I don't think we're going change our viewpoints, but the reason is because I think that freezing it would cause more pain overall. I would like to see some significant changes to the base package, e.g. in how exceptions are implemented (to avoid the gigantic import cycle that the current implementation causes, and also because I think Simon's proposed replacement is nicer to use). > when it should be freezed? I'm not sure it ever should, but it would have to be an awful lot smaller first in my opinion. > as an example look at ghc itself - it's full of #ifdefs and borrowed > libraries. is that organization is recommended haskell programming style? GHC tries to be buildable with just a plain GHC install, no extra or upgraded libraries, going back as many GHC versions as possible. That's because of the hassle of bootstrapping it again if you fall too far behind. I wouldn't recommend for other Haskell code to go to such lengths. Thanks Ian From simonmarhaskell at gmail.com Thu Jan 31 06:15:58 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Thu Jan 31 06:15:20 2008 Subject: Proposal: Add concatMapM function (#2042) In-Reply-To: <259254796.20080129225150@gmail.com> References: <478B90A4.4090807@gmail.com> <479F1801.20801@gmail.com> <404396ef0801290418v4755f9f3n1ddd175c3e56d66e@mail.gmail.com> <20080129175243.GA18863@scytale.galois.com> <479F6CBD.3090009@imn.htwk-leipzig.de> <259254796.20080129225150@gmail.com> Message-ID: <47A1ADEE.80407@gmail.com> Bulat Ziganshin wrote: > Hello Henning, > > Tuesday, January 29, 2008, 9:54:18 PM, you wrote: > >> The question is - where to add it, if not to Data.List? We could setup new >> Data.List.Extras. But this would have the same problem like Data.List. >> Is the solution to move Data.List from 'base' to 'containers' or so, since >> the basic list functions are already in Prelude? > > the whole problem is that base is hard-wired with ghc and CAN'T BE > UPGRADED. so i propose to add new package for all those new funcs and > freeze base to solve problem of ghc versions incompatibility Freezing base is a bad idea. - we'd end up with silly packages called things like 'listexts' with Data.List.Exts. - we have no way of evolving the design of the libraries, no way to make improvements. We're stuck with a design which is widely acknowledged to be lacking in various serious ways (e.g. no Unicode in the IO library). What we propose to do instead is to provide better support for backwards compatibility. I'm honestly not sure whether this will lead to more problems, or whether it will just work nicely, but it's pretty clear we have to try. Before responding, take a good read through http://hackage.haskell.org/trac/ghc/wiki/PackageCompatibility In particular, I think the most practical approach is 4.3, although this doesn't give complete backwards compatibility. If you have a better suggestion, let's hear it - but please nothing of the form "oh, it must be possible to just do X", think about all the ramifications of "just doing X" and add a proposal to the wiki page, or write a new page. In addition to this, we need to get packages using the Package Versioning Policy: http://haskell.org/haskellwiki/Package_versioning_policy For this we need support in Cabal and/or Hackage. By the time we release GHC 6.10, we want most packages in Hackage using accurate dependencies, so that the majority will continue to work with GHC 6.10. Something else we have to think about is upgrades. We're now commonly seeing multiple versions of packages installed, leading to problems when resolving dependencies ends up with two different versions of a given package, and type errors ensue. It's probably time to start a new wiki page for thinking about solutions to this. Cheers, Simon From johan.tibell at gmail.com Thu Jan 31 06:35:06 2008 From: johan.tibell at gmail.com (Johan Tibell) Date: Thu Jan 31 06:34:23 2008 Subject: Proposal: Add concatMapM function (#2042) In-Reply-To: <47A1ADEE.80407@gmail.com> References: <478B90A4.4090807@gmail.com> <479F1801.20801@gmail.com> <404396ef0801290418v4755f9f3n1ddd175c3e56d66e@mail.gmail.com> <20080129175243.GA18863@scytale.galois.com> <479F6CBD.3090009@imn.htwk-leipzig.de> <259254796.20080129225150@gmail.com> <47A1ADEE.80407@gmail.com> Message-ID: <90889fe70801310335rffc281fof0cb4e4eddc9c346@mail.gmail.com> > Freezing base is a bad idea. > > - we'd end up with silly packages called things like 'listexts' with > Data.List.Exts. > > - we have no way of evolving the design of the libraries, no way to > make improvements. We're stuck with a design which is widely > acknowledged to be lacking in various serious ways (e.g. no Unicode > in the IO library). I've been thinking about this lately. As you mentioned, we have functions that do I/O with Strings. These functions can be split up into two groups: * Those who do binary I/O but (ab)use String to store binary data (e.g. the socket API.) We might want to change their type to [Word8] or something similar. * Those who do text I/O. We might want to add an encoding parameter to those or add other, identical functions that takes the encoding as a parameter and use a default encoding for the functions that lack explicit encoding. e.g. > readFile :: FilePath -> IO String -- defaults to some encoding > readFileWithEnc :: Encoding -> FilePath -> IO String -- explicit encoding, should have a better function name > data Encoding = Ascii | Utf8 | Utf16 -- no ALL CAPS pretty please! > decode :: Encoding -> [Word8] -> String -- you read something from a socket, now you want to decode it How would such a change fit into the package compatibility proposal number 4.3? Isn't there also an interaction with the Haskell' spec here as well if it defines a few of those functions? -- Johan From bulat.ziganshin at gmail.com Thu Jan 31 08:13:08 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Thu Jan 31 09:09:31 2008 Subject: Proposal: Add concatMapM function (#2042) In-Reply-To: <90889fe70801310335rffc281fof0cb4e4eddc9c346@mail.gmail.com> References: <478B90A4.4090807@gmail.com> <479F1801.20801@gmail.com> <404396ef0801290418v4755f9f3n1ddd175c3e56d66e@mail.gmail.com> <20080129175243.GA18863@scytale.galois.com> <479F6CBD.3090009@imn.htwk-leipzig.de> <259254796.20080129225150@gmail.com> <47A1ADEE.80407@gmail.com> <90889fe70801310335rffc281fof0cb4e4eddc9c346@mail.gmail.com> Message-ID: <1508723353.20080131161308@gmail.com> Hello Johan, Thursday, January 31, 2008, 2:35:06 PM, you wrote: > * Those who do text I/O. We might want to add an encoding parameter to > those or add other, identical functions that takes the encoding as a > parameter and use a default encoding for the functions that lack > explicit encoding. e.g. >> readFile :: FilePath -> IO String -- defaults to some encoding >> readFileWithEnc :: Encoding -> FilePath -> IO String -- explicit encoding, should have a better function name i can quickly tell why it's bad idea. it doubles amount of i/o functions just for this particular need. then you will notice that we also need functions which don't lock Handle or add some other processing and number of functions will double again and again i don't even say that for practical programming you will quickly find that passing encoding for particular file down all the functions that work with it is a nightmare the right way to deal with "modifiers" is to attach them to the Handle itself like this: f <- openFile "name" >>= withLocking >>= withEncoding utf8 and now look at http://haskell.org/haskellwiki/Library/Streams ;) > data Encoding = Ascii | Utf8 | Utf16 -- no ALL CAPS pretty please! btw, it's another bad idea which means that set of encodings cannot be changed without changing library. it will be especially "great" if we will hard-code this into base, meaning that in order to get support for new encodings you should upgrade your ghc and any new encodings will become available for ghc users ONE YEAR AFTER actual implementation in FP language, the best way to provide encoding is to define it as pair of functions: data Encoding = Encoding { encode :: String -> String , decode :: String -> String } utf8 = Encoding encodeUtf8 decodeUtf8 -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From johan.tibell at gmail.com Thu Jan 31 10:05:21 2008 From: johan.tibell at gmail.com (Johan Tibell) Date: Thu Jan 31 10:04:42 2008 Subject: Proposal: Add concatMapM function (#2042) In-Reply-To: <1508723353.20080131161308@gmail.com> References: <478B90A4.4090807@gmail.com> <479F1801.20801@gmail.com> <404396ef0801290418v4755f9f3n1ddd175c3e56d66e@mail.gmail.com> <20080129175243.GA18863@scytale.galois.com> <479F6CBD.3090009@imn.htwk-leipzig.de> <259254796.20080129225150@gmail.com> <47A1ADEE.80407@gmail.com> <90889fe70801310335rffc281fof0cb4e4eddc9c346@mail.gmail.com> <1508723353.20080131161308@gmail.com> Message-ID: <90889fe70801310705x5fa02ccbo8a2eacbaf131df02@mail.gmail.com> On Jan 31, 2008 2:13 PM, Bulat Ziganshin wrote: > Hello Johan, > > Thursday, January 31, 2008, 2:35:06 PM, you wrote: > > > * Those who do text I/O. We might want to add an encoding parameter to > > those or add other, identical functions that takes the encoding as a > > parameter and use a default encoding for the functions that lack > > explicit encoding. e.g. > > >> readFile :: FilePath -> IO String -- defaults to some encoding > >> readFileWithEnc :: Encoding -> FilePath -> IO String -- explicit encoding, should have a better function name > > i can quickly tell why it's bad idea. it doubles amount of i/o > functions just for this particular need. then you will notice that we > also need functions which don't lock Handle or add some other > processing and number of functions will double again and again > > i don't even say that for practical programming you will quickly find > that passing encoding for particular file down all the functions that > work with it is a nightmare > > the right way to deal with "modifiers" is to attach them to the Handle > itself like this: > > f <- openFile "name" >>= withLocking >>= withEncoding utf8 > > and now look at http://haskell.org/haskellwiki/Library/Streams ;) > > > > data Encoding = Ascii | Utf8 | Utf16 -- no ALL CAPS pretty please! > > btw, it's another bad idea which means that set of encodings cannot be > changed without changing library. it will be especially "great" if we > will hard-code this into base, meaning that in order to get support > for new encodings you should upgrade your ghc and any new encodings > will become available for ghc users ONE YEAR AFTER actual implementation > > in FP language, the best way to provide encoding is to define it as > pair of functions: > > data Encoding = Encoding { encode :: String -> String > , decode :: String -> String } > > utf8 = Encoding encodeUtf8 decodeUtf8 Just to be clear here. I don't care (for the purpose of this email) what these functions will look like. I just provided some random examples. I was asking how changes to existing functions would be handled. It's interesting to hear your ideas on the topic none the less. :) -- Johan From waldmann at imn.htwk-leipzig.de Thu Jan 31 10:10:14 2008 From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann) Date: Thu Jan 31 10:09:32 2008 Subject: Proposal: Add concatMapM function (#2042) In-Reply-To: <1508723353.20080131161308@gmail.com> References: <478B90A4.4090807@gmail.com> <479F1801.20801@gmail.com> <404396ef0801290418v4755f9f3n1ddd175c3e56d66e@mail.gmail.com> <20080129175243.GA18863@scytale.galois.com> <479F6CBD.3090009@imn.htwk-leipzig.de> <259254796.20080129225150@gmail.com> <47A1ADEE.80407@gmail.com> <90889fe70801310335rffc281fof0cb4e4eddc9c346@mail.gmail.com> <1508723353.20080131161308@gmail.com> Message-ID: <47A1E4D6.9000806@imn.htwk-leipzig.de> Bulat Ziganshin wrote: (very sound software engineering arguments - can someone with The Force please copy Bulat's mail to Haskell/Category/Style ...) I agree completely, and just add one remark here : > data Encoding = Encoding { encode :: String -> String > , decode :: String -> String } > > utf8 = Encoding encodeUtf8 decodeUtf8 this is in fact a method table (Java speak) or a dictionary (Haskell), and Encoding is the interface (class) - except that we can have local instances by passing around dictionaries explicitly. This is similar to passing a Comparator object to some sorting routine. Best regards, Johannes. PS: go read any honest OO book on the benefits of interface oriented design - they know this stuff - they got there the hard way (that is, via C++ :-) From johan.tibell at gmail.com Thu Jan 31 10:19:40 2008 From: johan.tibell at gmail.com (Johan Tibell) Date: Thu Jan 31 10:25:06 2008 Subject: Proposal: Add concatMapM function (#2042) In-Reply-To: <47A1E4D6.9000806@imn.htwk-leipzig.de> References: <478B90A4.4090807@gmail.com> <404396ef0801290418v4755f9f3n1ddd175c3e56d66e@mail.gmail.com> <20080129175243.GA18863@scytale.galois.com> <479F6CBD.3090009@imn.htwk-leipzig.de> <259254796.20080129225150@gmail.com> <47A1ADEE.80407@gmail.com> <90889fe70801310335rffc281fof0cb4e4eddc9c346@mail.gmail.com> <1508723353.20080131161308@gmail.com> <47A1E4D6.9000806@imn.htwk-leipzig.de> Message-ID: <90889fe70801310719m28da6064h740f930086453aaa@mail.gmail.com> On Jan 31, 2008 4:10 PM, Johannes Waldmann wrote: > Bulat Ziganshin wrote: > > (very sound software engineering arguments - > can someone with The Force please copy Bulat's mail > to Haskell/Category/Style ...) > > I agree completely, and just add one remark here : > > > data Encoding = Encoding { encode :: String -> String > > , decode :: String -> String } > > > > utf8 = Encoding encodeUtf8 decodeUtf8 > > this is in fact a method table (Java speak) or a dictionary > (Haskell), and Encoding is the interface (class) - > > except that we can have local instances > by passing around dictionaries explicitly. > > This is similar to passing a Comparator object > to some sorting routine. > > Best regards, Johannes. > > PS: go read any honest OO book on the benefits of interface > oriented design - they know this stuff - they got there > the hard way (that is, via C++ :-) With this approach I would like some facility (e.g. table) to lookup common encodings as the encoding used for a particular datum is not know at compile time in many applications (e.g. it's read from a HTTP Content-Type header or similar.) > lookupEncoding :: String -> Maybe Encoding -- Johan From bulat.ziganshin at gmail.com Thu Jan 31 11:35:40 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Thu Jan 31 11:35:19 2008 Subject: Proposal: Add concatMapM function (#2042) In-Reply-To: <47A1E4D6.9000806@imn.htwk-leipzig.de> References: <478B90A4.4090807@gmail.com> <479F1801.20801@gmail.com> <404396ef0801290418v4755f9f3n1ddd175c3e56d66e@mail.gmail.com> <20080129175243.GA18863@scytale.galois.com> <479F6CBD.3090009@imn.htwk-leipzig.de> <259254796.20080129225150@gmail.com> <47A1ADEE.80407@gmail.com> <90889fe70801310335rffc281fof0cb4e4eddc9c346@mail.gmail.com> <1508723353.20080131161308@gmail.com> <47A1E4D6.9000806@imn.htwk-leipzig.de> Message-ID: <1891544839.20080131193540@gmail.com> Hello Johannes, Thursday, January 31, 2008, 6:10:14 PM, you wrote: > PS: go read any honest OO book on the benefits of interface > oriented design - they know this stuff - they got there > the hard way (that is, via C++ :-) OOP is well known as "stripped FP" paradigm :) when FP just pass all the functions and data required for specialization of generic algorithm, OOP provides interfaces, virtual functions, anonymous classes, delegates and lots of other interesting ways to hide the fact of lack of first-class functions :) look at http://haskell.org/haskellwiki/OOP_vs_type_classes -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From cdsmith at twu.net Thu Jan 31 13:23:18 2008 From: cdsmith at twu.net (Chris Smith) Date: Thu Jan 31 13:22:47 2008 Subject: Proposal: Add concatMapM function (#2042) References: <478B90A4.4090807@gmail.com> <404396ef0801290418v4755f9f3n1ddd175c3e56d66e@mail.gmail.com> <20080129175243.GA18863@scytale.galois.com> <479F6CBD.3090009@imn.htwk-leipzig.de> <259254796.20080129225150@gmail.com> <47A1ADEE.80407@gmail.com> <90889fe70801310335rffc281fof0cb4e4eddc9c346@mail.gmail.com> <1508723353.20080131161308@gmail.com> <47A1E4D6.9000806@imn.htwk-leipzig.de> <90889fe70801310719m28da6064h740f930086453aaa@mail.gmail.com> Message-ID: Johan Tibell wrote: > With this approach I would like some facility (e.g. table) to lookup > common encodings as the encoding used for a particular datum is not know > at compile time in many applications (e.g. it's read from a HTTP > Content-Type header or similar.) > >> lookupEncoding :: String -> Maybe Encoding In fact, there is probably use for several such lookup functions: one for each naming scheme for encodings (and there are several of those, largely overlapping). This lookupEncoding function can be implemented after the fact -- perhaps in a library dedicated to dealing with MIME content -- and it may look something like: lookupEncoding "ISO-8859-1" = Just iso8859_1 lookupEncoding "ISO-8859-2" = Just iso8859_2 ... lookupEncoding _ = Nothing And voila! You've got yourself a way to look up text encodings by name. All this praise of Java makes me nervous, because as a programmer interface, Java is *wrong* about text encodings. Its standard library treats strings, mainly, as the right type for talking about text encodings; and they are not! It keeps one global name-to-encoding mapping, assigns each encoding a canonical "Java name", which is sometimes invented out of thin air. The compiler has no list of encodings that will be available, so it doesn't complain if you hard-code a misspelled encoding name into your program. This stuff is *really* *bad*; it's part of why using Java is a chore rather than a joy. Obviously, I'd like to see Haskell avoid that route. I'm not saying anyone proposed going in that direction; but I got the sense that we may be wandering dangerously close. This is no less fundamental than a question of whether we use language features, or fear them because we fear committment. As Simon mentioned, perhaps there are more things that need to happen to make the language features to make them more compatibility-friendly; but we should make a concerted effort to dive right in and use language features for their intended purpose rather than timidly hang around the outside fringes. -- Chris Smith From wnoise at ofb.net Thu Jan 31 14:15:50 2008 From: wnoise at ofb.net (Aaron Denney) Date: Thu Jan 31 14:15:18 2008 Subject: Proposal: Add concatMapM function (#2042) References: <478B90A4.4090807@gmail.com> <479F1801.20801@gmail.com> <404396ef0801290418v4755f9f3n1ddd175c3e56d66e@mail.gmail.com> <20080129175243.GA18863@scytale.galois.com> <479F6CBD.3090009@imn.htwk-leipzig.de> <259254796.20080129225150@gmail.com> <47A1ADEE.80407@gmail.com> <90889fe70801310335rffc281fof0cb4e4eddc9c346@mail.gmail.com> <1508723353.20080131161308@gmail.com> Message-ID: On 2008-01-31, Bulat Ziganshin wrote: [A bunch of quite sound advice] > in FP language, the best way to provide encoding is to define it as > pair of functions: > > data Encoding = Encoding { encode :: String -> String > , decode :: String -> String } Except these types are lies. > data Encoding = Encoding { encode :: String -> Maybe [Word8] > , decode :: [Word8] -> Maybe String } -- Aaron Denney -><- From bulat.ziganshin at gmail.com Thu Jan 31 13:45:26 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Thu Jan 31 14:18:59 2008 Subject: Proposal: Add concatMapM function (#2042) In-Reply-To: <90889fe70801310719m28da6064h740f930086453aaa@mail.gmail.com> References: <478B90A4.4090807@gmail.com> <404396ef0801290418v4755f9f3n1ddd175c3e56d66e@mail.gmail.com> <20080129175243.GA18863@scytale.galois.com> <479F6CBD.3090009@imn.htwk-leipzig.de> <259254796.20080129225150@gmail.com> <47A1ADEE.80407@gmail.com> <90889fe70801310335rffc281fof0cb4e4eddc9c346@mail.gmail.com> <1508723353.20080131161308@gmail.com> <47A1E4D6.9000806@imn.htwk-leipzig.de> <90889fe70801310719m28da6064h740f930086453aaa@mail.gmail.com> Message-ID: <1445225435.20080131214526@gmail.com> Hello Johan, Thursday, January 31, 2008, 6:19:40 PM, you wrote: >> > data Encoding = Encoding { encode :: String -> String >> > , decode :: String -> String } > With this approach I would like some facility (e.g. table) to lookup > common encodings as the encoding used for a particular datum is not > know at compile time in many applications (e.g. it's read from a HTTP > Content-Type header or similar.) >> lookupEncoding :: String -> Maybe Encoding you may have several libs installed each one providing its own set of encodings, moreover some libs (e.g. iconv-based) may provide this info only at run-time (i.e. in IO monad) so it have meaning to require from authors of encoding libs/modules to provide "dictionaries" of encodings implemented, and combine these dictionaries yourself: myLookup = do iconvEncodings <- IConv.lookupEncoding return (stdEncodings <+> iconvEncodings <+> OtherLib.lookupEncoding) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From johan.tibell at gmail.com Thu Jan 31 14:49:11 2008 From: johan.tibell at gmail.com (Johan Tibell) Date: Thu Jan 31 14:48:39 2008 Subject: Proposal: Add concatMapM function (#2042) In-Reply-To: <1445225435.20080131214526@gmail.com> References: <478B90A4.4090807@gmail.com> <479F6CBD.3090009@imn.htwk-leipzig.de> <259254796.20080129225150@gmail.com> <47A1ADEE.80407@gmail.com> <90889fe70801310335rffc281fof0cb4e4eddc9c346@mail.gmail.com> <1508723353.20080131161308@gmail.com> <47A1E4D6.9000806@imn.htwk-leipzig.de> <90889fe70801310719m28da6064h740f930086453aaa@mail.gmail.com> <1445225435.20080131214526@gmail.com> Message-ID: <90889fe70801311149u3ae5037ej178522ebb9e68277@mail.gmail.com> On Jan 31, 2008 7:45 PM, Bulat Ziganshin wrote: > Hello Johan, > > Thursday, January 31, 2008, 6:19:40 PM, you wrote: > > >> > data Encoding = Encoding { encode :: String -> String > >> > , decode :: String -> String } > > > With this approach I would like some facility (e.g. table) to lookup > > common encodings as the encoding used for a particular datum is not > > know at compile time in many applications (e.g. it's read from a HTTP > > Content-Type header or similar.) > > >> lookupEncoding :: String -> Maybe Encoding > > you may have several libs installed each one providing its own > set of encodings, moreover some libs (e.g. iconv-based) may provide > this info only at run-time (i.e. in IO monad) > > so it have meaning to require from authors of encoding libs/modules to > provide "dictionaries" of encodings implemented, and combine these > dictionaries yourself: > > myLookup = do iconvEncodings <- IConv.lookupEncoding > return (stdEncodings <+> iconvEncodings <+> OtherLib.lookupEncoding) Hi Bulat, Sure. I would also prefer to have a minimal number of encoding provided in a GHC library. From lennart at augustsson.net Thu Jan 31 18:33:06 2008 From: lennart at augustsson.net (Lennart Augustsson) Date: Thu Jan 31 18:32:22 2008 Subject: Proposal: Add variants of tails & inits not returning empty lists In-Reply-To: <20080128204629.GB26352@sliver.repetae.net> References: <20071214161738.GI71713@elvis.mu.org> <1433408180.20071214193442@gmail.com> <20071214195326.GJ71713@elvis.mu.org> <479DBC57.3070809@gmail.com> <20080128204629.GB26352@sliver.repetae.net> Message-ID: I've never needed them. So, no thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20080131/c3e98fab/attachment.htm