From simonmarhaskell at gmail.com Thu Feb 1 04:46:29 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Thu Feb 1 04:41:27 2007 Subject: Proposal: System.Timeout module for base In-Reply-To: <20070130163806.GA15160@localdomain> References: <878xfpv1yd.fsf@write-only.cryp.to> <20070128121623.GB10874@localdomain> <871wlfruk7.fsf@write-only.cryp.to> <20070129222926.GA17786@localdomain> <45BF3823.5080205@gmail.com> <20070130163806.GA15160@localdomain> Message-ID: <45C1B6F5.8080002@gmail.com> Einar Karttunen wrote: > On 30.01 12:20, Simon Marlow wrote: >> How would you interrupt the FFI call when the timeout expired? >> pthread_cancel(), maybe? > > That is one solution. Just letting it running and returning > is "good enough" for most things. One common thing would be > network related functions if implemented in a blocking way (over > various C libraries). They usually do need timeouts and are > blocking FFI calls. I think it would be wrong to leave the FFI call running and still deliver the exception to the thread. Wrong because it leads to surprising behaviour: if the blocked call has a side effect, e.g. a write(), then the side-effect may still heppen, despite the fact that the Haskell thread has been interrupted by the timeout. And wrong because it's not possible to implement it in GHC, at least for bound threads: the OS thread making the foreign call is the only one that can execute the Haskell thread. So that leaves pthread_cancel(). Unfortunately pthread_cancel() isn't really an exception - it can be caught, but the handler is for cleaning up only, it can't continue. So this doesn't let us interrupt FFI calls either. Any other suggestions? My take on this is that if you want to make an interruptible FFI call, you make it in a separate thread, and ensure that if it continues to execute after the parent has received an exception, then this is benign. This is essentially what the IO manager thread in the GHC IO library does: any thread blocked on I/O can be interrupted by a signal, because it is the IO manager thread performing the FFI call. Cheers, Simon From bulat.ziganshin at gmail.com Thu Feb 1 05:49:23 2007 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Thu Feb 1 06:36:26 2007 Subject: Proposal: System.Timeout module for base In-Reply-To: <45C1B6F5.8080002@gmail.com> References: <878xfpv1yd.fsf@write-only.cryp.to> <20070128121623.GB10874@localdomain> <871wlfruk7.fsf@write-only.cryp.to> <20070129222926.GA17786@localdomain> <45BF3823.5080205@gmail.com> <20070130163806.GA15160@localdomain> <45C1B6F5.8080002@gmail.com> Message-ID: <1923347863.20070201134923@gmail.com> Hello Simon, Thursday, February 1, 2007, 12:46:29 PM, you wrote: > Any other suggestions? may be, we can raise exception in foreign language? at least for 'safe' calls. i.e., we establish in RTS signal handler. this handler checks whether we are performing safe call and if so - raise language-specific exception... hmm, if that's possible btw, how about using for *Haskell* code *default* signal handler that raise Haskell exception? i think that using signal handlers to process OS-generated events is just legacy from the C days. i.e. 'main' should be called by RTS inside code like this: mainThread <- myThreadId let onBreak event = do throwTo mainThread BreakException bracket (installHandler$ Catch onBreak) (installHandler) $ \oldHandler -> do main (of course, this handles only ^Break and only on Windows) among other things, this should make signal handling portable between Win/Unix -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From simonmarhaskell at gmail.com Thu Feb 1 08:35:02 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Thu Feb 1 08:29:57 2007 Subject: Proposal: Make StateT in mtl lazy In-Reply-To: <404396ef0701310806s4f55efetcb8f0c4d7670f9b8@mail.gmail.com> References: <20070130165848.GA10003@matrix.chaos.earth.li> <20070131154825.GA30813@matrix.chaos.earth.li> <404396ef0701310806s4f55efetcb8f0c4d7670f9b8@mail.gmail.com> Message-ID: <45C1EC86.60106@gmail.com> Neil Mitchell wrote: > Hi > >> If we're going to have a strict StateT then it would make sense to have >> a strict State too. Control.Monad.State.Strict perhaps? (and likewise >> for the other mtl monads, where appropriate). > > For foldl we have foldl and foldl'. Why not State and State' ? I'm not > a particular fan of changing the imports to get different sets of > behaviours... So if you want (gasp!) strictness you have to pay the Prime Tax :-) I'm not keen on having a bias implied by the naming convention: State' suggests that this is a special/modified version of State, whereas I think both versions are equally useful. Using lazy when you wanted strict can result in a space leak, using strict when you wanted lazy can result in a stack overflow or a time leak. I don't mind so much a bias in the module names: e.g. Control.Monad.State could be the lazy version, Control.Monad.State.Strict the strict version, that's much less intrusive. Cheers, Simon From Malcolm.Wallace at cs.york.ac.uk Thu Feb 1 08:47:54 2007 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Thu Feb 1 08:45:28 2007 Subject: Unsafe aspects of ByteString In-Reply-To: <1231287323.20070131041946@gmail.com> References: <5ab17e790701280958i5fbd4fa8p7568627c9407de6@mail.gmail.com> <20070130030850.GE27625@cse.unsw.EDU.AU> <1231287323.20070131041946@gmail.com> Message-ID: <20070201134754.1f971527.Malcolm.Wallace@cs.york.ac.uk> Bulat Ziganshin wrote: > > The Data.ByteString functions relating to CString have now been > > modified as follows, in the darcs repository. These changes will be > > propogated into base in due course. > > i.e. only in ghc 6.8. i use this chance to remind about our suggestion > to remove ByteString from Base in ghc 6.6.1 and include it as > *separate* library. I'd like to echo this. The Data.ByteString library is wonderful, but its API is still changing fast. It was definitely a mistake to include it in the 'base' package so early. Furthermore, users of ghc cannot even override the 'base' version by adding "-package fps" on the command-line. (Well, you can, but only if your importing module does not use any of the other 'base' package libraries. Is that right?) Regards, Malcolm From haskell at list.mightyreason.com Thu Feb 1 09:00:31 2007 From: haskell at list.mightyreason.com (Chris Kuklewicz) Date: Thu Feb 1 08:55:25 2007 Subject: Proposal: Make StateT in mtl lazy In-Reply-To: <45C1EC86.60106@gmail.com> References: <20070130165848.GA10003@matrix.chaos.earth.li> <20070131154825.GA30813@matrix.chaos.earth.li> <404396ef0701310806s4f55efetcb8f0c4d7670f9b8@mail.gmail.com> <45C1EC86.60106@gmail.com> Message-ID: <45C1F27F.2030403@list.mightyreason.com> Simon Marlow wrote: > Neil Mitchell wrote: >> Hi >> >>> If we're going to have a strict StateT then it would make sense to have >>> a strict State too. Control.Monad.State.Strict perhaps? (and likewise >>> for the other mtl monads, where appropriate). >> >> For foldl we have foldl and foldl'. Why not State and State' ? I'm not >> a particular fan of changing the imports to get different sets of >> behaviours... > > So if you want (gasp!) strictness you have to pay the Prime Tax :-) > > I'm not keen on having a bias implied by the naming convention: State' > suggests that this is a special/modified version of State, whereas I > think both versions are equally useful. Using lazy when you wanted > strict can result in a space leak, using strict when you wanted lazy can > result in a stack overflow or a time leak. > > I don't mind so much a bias in the module names: e.g. > Control.Monad.State could be the lazy version, > Control.Monad.State.Strict the strict version, that's much less intrusive. > > Cheers, > Simon It is foreseeable that complicated Monads mighty have more intermediate levels of Strictness (in the tuple, in the return value, in part of the state ...). The module name space accommodates this better than counting primes on State''', and the "import qualified" syntax makes changing imports transparent to the rest of the file. -- Chris From igloo at earth.li Thu Feb 1 09:24:05 2007 From: igloo at earth.li (Ian Lynagh) Date: Thu Feb 1 09:18:57 2007 Subject: Proposal: Make StateT in mtl lazy In-Reply-To: <20070131154825.GA30813@matrix.chaos.earth.li> References: <20070130165848.GA10003@matrix.chaos.earth.li> <20070131154825.GA30813@matrix.chaos.earth.li> Message-ID: <20070201142405.GA13570@matrix.chaos.earth.li> On Wed, Jan 31, 2007 at 03:48:25PM +0000, Ian Lynagh wrote: > > instance Monad (State s) where > return a = State $ \s -> (a, s) > m >>= k = State $ \s -> case runState m s of > (a, s') -> runState (k a) $! s' > > instance (Monad m) => Monad (StateT s m) where > return a = StateT $ \s -> return (a, s) > m >>= k = StateT $ \s -> do > (a, s') <- runStateT m s > runStateT (k a) $! s' > fail str = StateT $ \_ -> fail str We agreed on IRC that the $!'s solve an orthogonal problem so the strict monads will just have: instance Monad (State s) where return a = State $ \s -> (a, s) m >>= k = State $ \s -> case runState m s of (a, s') -> runState (k a) s' instance (Monad m) => Monad (StateT s m) where return a = StateT $ \s -> return (a, s) m >>= k = StateT $ \s -> do (a, s') <- runStateT m s runStateT (k a) s' fail str = StateT $ \_ -> fail str Thanks Ian From simons at cryp.to Thu Feb 1 13:05:20 2007 From: simons at cryp.to (Peter Simons) Date: Thu Feb 1 13:02:34 2007 Subject: Proposal: System.Timeout module for base References: <878xfpv1yd.fsf@write-only.cryp.to> <20070128121623.GB10874@localdomain> <871wlfruk7.fsf@write-only.cryp.to> <20070129222926.GA17786@localdomain> <45BF3823.5080205@gmail.com> <20070130163806.GA15160@localdomain> <45C1B6F5.8080002@gmail.com> Message-ID: <87tzy5iwin.fsf@write-only.cryp.to> Simon Marlow writes: > Any other suggestions? The fact that blocking FFI threads cannot be timed out with the current implementation is unpleasant, and I would be happy to lift that limitation. I wonder, though, whether depending on unportable low-level OS mechanisms like pthread_cancel() or pthread signals to deliver a timeout might prove to be far more unpleasant than the limitation we try to lift. As far as I'm concerned, the limitation that blocking FFI threads cannot be timed out from Haskell is not that hard. A blocking FFI call, well, blocks. In all honesty, I wouldn't expect that to be any different. I would be far more surprised if it turned out that my currently running C code suddenly receives signals and is supposed to deal with that. My preferred approach would be to agree on the _signature_ of the combinator. We should find consensus that timeout is supposed to look like this: timeout :: Int -> IO a -> IO (Maybe a) If that is the case, then we can add the function into the distribution now and worry about wild improvements of the implementation later. I feel that making even an unperfect solution available to Haskell programmers would be a significant step forward. Maybe this endeavor would be easier to accomplish if we rename the function to unsafeTimeout? ;-) Peter From john at repetae.net Thu Feb 1 17:27:09 2007 From: john at repetae.net (John Meacham) Date: Thu Feb 1 17:27:02 2007 Subject: Unsafe aspects of ByteString In-Reply-To: <5ab17e790701280958i5fbd4fa8p7568627c9407de6@mail.gmail.com> References: <5ab17e790701280958i5fbd4fa8p7568627c9407de6@mail.gmail.com> Message-ID: <20070201222709.GA21072@momenergy.repetae.net> I am not sure this is actually an issue. if you are willing to use 'poke' then _nothing_ preserves referential transparency in Haskell, you can arbitrarily overwrite various parts of the heap. Of course anything that writes to memory directly is unsafe, but 'poke' is the unsafe thing here, not packCString. John -- John Meacham - ?repetae.net?john? From simonmarhaskell at gmail.com Fri Feb 2 04:04:56 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Fri Feb 2 03:59:48 2007 Subject: Proposal: System.Timeout module for base In-Reply-To: <87tzy5iwin.fsf@write-only.cryp.to> References: <878xfpv1yd.fsf@write-only.cryp.to> <20070128121623.GB10874@localdomain> <871wlfruk7.fsf@write-only.cryp.to> <20070129222926.GA17786@localdomain> <45BF3823.5080205@gmail.com> <20070130163806.GA15160@localdomain> <45C1B6F5.8080002@gmail.com> <87tzy5iwin.fsf@write-only.cryp.to> Message-ID: <45C2FEB8.10501@gmail.com> Peter Simons wrote: > Simon Marlow writes: > > > Any other suggestions? > > The fact that blocking FFI threads cannot be timed out with the > current implementation is unpleasant, and I would be happy to > lift that limitation. > > I wonder, though, whether depending on unportable low-level OS > mechanisms like pthread_cancel() or pthread signals to deliver a > timeout might prove to be far more unpleasant than the limitation > we try to lift. As far as I'm concerned, the limitation that > blocking FFI threads cannot be timed out from Haskell is not that > hard. A blocking FFI call, well, blocks. In all honesty, I > wouldn't expect that to be any different. I would be far more > surprised if it turned out that my currently running C code > suddenly receives signals and is supposed to deal with that. Yes, agreed. > My preferred approach would be to agree on the _signature_ of the > combinator. We should find consensus that timeout is supposed to > look like this: > > timeout :: Int -> IO a -> IO (Maybe a) > > If that is the case, then we can add the function into the > distribution now and worry about wild improvements of the > implementation later. I feel that making even an unperfect > solution available to Haskell programmers would be a significant > step forward. I'd go with the proposed signature above. One further suggestion: the docs should mention *how* the timeout is implemented (namely as an asynchronous dynamic exception), which makes it clear that you can take the usual protective measures against mutable data getting into an inconsistent state when the timeout happens: exception handlers, bracket, withMVar, block/unblock etc. Cheers, Simon From alistair at abayley.org Fri Feb 2 06:28:34 2007 From: alistair at abayley.org (Alistair Bayley) Date: Fri Feb 2 06:23:24 2007 Subject: ANN: Takusen 0.6 Message-ID: <79d7c4980702020328l1c415dfeo8cb98dcfc9167231@mail.gmail.com> We are pleased to announce a new release of Takusen. There are a large number of changes and bug-fixes: - Oracle support for processing cursors returned from procedure calls - withContinuedSession supports connection reuse (e.g. for persistent connections and connection pooling) - new README file with useful information about getting started with Takusen - new UTF8 en/de-coder (the old one was buggy) - PostgreSQL support for CalendarTime - improved Cabal Setup.hs script, which does a better job of modifying the installation to reflect installed DBMS's. This gives good ghci support (PostgreSQL users on Windows have a small extra step) - prepared statement API requires that users distinguish between queries and DML Our long-term plans are the same as ever: - large objects - ODBC and MS Sql Server backends Release: http://darcs.haskell.org/takusen/takusen-0.6.tar.gz Source: darcs get --partial http://darcs.haskell.org/takusen Oleg and Alistair From alistair at abayley.org Fri Feb 2 07:01:04 2007 From: alistair at abayley.org (Alistair Bayley) Date: Fri Feb 2 06:55:54 2007 Subject: UTF8 libraries Message-ID: <79d7c4980702020401k5382f10ckc46f6dd57b582936@mail.gmail.com> What is the state of UTF8 support in Haskell libraries (base or user-contributed)? I had a need for a UTF8 en & de-coder for Takusen, and after looking around couldn't find anything particularly satisfactory, so ended up writing (yet another) one. I'm interested mainly in marshalling to/from CStrings, so support for functions like peekUTF8String, newUTF8String, withUTF8String, etc is interesting. I realise that one can use one of the pure decoders after a peekCString, but that means building an intermediate list, which isn't strictly necessary. So far I've found the following: - John Meacham's UTF8 lib: http://repetae.net/repos/jhc/UTF8.hs (only handles codepoints < 65536, pure String <-> [Word8] so no direct CString marshalling) - HXT's Text.XML.HXT.DOM.Unicode: http://www.fh-wedel.de/~si/HXmlToolbox/ (full Unicode range - up to 6 bytes per char, pure String <-> String) - George Russell's: http://www.haskell.org/pipermail/glasgow-haskell-users/2004-April/006564.html (buggy - won't roundtrip chars > 127, pure String <-> String) The one I wrote, which is largely based on John Meacham's and HXT's code, can be seen here: http://darcs.haskell.org/takusen/Foreign/C/UTF8.hs Alistair From shelarcy at gmail.com Fri Feb 2 10:40:14 2007 From: shelarcy at gmail.com (shelarcy) Date: Fri Feb 2 10:35:21 2007 Subject: UTF8 libraries In-Reply-To: <79d7c4980702020401k5382f10ckc46f6dd57b582936@mail.gmail.com> References: <79d7c4980702020401k5382f10ckc46f6dd57b582936@mail.gmail.com> Message-ID: Hi Alistar, On Fri, 02 Feb 2007 21:01:04 +0900, Alistair Bayley wrote: > What is the state of UTF8 support in Haskell libraries (base or > user-contributed)? I had a need for a UTF8 en & de-coder for Takusen, > and after looking around couldn't find anything particularly > satisfactory, so ended up writing (yet another) one. regex-posix doesn't support UTF8. Because regex-posix uses POSIX regex. So this problem can't fixed by only correct UTF8 en & de-coder. If someone is interested in suppourting UTF8, I recommend to use oniguruma. http://www.geocities.jp/kosako3/oniguruma/ Oniguruma also supports UTF-16BE, UTF-16LE, UTF-32BE, UTF-32LE, etc .... And it is portable, it's available both on Unix and Windows. So I think it is best regex C library to choose backend. -- shelarcy http://page.freett.com/shelarcy/ From Alistair_Bayley at invescoperpetual.co.uk Fri Feb 2 10:50:37 2007 From: Alistair_Bayley at invescoperpetual.co.uk (Bayley, Alistair) Date: Fri Feb 2 10:45:27 2007 Subject: UTF8 libraries In-Reply-To: Message-ID: <125EACD0CAE4D24ABDB4D148C4593DA9891B22@GBLONXMB02.corp.amvescap.net> > From: libraries-bounces@haskell.org > > If someone is interested in suppourting UTF8, I recommend to > use oniguruma. > > http://www.geocities.jp/kosako3/oniguruma/ > > Oniguruma also supports UTF-16BE, UTF-16LE, UTF-32BE, UTF-32LE, > etc .... And it is portable, it's available both on Unix and > Windows. > > So I think it is best regex C library to choose backend. Sorry, I didn't explain this so well. I mean an decoder to marshal a C-string that I know is UTF8 into a Haskell String (i.e. [Char]). An FFI call out to C might be convenient, but will have overhead. It's not that hard to write a UTF8 decoder (and encoder) in Haskell; I just wanted to avoid wasted work. 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 ekarttun at cs.helsinki.fi Fri Feb 2 11:14:48 2007 From: ekarttun at cs.helsinki.fi (Musasabi) Date: Fri Feb 2 11:09:57 2007 Subject: Adding binarySize to Binary Message-ID: <20070202161448.GA9458@localdomain> Hello I keep wanting something like: binarySize :: Binary a => Proxy a -> (Int,Maybe Int) in the Data.Binary for returning the minimum and maximum (or Nothing for infinite) space requirements for objects of a given type. Proxy is just defined as "data Proxy t = Proxy", but omitting it is also possible. Would other people consider this an useful addition? - Einar Karttunen From john at repetae.net Fri Feb 2 22:17:21 2007 From: john at repetae.net (John Meacham) Date: Fri Feb 2 22:12:09 2007 Subject: UTF8 libraries In-Reply-To: References: <79d7c4980702020401k5382f10ckc46f6dd57b582936@mail.gmail.com> Message-ID: <20070203031721.GB5785@momenergy.repetae.net> On Sat, Feb 03, 2007 at 12:40:14AM +0900, shelarcy wrote: > Hi Alistar, > > On Fri, 02 Feb 2007 21:01:04 +0900, Alistair Bayley wrote: > > What is the state of UTF8 support in Haskell libraries (base or > > user-contributed)? I had a need for a UTF8 en & de-coder for Takusen, > > and after looking around couldn't find anything particularly > > satisfactory, so ended up writing (yet another) one. > > regex-posix doesn't support UTF8. Because regex-posix uses POSIX > regex. So this problem can't fixed by only correct UTF8 en & de-coder. actually, conforming POSIX regular expressions work in the character encoding of the current locale, which is very likely utf8. In fact, personally, I would consider any system where it is still not utf8 (or perhaps ascii, which is compatable) at this day and age to be broken. (not that they don't exist) John -- John Meacham - ?repetae.net?john? From duncan.coutts at worc.ox.ac.uk Sat Feb 3 08:39:30 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sat Feb 3 08:34:07 2007 Subject: Gtk2Hs 0.9.11 RC2 available for testing Message-ID: <1170509970.29376.146.camel@localhost> The second release candidate for Gtk2Hs 0.9.11 is now available. (The actual version number is 0.9.10.6) The source tarball and windows installer are available: http://haskell.org/gtk2hs/gtk2hs-0.9.10.6.tar.gz (md5sum 8842898cb1f6b595b5a3a057e66a810b) http://haskell.org/gtk2hs/gtk2hs-0.9.10.6.exe (md5sum 97ed838d88ee2d6a01e78d3fea26c18c) and the corresponding documentation: http://haskell.org/gtk2hs/docs/gtk2hs-docs-0.9.10.6/ Changes since 0.9.10: * works with GHC-6.6 and Gtk+ 2.10.x * new typed tree/list widget API * new OpenGL widget added * new cairo SVG package (for rendering SVG images on cairo surfaces) * new implementation of the Graphics.SOE API * new glade tutorial (and hopefully the new intro tutorial will be ready in time too) * many more demo programs (clock, graph, traffic congestion sim, fonts, noughts & crosses, opengl, svg and updated profile viewer and other tree/list demos) * much smaller binaries (thanks to the ghc 'split objs' feature) * many bugs fixed * various minor documentation improvements Changes since the first release candidate: * now works again in GHCi (even in Windows!) * new functions for working with the threaded RTS * new ./configure --enable-profiling flag * new ./configure --with-user-pkgconf flag * Windows version now uses the "MS Windows" theme by default * Windows version now comes with the Gtk+ OpenGL package * Windows version now supports GHCi (6.6 only) and profiling * minor fixes to various demo programs * the svgcairo package now uses librsvg rather than libsvg-cairo Please test this on your platform and report success or failures to the gtk2hs users list (gtk2hs-users@lists.sourceforge.net). So far we've tested on Linux (x86, x86-64, sparc), Windows and Solaris (sparc) with GHC 6.2.2, 6.4.1, 6.4.2, 6.6 and with Gtk+ 2.0 and 2.10. Build reports from people using *BSD, Mac OS X (ppc or x86), GHC 6.0.x or Gtk+ 2.4-2.8 would be particularly appreciated. Windows notes: The installer expects GHC 6.4.2 or 6.6. (As always if you need a build for a different version of GHC then that's possible by building from source.) The GHCi support is only for GHC-6.6 (due to the infamous relocs overflow bug in earlier versions). The installer now comes bundled with Gtk+ itself so there's no need to download it separately. Hopefully this should also make the installation process a bit more reliable if only by reducing the number of configuration combinations. The windows build doesn't include the svgcairo or sourceview packages since they introduce rather a large number of dependencies and would make the installer a much bigger download. Testing issues: I have enabled the 'split-objs' feature by default (for linking the Gtk2Hs libs such that the final binaries are much smaller). If you run into problems during during the build that you think are related to linking then try ./configure --disable-split-objs and report the problem and whether turning off split-objs fixed it. Depending on how it goes we'll decide whether to leave it on by default in the final release or not. For testing, try building, installing and then run: make installcheck This should build all the demo programs that are appropriate for your configuration. Running a selection of them would be good and if you have any other programs that use Gtk2Hs that you can test with, that'd be great. Packaging: For people preparing packages for distributions: note that there are three new packages, "gtkglext", "svgcairo" and "soegtk". For reference there is a Gentoo ebuild available: http://haskell.org/~gentoo/gentoo-haskell/dev-haskell/gtk2hs/ The mozembed package can now be built against firefox, seamonkey, xulrunner or mozilla. Just pass --enable- to ./configure. Duncan (on behalf of the Gtk2Hs team) From dons at cse.unsw.edu.au Sat Feb 3 22:00:57 2007 From: dons at cse.unsw.edu.au (Donald Bruce Stewart) Date: Sat Feb 3 21:55:48 2007 Subject: Adding binarySize to Binary In-Reply-To: <20070202161448.GA9458@localdomain> References: <20070202161448.GA9458@localdomain> Message-ID: <20070204030057.GA17406@cse.unsw.EDU.AU> ekarttun: > Hello > > I keep wanting something like: > > binarySize :: Binary a => Proxy a -> (Int,Maybe Int) > > in the Data.Binary for returning the minimum and maximum (or Nothing > for infinite) space requirements for objects of a given type. > > Proxy is just defined as "data Proxy t = Proxy", but omitting it > is also possible. Would other people consider this an useful > addition? Yes, I've thought this would be useful too. A la 'sizeOf' in Storable. Should it be a member of the Binary class? -- Don From jbapple+haskell-lib at gmail.com Sat Feb 3 23:30:00 2007 From: jbapple+haskell-lib at gmail.com (Jim Apple) Date: Sat Feb 3 23:24:46 2007 Subject: Catamorphisms for arrows? Message-ID: Could Data.Foldable be extended to function types by way of Bananas in Space: Extending Fold and Unfold to Exponential Types [1][2] or Boxes Go Bananas: Encoding Higher-Order Abstract Syntax with Parametric Polymorphism [3][4]? 1. http://citeseer.ist.psu.edu/293490.html 2. http://www.cs.nott.ac.uk/~gmh//bananas.ps 3. http://repository.upenn.edu/cis_reports/43/ 4. http://www.seas.upenn.edu/%7Esweirich/abstracts.html#washburn+:bgb-journal Jim From jbapple+haskell-lib at gmail.com Sat Feb 3 23:36:13 2007 From: jbapple+haskell-lib at gmail.com (Jim Apple) Date: Sat Feb 3 23:30:57 2007 Subject: Paramorphisms / Data.Scanable? Message-ID: I understand that it may not be possible to give simple types to anamorphisms or hylomorphisms, but I don't see there can't be a Data.Scannable with paramorphisms. class Scannable t where scanr :: (a -> b -> b) -> b -> t a -> t b scanl :: (a -> b -> a) -> a -> t b -> t a scanr1 :: (a -> a -> a) -> t a -> t a scanl1 :: (a -> a -> a) -> t a -> t a Jim From ross at soi.city.ac.uk Sun Feb 4 04:11:13 2007 From: ross at soi.city.ac.uk (Ross Paterson) Date: Sun Feb 4 04:05:58 2007 Subject: Paramorphisms / Data.Scanable? In-Reply-To: References: Message-ID: <20070204091113.GA3263@soi.city.ac.uk> On Sat, Feb 03, 2007 at 11:36:13PM -0500, Jim Apple wrote: > I understand that it may not be possible to give simple types to > anamorphisms or hylomorphisms, but I don't see there can't be a > Data.Scannable with paramorphisms. > > class Scannable t where > scanr :: (a -> b -> b) -> b -> t a -> t b > scanl :: (a -> b -> a) -> a -> t b -> t a > scanr1 :: (a -> a -> a) -> t a -> t a > scanl1 :: (a -> a -> a) -> t a -> t a scanr and scanl produce lists one longer than the input, i.e. results of a different shape. Variants more suitable for generalization would be scanr' :: (a -> b -> b) -> b -> t a -> (b, t b) scanl' :: (a -> b -> a) -> a -> t b -> (t a, a) (The other element of the pair being the foldr or foldl respectively.) Then the left-to-right functions could be implemented using Traversable and a state monad. The right-to-left variants could use Traversable with the mirror image applicative functor. I don't think this is the same thing as paramorphisms (primitive recursion), though. From duncan.coutts at worc.ox.ac.uk Sun Feb 4 07:31:21 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Feb 4 07:25:58 2007 Subject: Adding binarySize to Binary In-Reply-To: <20070204030057.GA17406@cse.unsw.EDU.AU> References: <20070202161448.GA9458@localdomain> <20070204030057.GA17406@cse.unsw.EDU.AU> Message-ID: <1170592281.29376.186.camel@localhost> On Sun, 2007-02-04 at 14:00 +1100, Donald Bruce Stewart wrote: > ekarttun: > > Hello > > > > I keep wanting something like: > > > > binarySize :: Binary a => Proxy a -> (Int,Maybe Int) > > > > in the Data.Binary for returning the minimum and maximum (or Nothing > > for infinite) space requirements for objects of a given type. > > > > Proxy is just defined as "data Proxy t = Proxy", but omitting it > > is also possible. Would other people consider this an useful > > addition? > > > Yes, I've thought this would be useful too. A la 'sizeOf' in Storable. > Should it be a member of the Binary class? What would it mean? How hard would it have to work to be accurate? Is this just for (mostly-)fixed size records? What about lists? I don't think we should be forcing the list just to see how big it is. What is the use-case? Duncan From bulat.ziganshin at gmail.com Sun Feb 4 07:41:44 2007 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sun Feb 4 07:38:33 2007 Subject: Paramorphisms / Data.Scanable? In-Reply-To: References: Message-ID: <147540660.20070204154144@gmail.com> Hello Jim, Sunday, February 4, 2007, 7:36:13 AM, you wrote: > class Scannable t where > scanr :: (a -> b -> b) -> b -> t a -> t b > scanl :: (a -> b -> a) -> a -> t b -> t a > scanr1 :: (a -> a -> a) -> t a -> t a > scanl1 :: (a -> a -> a) -> t a -> t a for me it seems that these operations are generalization of fmap and fmap can be implemented via scnal/scanr -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From ekarttun at cs.helsinki.fi Sun Feb 4 09:33:52 2007 From: ekarttun at cs.helsinki.fi (Musasabi) Date: Sun Feb 4 09:28:57 2007 Subject: Adding binarySize to Binary In-Reply-To: <1170592281.29376.186.camel@localhost> References: <20070202161448.GA9458@localdomain> <20070204030057.GA17406@cse.unsw.EDU.AU> <1170592281.29376.186.camel@localhost> Message-ID: <20070204143351.GA7185@localdomain> On 04.02 12:31, Duncan Coutts wrote: > Dons wrote: > > Yes, I've thought this would be useful too. A la 'sizeOf' in Storable. > > Should it be a member of the Binary class? Yes, as there is no other good way of implementing it in general. > What would it mean? How hard would it have to work to be accurate? Is > this just for (mostly-)fixed size records? What about lists? I don't > think we should be forcing the list just to see how big it is. As it would operate on types rather than values (think sizeOf), the result for "[a]" would probably be "(1, Nothing)" - a list takes one byte at minimum and infinite bytes at maximum. > What is the use-case? I am playing with on disk B-tree like things and object sizes become quite important when deciding layout. Several optimizations can be done if the objects are known to be fixed size (or have only small size variations). And if it is known beforehand how many objects will fit into a page that helps too. - Musasabi From dons at cse.unsw.edu.au Sun Feb 4 18:07:52 2007 From: dons at cse.unsw.edu.au (Donald Bruce Stewart) Date: Sun Feb 4 18:02:37 2007 Subject: [hoelz@wisc.edu: [Haskell] Haskell Xlib bindings] Message-ID: <20070204230752.GA30998@cse.unsw.EDU.AU> This question is best asked on the libraries@haskell.org list, so I'll forward it there. Failing that, best to contact the maintainer of the xlib package. Cheers, Don ----- Forwarded message from Rob Hoelz ----- Date: Sun, 04 Feb 2007 16:00:44 -0600 From: Rob Hoelz To: haskell@haskell.org Subject: [Haskell] Haskell Xlib bindings Hello everyone, This question probably belongs in GUI, but I tried posting there a week ago and have yet to get a response. My question is this: Why do the Haskell Xlib bindings have no way to extract the property event from an event pointer? For example, the following functions are available: get_KeyEvent, get_ButtonEvent, get_MotionEvent, etc. but there's no get_PropertyEvent. Why was this left out? It seems pretty critical to the functionality of an Xlib program to someone who's been programming in C with Xlib for quite some time. Thanks, Robert Hoelz _______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell ----- End forwarded message ----- From ross at soi.city.ac.uk Sun Feb 4 18:24:52 2007 From: ross at soi.city.ac.uk (Ross Paterson) Date: Sun Feb 4 18:19:36 2007 Subject: Haskell Xlib bindings In-Reply-To: <20070204230752.GA30998@cse.unsw.EDU.AU> References: <20070204230752.GA30998@cse.unsw.EDU.AU> Message-ID: <20070204232452.GA26932@soi.city.ac.uk> Rob Hoelz wrote: > My question is this: Why do the Haskell Xlib bindings have no way to > extract the property event from an event pointer? > > For example, the following functions are available: > > get_KeyEvent, get_ButtonEvent, get_MotionEvent, etc. > > but there's no get_PropertyEvent. > > Why was this left out? It seems pretty critical to the functionality > of an Xlib program to someone who's been programming in C with Xlib for > quite some time. It wasn't left out, it just wasn't put in, like a lot of other things. If you have a list of stuff you need, it can be added. From hoelz at wisc.edu Sun Feb 4 18:42:38 2007 From: hoelz at wisc.edu (Rob Hoelz) Date: Sun Feb 4 18:37:34 2007 Subject: Haskell Xlib bindings In-Reply-To: <20070204232452.GA26932@soi.city.ac.uk> References: <20070204230752.GA30998@cse.unsw.EDU.AU> <20070204232452.GA26932@soi.city.ac.uk> Message-ID: <20070204174238.27c8f1b9@localhost.localdomain> Ross Paterson wrote: > Rob Hoelz wrote: > > My question is this: Why do the Haskell Xlib bindings have no way > > to extract the property event from an event pointer? > > > > For example, the following functions are available: > > > > get_KeyEvent, get_ButtonEvent, get_MotionEvent, etc. > > > > but there's no get_PropertyEvent. > > > > Why was this left out? It seems pretty critical to the > > functionality of an Xlib program to someone who's been programming > > in C with Xlib for quite some time. > > It wasn't left out, it just wasn't put in, like a lot of other things. > If you have a list of stuff you need, it can be added. > Actually, I wouldn't mind doing it myself. Are the Haskell libs compiler-specific, or central? Either way, is there a CVS/subversion/git repository I can check out from? From dons at cse.unsw.edu.au Sun Feb 4 18:49:34 2007 From: dons at cse.unsw.edu.au (Donald Bruce Stewart) Date: Sun Feb 4 18:44:18 2007 Subject: Haskell Xlib bindings In-Reply-To: <20070204174238.27c8f1b9@localhost.localdomain> References: <20070204230752.GA30998@cse.unsw.EDU.AU> <20070204232452.GA26932@soi.city.ac.uk> <20070204174238.27c8f1b9@localhost.localdomain> Message-ID: <20070204234934.GE30998@cse.unsw.EDU.AU> hoelz: > Ross Paterson wrote: > > > Rob Hoelz wrote: > > > My question is this: Why do the Haskell Xlib bindings have no way > > > to extract the property event from an event pointer? > > > > > > For example, the following functions are available: > > > > > > get_KeyEvent, get_ButtonEvent, get_MotionEvent, etc. > > > > > > but there's no get_PropertyEvent. > > > > > > Why was this left out? It seems pretty critical to the > > > functionality of an Xlib program to someone who's been programming > > > in C with Xlib for quite some time. > > > > It wasn't left out, it just wasn't put in, like a lot of other things. > > If you have a list of stuff you need, it can be added. > > > > Actually, I wouldn't mind doing it myself. Are the Haskell libs > compiler-specific, or central? Either way, is there a > CVS/subversion/git repository I can check out from? Great! You can get most Haskell software via darcs repositories, (http://darcs.net) , and X11 is no exception: $ darcs get http://darcs.haskell.org/packages/X11 Copying patch 17 of 99... General information for developing Haskell libraries is available here: http://haskell.org/haskellwiki/How_to_write_a_Haskell_program and covers the toolchain and best practices. Cheers, Don From jeremy.shaw at linspireinc.com Sun Feb 4 18:52:36 2007 From: jeremy.shaw at linspireinc.com (Jeremy Shaw) Date: Sun Feb 4 18:47:21 2007 Subject: Haskell Xlib bindings In-Reply-To: <20070204232452.GA26932@soi.city.ac.uk> References: <20070204230752.GA30998@cse.unsw.EDU.AU> <20070204232452.GA26932@soi.city.ac.uk> Message-ID: Hello, I have some code that adds support for ClientMessage, peekXButtonEvent, and XGetAtomName: http://www.n-heptane.com/nhlab/repos/haskell-glx/ClientMessage.hsc This code is in reasonably good shape (and is only a few lines anyway). I can follow the library submission guidelines: http://haskell.org/haskellwiki/Library_submissions unless there is a better way. j. From ross at soi.city.ac.uk Sun Feb 4 19:02:18 2007 From: ross at soi.city.ac.uk (Ross Paterson) Date: Sun Feb 4 18:57:01 2007 Subject: Haskell Xlib bindings In-Reply-To: References: <20070204230752.GA30998@cse.unsw.EDU.AU> <20070204232452.GA26932@soi.city.ac.uk> Message-ID: <20070205000218.GB26932@soi.city.ac.uk> On Sun, Feb 04, 2007 at 03:52:36PM -0800, Jeremy Shaw wrote: > I have some code that adds support for ClientMessage, > peekXButtonEvent, and XGetAtomName: > > http://www.n-heptane.com/nhlab/repos/haskell-glx/ClientMessage.hsc > > This code is in reasonably good shape (and is only a few lines anyway). > > I can follow the library submission guidelines: > > http://haskell.org/haskellwiki/Library_submissions > > unless there is a better way. X11 is a fairly peripheral library, so there's no need for that -- just send a patch against the X11 darcs repository, e.g. to me. From igloo at earth.li Sun Feb 4 19:13:27 2007 From: igloo at earth.li (Ian Lynagh) Date: Sun Feb 4 19:08:08 2007 Subject: Proposal: Make StateT in mtl lazy In-Reply-To: <20070131154825.GA30813@matrix.chaos.earth.li> References: <20070130165848.GA10003@matrix.chaos.earth.li> <20070131154825.GA30813@matrix.chaos.earth.li> Message-ID: <20070205001327.GA26250@matrix.chaos.earth.li> On Wed, Jan 31, 2007 at 03:48:25PM +0000, Ian Lynagh wrote: > > Control.Monad.State.Class -- for the MonadState class > Control.Monad.State.Lazy > Control.Monad.State.Strict > Control.Monad.State -- re-exports .Class and .Lazy Now done. Here's the patch description: [Rejig mtl; trac proposal #1127 Ian Lynagh **20070205000253 Moved the MonadFoo classes to Control.Monad.Foo.Class. Put the instances consistently in the module which defines the type they give an instance for. Made the existing transformers lazy to match the existing monads, and put them in Control.Monad.Foo.Lazy. Also added Control.Monad.Foo.Strict with strict monads and transformers. Control.Monad.Foo still exports what it used to. Created a MonadRWS class. Made the MonadWriter w (ErrorT e m) instance strict to match everything else. ] Thanks Ian From droundy at darcs.net Mon Feb 5 12:50:20 2007 From: droundy at darcs.net (David Roundy) Date: Mon Feb 5 12:45:01 2007 Subject: Adding binarySize to Binary In-Reply-To: <20070204143351.GA7185@localdomain> References: <20070202161448.GA9458@localdomain> <20070204030057.GA17406@cse.unsw.EDU.AU> <1170592281.29376.186.camel@localhost> <20070204143351.GA7185@localdomain> Message-ID: <20070205175018.GE21652@abridgegame.org> On Sun, Feb 04, 2007 at 04:33:52PM +0200, Musasabi wrote: > On 04.02 12:31, Duncan Coutts wrote: > > Dons wrote: > > > Yes, I've thought this would be useful too. A la 'sizeOf' in Storable. > > > Should it be a member of the Binary class? > > Yes, as there is no other good way of implementing it in general. And I presume the class would define a default function returning (1,Nothing), or maybe returning (0,Nothing), since some data types will take no space. So it'd only put a burden on instance-declarers who want to help out optimizing users of their data type. -- David Roundy Department of Physics Oregon State University From ndmitchell at gmail.com Mon Feb 5 13:37:38 2007 From: ndmitchell at gmail.com (Neil Mitchell) Date: Mon Feb 5 13:32:18 2007 Subject: Adding binarySize to Binary In-Reply-To: <20070204143351.GA7185@localdomain> References: <20070202161448.GA9458@localdomain> <20070204030057.GA17406@cse.unsw.EDU.AU> <1170592281.29376.186.camel@localhost> <20070204143351.GA7185@localdomain> Message-ID: <404396ef0702051037m5d5d0245h22fef96e869d0826@mail.gmail.com> Hi > As it would operate on types rather than values (think sizeOf), the > result for "[a]" would probably be "(1, Nothing)" - a list takes one > byte at minimum and infinite bytes at maximum. That interface seems horrible - it looks like it will only be useful to a small number of people, and not be general at all. I really don't like the idea of an interface specifying a "fuzz factor" (which is what upper/lower bounds correspond to) In my BinaryDefer library I have a class BinaryDeferStatic: class BinaryDefer a => BinaryDeferStatic a where -- | Must be a constant, must not examine first argument getSize :: Proxy a -> Int This is for things which have a fixed and static size based on their type. I could also see a reason for having a sizeOf method in the Binary class - where if unimplemented it just calls encode and then B.length. Anything else just seems to be an ugly API... Thanks Neil From droundy at darcs.net Mon Feb 5 14:37:35 2007 From: droundy at darcs.net (David Roundy) Date: Mon Feb 5 14:32:15 2007 Subject: Adding binarySize to Binary In-Reply-To: <404396ef0702051037m5d5d0245h22fef96e869d0826@mail.gmail.com> References: <20070202161448.GA9458@localdomain> <20070204030057.GA17406@cse.unsw.EDU.AU> <1170592281.29376.186.camel@localhost> <20070204143351.GA7185@localdomain> <404396ef0702051037m5d5d0245h22fef96e869d0826@mail.gmail.com> Message-ID: <20070205193732.GF21652@abridgegame.org> On Mon, Feb 05, 2007 at 06:37:38PM +0000, Neil Mitchell wrote: > Hi > > >As it would operate on types rather than values (think sizeOf), the > >result for "[a]" would probably be "(1, Nothing)" - a list takes one > >byte at minimum and infinite bytes at maximum. > > That interface seems horrible - it looks like it will only be useful > to a small number of people, and not be general at all. I really don't > like the idea of an interface specifying a "fuzz factor" (which is > what upper/lower bounds correspond to) But often a fuzz factor is helpful, and it's always well-defined. One would often like to allocate padded structures so you can either modify them in-place or have O(1) access to the elements, and you need a max size for that. The min size would be helpful for knowing when it's worth padding. It'd be heuristic, but if the max size is 1000 times larger than the min size, you might not want to always allocate the maximum. > In my BinaryDefer library I have a class BinaryDeferStatic: > > class BinaryDefer a => BinaryDeferStatic a where > -- | Must be a constant, must not examine first argument > getSize :: Proxy a -> Int > > This is for things which have a fixed and static size based on their type. Except that the class-based approach is no good for a function (or data type) which is intended to work with any data, even that which doesn't have a static size. > I could also see a reason for having a sizeOf method in the Binary > class - where if unimplemented it just calls encode and then B.length. Except that sizeOf as you describe it would operate on values rather than on types, and as such would be useless for any of the uses of binarySize. > Anything else just seems to be an ugly API... I agree about the ugliness of binarySize as implemented (returning a tuple). Why not something like: class Binary a where ... maxSize :: Proxy a -> Maybe Int maxSize _ = Nothing minSize :: Proxy a -> Int minSize _ = 0 staticSize :: Proxy a -> Maybe Int staticSize p | maxSize p == Just (minSize p) = maxSize p staticSize _ = Nothing Thus one can do nice things like make an array class that operates on any Binary data, but can do nice tricks to optimize access times. e.g. one might want to allocate N*maxSize space, so you can have O(1) writes (in a mutable array, or on disk). -- David Roundy Department of Physics Oregon State University From alistair at abayley.org Tue Feb 6 04:00:17 2007 From: alistair at abayley.org (Alistair Bayley) Date: Tue Feb 6 03:54:56 2007 Subject: Compiling module using Data.Time with -O fails; can't find HsTime.h Message-ID: <79d7c4980702060100s56079703mc990134a2898bb4@mail.gmail.com> If I try to compile this Main.hs: module Main where import Data.Time main = getCurrentTime >>= print with this ghc-6.6 command: ghc --make Main -o test -O ... I get this error: C:\DOCUME~1\bayleya\LOCALS~1\Temp\ghc728_0\ghc728_0.hc:8:20: HsTime.h: No such file or directory Is this me doing something I shouldn't, or is there something wrong with the way the library has been distributed? Alistair From jeanphilippe.bernardy at gmail.com Tue Feb 6 08:54:21 2007 From: jeanphilippe.bernardy at gmail.com (Jean-Philippe Bernardy) Date: Tue Feb 6 08:49:00 2007 Subject: swap minView/maxView return value. Message-ID: <953e0d250702060554o757ee142n74ba111aa3a7799c@mail.gmail.com> Some time ago (before ghc 6.6 / base 2.0 release), I introduced minView and maxView in Data.Set and Data.Map (at a user's request). I agreed with Robert Dockins to implement the same functionality as in his version of the Edison library. Unfortunately, I uselessly swapped the return values of minView and maxView, introducing a difference both with the corresponding functions in the edison library and similar functions in Data.Map/Set. I propose to restore the symmetry, at the cost of incompatibility. The incompatibility is probably acceptable because the functions are still short-lived. See the trac ticket for details. http://hackage.haskell.org/trac/ghc/ticket/1134 I provide no patch nor QuickCheck properties because of the triviality of the change. Cheers, JP. From maeder at tzi.de Tue Feb 6 09:37:22 2007 From: maeder at tzi.de (Christian Maeder) Date: Tue Feb 6 09:32:12 2007 Subject: swap minView/maxView return value. In-Reply-To: <953e0d250702060554o757ee142n74ba111aa3a7799c@mail.gmail.com> References: <953e0d250702060554o757ee142n74ba111aa3a7799c@mail.gmail.com> Message-ID: <45C892A2.8060602@tzi.de> Jean-Philippe Bernardy schrieb: > I propose to restore the symmetry, at the cost of incompatibility. > The incompatibility is probably acceptable because the functions are > still short-lived. > > See the trac ticket for details. > http://hackage.haskell.org/trac/ghc/ticket/1134 The milestone should even be 6.6.1 and the current result-pair-order considered to be bug in 6.6 in order to allow an interface change between minor versions and keep the incompatibility really as short-lived as possible. Cheers Christian From igloo at earth.li Tue Feb 6 10:12:25 2007 From: igloo at earth.li (Ian Lynagh) Date: Tue Feb 6 10:07:03 2007 Subject: Compiling module using Data.Time with -O fails; can't find HsTime.h In-Reply-To: <79d7c4980702060100s56079703mc990134a2898bb4@mail.gmail.com> References: <79d7c4980702060100s56079703mc990134a2898bb4@mail.gmail.com> Message-ID: <20070206151225.GA18707@matrix.chaos.earth.li> Hi Alistair, On Tue, Feb 06, 2007 at 09:00:17AM +0000, Alistair Bayley wrote: > > C:\DOCUME~1\bayleya\LOCALS~1\Temp\ghc728_0\ghc728_0.hc:8:20: HsTime.h: > No such file or directory > > Is this me doing something I shouldn't, No, this should work. > or is there something wrong > with the way the library has been distributed? I can reproduce this with my installation by the Windows installer, but not the Debian packages which build time as a standalone cabal package. I've made a ticket for it: http://hackage.haskell.org/trac/ghc/ticket/1135 Thanks Ian From maeder at tzi.de Wed Feb 7 04:06:48 2007 From: maeder at tzi.de (Christian Maeder) Date: Wed Feb 7 04:01:22 2007 Subject: [Fwd: Re: [GHC] #1134: swap minView/maxView return value] Message-ID: <45C996A8.9090302@tzi.de> It should be allowed to fix a buggy interface (before the bug becomes a feature) Christian -------- Original-Nachricht -------- Betreff: Re: [GHC] #1134: swap minView/maxView return value Datum: Tue, 06 Feb 2007 23:59:25 -0000 Von: GHC Antwort an: glasgow-haskell-bugs@haskell.org An: glasgow-haskell-bugs@haskell.org Newsgruppen: gmane.comp.lang.haskell.glasgow.bugs Referenzen: <071.1d16a01fab839e0adc11599f4864434e@localhost> #1134: swap minView/maxView return value ----------------------------+----------------------------------------------- Reporter: jpbernardy | Owner: jpbernardy Type: proposal | Status: new Priority: normal | Milestone: 6.8 Component: libraries/base | Version: 6.6 Severity: normal | Resolution: Keywords: collections | Difficulty: Easy (1 hr) Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Changes (by igloo): * milestone: 6.6.1 => 6.8 * type: bug => proposal Comment: Unfortunately fixing this for 6.6.1 would mean changing the interface, which we don't allow within a stable branch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ekarttun at cs.helsinki.fi Wed Feb 7 06:25:23 2007 From: ekarttun at cs.helsinki.fi (Musasabi) Date: Wed Feb 7 06:20:23 2007 Subject: Proposal: Data.Proxy Message-ID: <20070207112523.GA29759@localdomain> Hello I propose a module called Data.Proxy into the base package containing the common Proxy type used in many different libraries (e.g. HAppS, HList, ...). Attached is the source code. - Einar Karttunen -------------- next part -------------- A non-text attachment was scrubbed... Name: Proxy.hs Type: text/x-haskell Size: 558 bytes Desc: not available Url : http://www.haskell.org/pipermail/libraries/attachments/20070207/6e7afa6e/Proxy.bin From ndmitchell at gmail.com Wed Feb 7 07:08:25 2007 From: ndmitchell at gmail.com (Neil Mitchell) Date: Wed Feb 7 07:03:00 2007 Subject: Proposal: Data.Proxy In-Reply-To: <20070207112523.GA29759@localdomain> References: <20070207112523.GA29759@localdomain> Message-ID: <404396ef0702070408i4da17f46y457e3ce257202c2d@mail.gmail.com> Hi > I propose a module called Data.Proxy into the base package containing the common > Proxy type used in many different libraries (e.g. HAppS, HList, ...). > > Attached is the source code. Great idea! A few questions: Proxy is very simple, so why not export it as Proxy(..) - the implementation of the data type is essential to how it works. We don't hide things like Maybe's internals. It's not an abstract data type, its a concrete one (in my mind). If you do this, then proxy is redundant, we have Proxy on its own. I would rather something like proxyOf than toProxy - this fits in slightly better with asTypeOf in the Prelude. Thanks Neil From sven.panne at aedion.de Wed Feb 7 09:17:30 2007 From: sven.panne at aedion.de (Sven Panne) Date: Wed Feb 7 09:12:02 2007 Subject: [Haskell] Haskell Xlib bindings In-Reply-To: <1170630957.10634.13.camel@localhost> References: <20070204160044.7c87f8d8@localhost.localdomain> <1170630957.10634.13.camel@localhost> Message-ID: <200702071517.31127.sven.panne@aedion.de> [ moved to libraries list ] Am Montag, 5. Februar 2007 00:15 schrieb Duncan Coutts: > [...] Perhaps these days binding xcb might be the way to go for low level > X11 stuff. I had a look and XCB, and it looks quite promising as a "better Xlib". What is not so clear to me is: * X.Org seems to use it as a basis for their Xlib implementation. Is this correct? * What about XFree86? * What about X11 implementations on *BSD, Solaris, AIX, HP-UX, etc.? * Is XCB 100% feature-complete compared to Xlib? I guess that XCB is not widespread enough yet to drop the X11 package now, but I'd like to hear what others think. OTOH, a Haskell binding for XCB can probably be generated automatically to a large degree via XSLT, if I understand things correctly, which would be a big plus. Cheers, S. From moonlite at dtek.chalmers.se Wed Feb 7 10:48:09 2007 From: moonlite at dtek.chalmers.se (Mattias Bengtsson) Date: Wed Feb 7 10:42:42 2007 Subject: [Haskell] Haskell Xlib bindings In-Reply-To: <200702071517.31127.sven.panne@aedion.de> References: <20070204160044.7c87f8d8@localhost.localdomain> <1170630957.10634.13.camel@localhost> <200702071517.31127.sven.panne@aedion.de> Message-ID: <1170863289.5003.4.camel@localhost.localdomain> On Wed, 2007-02-07 at 15:17 +0100, Sven Panne wrote: [snip] > * What about XFree86? Is XFree86 even used anymore? > * What about X11 implementations on *BSD, Solaris, AIX, HP-UX, etc.? At least BSD (the ones i know of) and Solaris x86 uses xorg as default i think. > * Is XCB 100% feature-complete compared to Xlib? > > I guess that XCB is not widespread enough yet to drop the X11 package now, but > I'd like to hear what others think. OTOH, a Haskell binding for XCB can > probably be generated automatically to a large degree via XSLT, if I > understand things correctly, which would be a big plus. > This might be of interest: http://lists.freedesktop.org/archives/xcb/2006-January/001278.html Mattias From benjamin.franksen at bessy.de Wed Feb 7 14:51:21 2007 From: benjamin.franksen at bessy.de (Benjamin Franksen) Date: Wed Feb 7 14:46:16 2007 Subject: [Haskell] Haskell Xlib bindings References: <20070204160044.7c87f8d8@localhost.localdomain> <1170630957.10634.13.camel@localhost> <200702071517.31127.sven.panne@aedion.de> Message-ID: Sven Panne wrote: > [ moved to libraries list ] > > Am Montag, 5. Februar 2007 00:15 schrieb Duncan Coutts: >> [...] Perhaps these days binding xcb might be the way to go for low level >> X11 stuff. > > * Is XCB 100% feature-complete compared to Xlib? AFAIU, XCB is intentionally missing a number of 'high level' features of XLib (I specifically remember server state caching and i18n). Most of these features are usually not depended on by modern toolkits. XCB implements the full protocol (which already makes for a daunting amount of data types and routines). On top of that it implements a very lean connection management and request handling API that allows (this is one of the highlights) single-threaded as well as multi-threaded access. See the very readable paper http://www.linuxshowcase.org/2001/full_papers/massey/massey.pdf Cheers Ben From duncan.coutts at worc.ox.ac.uk Wed Feb 7 17:47:59 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Feb 7 17:42:20 2007 Subject: [Haskell] Haskell Xlib bindings In-Reply-To: <200702071517.31127.sven.panne@aedion.de> References: <20070204160044.7c87f8d8@localhost.localdomain> <1170630957.10634.13.camel@localhost> <200702071517.31127.sven.panne@aedion.de> Message-ID: <1170888479.10634.64.camel@localhost> On Wed, 2007-02-07 at 15:17 +0100, Sven Panne wrote: > [ moved to libraries list ] > > Am Montag, 5. Februar 2007 00:15 schrieb Duncan Coutts: > > [...] Perhaps these days binding xcb might be the way to go for low level > > X11 stuff. > > I had a look and XCB, and it looks quite promising as a "better Xlib". What is > not so clear to me is: > > * X.Org seems to use it as a basis for their Xlib implementation. Is this > correct? Yes. The X.org Xlib uses XCB underneath. Part of the reason for that is so that apps can start to migrate to XCB while still using some Xlib functions. > * What about XFree86? > > * What about X11 implementations on *BSD, Solaris, AIX, HP-UX, etc.? > > * Is XCB 100% feature-complete compared to Xlib? No and that's rather the point. Xlib contains lots of stuff that very few apps use. XCB is more minimal. > I guess that XCB is not widespread enough yet to drop the X11 package now, but > I'd like to hear what others think. OTOH, a Haskell binding for XCB can > probably be generated automatically to a large degree via XSLT, if I > understand things correctly, which would be a big plus. How about putting the Xlib binding into maintenance mode and moving the focus to XCB bindings. Duncan From ashley at semantic.org Wed Feb 7 21:45:01 2007 From: ashley at semantic.org (Ashley Yakeley) Date: Wed Feb 7 21:39:51 2007 Subject: Proposal: Data.Proxy In-Reply-To: <20070207112523.GA29759@localdomain> References: <20070207112523.GA29759@localdomain> Message-ID: Musasabi wrote: > data Proxy a = Proxy I do this, only I call it "Type". Anyway, ignoring that bikeshed, it can be considered the "universal type-witness". Consider a typical type-witness: data MyType a where MyBool :: MyType Bool MyInt :: MyType Int You can use type-witnesses like this to construct a type-witness for heterogenous lists: data ListType w a where Nil :: ListType w () Cons :: w a -> ListType w b -> ListType w (a,b) So now "ListType MyType" is a witness for heterogenous lists containing only Ints and Bools. But if you want a list that can contain any type, then "ListType Type" (your "ListType Proxy") will do the trick. If you prefer classes for passing witnesses around, that's easy: class Is w a where witness :: w a instance Is (ListType w) () where witness = Nil instance (Is w a,Is (ListType w) b) => Is (ListType w) (a,b) where witness = Cons witness witness instance Is MyType Bool where witness = MyBool instance Is MyType Int where witness = MyInt You can use your list type like this: addInts :: (Is (ListType MyType) list) => list -> Int addInts = addInts' witness where addInts' :: ListType MyType list -> list -> Int addInts' Nil _ = 0 addInts' (Cons (MyType Int) wl) (i:ms) = i + addInts' wl ms addInts' (Cons _ wl) (_:ms) = addInts' wl ms addInts (True,(3,(False,(4,())))) ==> 7 From flippa at flippac.org Wed Feb 7 21:47:52 2007 From: flippa at flippac.org (Philippa Cowderoy) Date: Wed Feb 7 21:44:24 2007 Subject: Proposal: Data.Proxy In-Reply-To: <20070207112523.GA29759@localdomain> References: <20070207112523.GA29759@localdomain> Message-ID: On Wed, 7 Feb 2007, Musasabi wrote: > Hello > > I propose a module called Data.Proxy into the base package containing > the common Proxy type used in many different libraries (e.g. HAppS, > HList, ...). > Perhaps Type.Proxy, creating a Type hierarchy for types with trivial values intended for type-level programming? -- flippa@flippac.org "My religion says so" explains your beliefs. But it doesn't explain why I should hold them as well, let alone be restricted by them. From stefanor at cox.net Wed Feb 7 22:00:00 2007 From: stefanor at cox.net (Stefan O'Rear) Date: Wed Feb 7 21:54:33 2007 Subject: Proposal: Data.Proxy In-Reply-To: References: <20070207112523.GA29759@localdomain> Message-ID: <20070208030000.GA3498@localhost.localdomain> On Thu, Feb 08, 2007 at 02:47:52AM +0000, Philippa Cowderoy wrote: > On Wed, 7 Feb 2007, Musasabi wrote: > > > Hello > > > > I propose a module called Data.Proxy into the base package containing > > the common Proxy type used in many different libraries (e.g. HAppS, > > HList, ...). > > > > Perhaps Type.Proxy, creating a Type hierarchy for types with trivial > values intended for type-level programming? I second this proposal. Also, due to the increasing popularity of witness types, I propose a optimization/pragmatic hint (warning, only 5 mins thought, please improve): {-# NO_PATTERN_MATCHING #-} does exactly what it says, and hints to the code generator that it can use 0 bytes to represent the value by some variation of the State# magic. From ndmitchell at gmail.com Thu Feb 8 05:49:46 2007 From: ndmitchell at gmail.com (Neil Mitchell) Date: Thu Feb 8 05:44:16 2007 Subject: Proposal: Data.Proxy In-Reply-To: <20070208030000.GA3498@localhost.localdomain> References: <20070207112523.GA29759@localdomain> <20070208030000.GA3498@localhost.localdomain> Message-ID: <404396ef0702080249j676c0a2fg5aa383f28471dbeb@mail.gmail.com> Hi > Also, due to the increasing popularity of witness types, I propose a > optimization/pragmatic hint (warning, only 5 mins thought, please improve): > > {-# NO_PATTERN_MATCHING #-} > > does exactly what it says, and hints to the code generator that it > can use 0 bytes to represent the value by some variation of the State# magic. That pragma changes the semantics of the data type from being populated by _|_ and Proxy, to being populated by nothing. Pragma's should try not to change the semantics. Wouldn't a definition such as: data Proxy a Achieve the same effect? (Of course, we are still writing the Haskell 98 libraries, so we should just use normal data for now) Thanks Neil From ross at soi.city.ac.uk Thu Feb 8 05:53:05 2007 From: ross at soi.city.ac.uk (Ross Paterson) Date: Thu Feb 8 05:47:41 2007 Subject: Proposal: Data.Proxy In-Reply-To: <404396ef0702080249j676c0a2fg5aa383f28471dbeb@mail.gmail.com> References: <20070207112523.GA29759@localdomain> <20070208030000.GA3498@localhost.localdomain> <404396ef0702080249j676c0a2fg5aa383f28471dbeb@mail.gmail.com> Message-ID: <20070208105305.GA11781@soi.city.ac.uk> On Thu, Feb 08, 2007 at 10:49:46AM +0000, Neil Mitchell wrote: > Wouldn't a definition such as: > > data Proxy a > > Achieve the same effect? In Haskell 98, newtype Proxy a = Proxy (Proxy a) or data Proxy a = Proxy !(Proxy a) yield one-point types. From gale at sefer.org Thu Feb 8 13:49:39 2007 From: gale at sefer.org (Yitzchak Gale) Date: Thu Feb 8 13:44:10 2007 Subject: Proposal: Make StateT in mtl lazy Message-ID: <2608b8a80702081049h6d38bca7l7ff673daff22e2b6@mail.gmail.com> Ian Lynagh wrote: > > Control.Monad.State.Class -- for the MonadState class > > Control.Monad.State.Lazy > > Control.Monad.State.Strict > > Control.Monad.State -- re-exports .Class and .Lazy > > Now done. Wonderful news! Thanks! -Yitz From john at repetae.net Thu Feb 8 18:44:08 2007 From: john at repetae.net (John Meacham) Date: Thu Feb 8 18:38:39 2007 Subject: Proposal: Data.Proxy In-Reply-To: <20070207112523.GA29759@localdomain> References: <20070207112523.GA29759@localdomain> Message-ID: <20070208234408.GC24298@momenergy.repetae.net> Wasn't something like this recently proposed, I believe we decided on calling it Void. perhaps we could put this in the same module, since it serves a similar purpose (but takes a type argument) John -- John Meacham - ?repetae.net?john? From ekarttun at cs.helsinki.fi Fri Feb 9 03:48:21 2007 From: ekarttun at cs.helsinki.fi (Musasabi) Date: Fri Feb 9 03:43:18 2007 Subject: Proposal: Data.Proxy In-Reply-To: <20070208105305.GA11781@soi.city.ac.uk> References: <20070207112523.GA29759@localdomain> <20070208030000.GA3498@localhost.localdomain> <404396ef0702080249j676c0a2fg5aa383f28471dbeb@mail.gmail.com> <20070208105305.GA11781@soi.city.ac.uk> Message-ID: <20070209084820.GA10972@localdomain> On 08.02 10:53, Ross Paterson wrote: > On Thu, Feb 08, 2007 at 10:49:46AM +0000, Neil Mitchell wrote: > > Wouldn't a definition such as: > > > > data Proxy a > > > > Achieve the same effect? > > In Haskell 98, > > newtype Proxy a = Proxy (Proxy a) > or > data Proxy a = Proxy !(Proxy a) > > yield one-point types. I think these definitions make sense. One more reason not to export the constructor so the actual implementation will be hidden. I don't have a strong opinion to Type.Proxy vs Data.Proxy, but creating a new hierarchy would probably need more consensus. - Einar Karttunen From droundy at darcs.net Fri Feb 9 11:42:26 2007 From: droundy at darcs.net (David Roundy) Date: Fri Feb 9 11:37:01 2007 Subject: Proposal: Data.Proxy In-Reply-To: <20070209084820.GA10972@localdomain> References: <20070207112523.GA29759@localdomain> <20070208030000.GA3498@localhost.localdomain> <404396ef0702080249j676c0a2fg5aa383f28471dbeb@mail.gmail.com> <20070208105305.GA11781@soi.city.ac.uk> <20070209084820.GA10972@localdomain> Message-ID: <20070209164224.GC3793@abridgegame.org> > I don't have a strong opinion to Type.Proxy vs Data.Proxy, but > creating a new hierarchy would probably need more consensus. I'd lean towards Data.Proxy, as this is an instantiable type. There may only be one value for (Proxy Int) but I can create that value and pass it to a fuction, which to me makes it data. Plus your point about a new hierarchy is a good one. -- David Roundy Department of Physics Oregon State University From sven.panne at aedion.de Sat Feb 10 07:09:49 2007 From: sven.panne at aedion.de (Sven Panne) Date: Sat Feb 10 07:04:10 2007 Subject: [Haskell] Haskell Xlib bindings In-Reply-To: <1170888479.10634.64.camel@localhost> References: <20070204160044.7c87f8d8@localhost.localdomain> <200702071517.31127.sven.panne@aedion.de> <1170888479.10634.64.camel@localhost> Message-ID: <200702101309.50021.sven.panne@aedion.de> Am Mittwoch, 7. Februar 2007 23:47 schrieb Duncan Coutts: > On Wed, 2007-02-07 at 15:17 +0100, Sven Panne wrote: > > [...] > > * What about X11 implementations on *BSD, Solaris, AIX, HP-UX, etc.? > [...] > How about putting the Xlib binding into maintenance mode and moving the > focus to XCB bindings. I think this makes sense, at least if the OSes mentioned above will support XCB in the long run, too. Or do they already have support right now? It would be good to know that... Cheers, S. From duncan.coutts at worc.ox.ac.uk Sat Feb 10 07:30:18 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sat Feb 10 07:21:30 2007 Subject: [Haskell] Haskell Xlib bindings In-Reply-To: <200702101309.50021.sven.panne@aedion.de> References: <20070204160044.7c87f8d8@localhost.localdomain> <200702071517.31127.sven.panne@aedion.de> <1170888479.10634.64.camel@localhost> <200702101309.50021.sven.panne@aedion.de> Message-ID: <1171110618.23819.60.camel@localhost> On Sat, 2007-02-10 at 13:09 +0100, Sven Panne wrote: > Am Mittwoch, 7. Februar 2007 23:47 schrieb Duncan Coutts: > > On Wed, 2007-02-07 at 15:17 +0100, Sven Panne wrote: > > > [...] > > > * What about X11 implementations on *BSD, Solaris, AIX, HP-UX, etc.? > > [...] > > How about putting the Xlib binding into maintenance mode and moving the > > focus to XCB bindings. > > I think this makes sense, at least if the OSes mentioned above will support > XCB in the long run, too. Or do they already have support right now? It would > be good to know that... Certainly Linux and Solaris use X.org. I can't remember if one or two of the BSDs still use XFree86 but the rest have moved to X.org. I have no idea about AIX or HP-UX. Duncan From sven.panne at aedion.de Sat Feb 10 12:04:32 2007 From: sven.panne at aedion.de (Sven Panne) Date: Sat Feb 10 11:58:52 2007 Subject: [Haskell] Haskell Xlib bindings In-Reply-To: References: <20070204160044.7c87f8d8@localhost.localdomain> <200702071517.31127.sven.panne@aedion.de> Message-ID: <200702101804.32638.sven.panne@aedion.de> Am Mittwoch, 7. Februar 2007 20:51 schrieb Benjamin Franksen: > [...] > XCB implements the full protocol (which already makes for a daunting amount > of data types and routines). On top of that it implements a very lean > connection management and request handling API that allows (this is one of > the highlights) single-threaded as well as multi-threaded access. Hmmm, the presentation in the paper is the other way round: The lower layer is the XCB_Connection layer, handling connections, requests and replies. On top of that, the XCB_Protocol layer implements, well, the protocol, including (un-)marshaling to/from C. > See the very readable paper > http://www.linuxshowcase.org/2001/full_papers/massey/massey.pdf After reading that paper and browsing around a bit, I think a slightly bolder approach might make sense for Haskell, in effect creating XHB ("X Protocol Haskell Binding"): I guess that the bulk of the code is in the XCB_Protocol layer, and that layer is already generated via an XML description for the C binding. If we can use the same technique to generate Haskell code, "only" a Haskell version of the connection layer would be needed to get a full XHB. This would have a few advantages: * There is no dependency on the XCB library, so XHB should work on *any* platform, including e.g. MinGW without any X11 libs. An X11 server is of course still needed... :-) * Data is only (un-)marshaled once. Using XCB, there would be 2 steps: Haskell <=> C <=> X protocol * The availability of protocol extensions is determined by XHB alone, not by any underlying XCB implementation. I am not sure if this is a realistic way to go, especially I am unsure about the amount of work needed to implement the functionality of the XCB_Connection layer directly in Haskell. Let's see if I can find a more or less stand-alone version of XCB (with no need to build all of X.Org) and understand how it is actually implemented. Any opinions? Hints? Cheers, S. From judah.jacobson at gmail.com Sun Feb 11 19:09:32 2007 From: judah.jacobson at gmail.com (Judah Jacobson) Date: Sun Feb 11 19:03:50 2007 Subject: Proposal: add extra readline completion functionality Message-ID: <6d74b0d20702111609x7308a9a3jfcdcebba09addbb8@mail.gmail.com> I propose adding some functionality to the readline package (really just wrappers of variables from that library) which is necessary to fix ghci bug #998. See the proposed patch at http://hackage.haskell.org/trac/ghc/ticket/1141 as well as the bug report at http://hackage.haskell.org/trac/ghc/ticket/998 The main addition is rl_completion_word_break_hook, which lets us change the set of word break characters based on the context of the line. Specifically for ghci, this is needed to change whether "/" is a word boundary (depending on whether we're expanding a Haskell name or a filename). Note that this variable is only present in readline version 5.0 or later; I've put in some ifdef's to support compiling against older versions. I've also included get/set functions for the rl_attempted_completion_over variable. If it's set to nonzero, readline won't use its default completer when our custom completer returns no results. Thanks, -Judah From benjamin.franksen at bessy.de Mon Feb 12 12:28:25 2007 From: benjamin.franksen at bessy.de (Benjamin Franksen) Date: Mon Feb 12 12:23:02 2007 Subject: [Haskell] Haskell Xlib bindings References: <20070204160044.7c87f8d8@localhost.localdomain> <200702071517.31127.sven.panne@aedion.de> <1170888479.10634.64.camel@localhost> <200702101309.50021.sven.panne@aedion.de> <1171110618.23819.60.camel@localhost> Message-ID: Duncan Coutts wrote: > On Sat, 2007-02-10 at 13:09 +0100, Sven Panne wrote: >> Am Mittwoch, 7. Februar 2007 23:47 schrieb Duncan Coutts: >> > On Wed, 2007-02-07 at 15:17 +0100, Sven Panne wrote: >> > > [...] >> > > * What about X11 implementations on *BSD, Solaris, AIX, HP-UX, >> > > etc.? >> > [...] >> > How about putting the Xlib binding into maintenance mode and moving the >> > focus to XCB bindings. >> >> I think this makes sense, at least if the OSes mentioned above will >> support XCB in the long run, too. Or do they already have support right >> now? It would be good to know that... > > Certainly Linux and Solaris use X.org. I can't remember if one or two of > the BSDs still use XFree86 but the rest have moved to X.org. I have no > idea about AIX or HP-UX. HP-UX is dying fast. Anyway, a direct implementation of an X client library (an 'XHB', as Sven suggested, generated from XCB's language independent protocol description) would make these questions irrelevant. Ben From benjamin.franksen at bessy.de Mon Feb 12 12:34:39 2007 From: benjamin.franksen at bessy.de (Benjamin Franksen) Date: Mon Feb 12 12:29:28 2007 Subject: [Haskell] Haskell Xlib bindings References: <20070204160044.7c87f8d8@localhost.localdomain> <200702071517.31127.sven.panne@aedion.de> <200702101804.32638.sven.panne@aedion.de> Message-ID: Sven Panne wrote: > Am Mittwoch, 7. Februar 2007 20:51 schrieb Benjamin Franksen: >> [...] >> XCB implements the full protocol (which already makes for a daunting >> amount of data types and routines). On top of that it implements a very >> lean connection management and request handling API that allows (this is >> one of the highlights) single-threaded as well as multi-threaded access. > > Hmmm, the presentation in the paper is the other way round: The lower > layer is the XCB_Connection layer, handling connections, requests and > replies. On top of that, the XCB_Protocol layer implements, well, the > protocol, including (un-)marshaling to/from C. You're right, sorry for the confusion. >> See the very readable paper >> http://www.linuxshowcase.org/2001/full_papers/massey/massey.pdf > > After reading that paper and browsing around a bit, I think a slightly > bolder approach might make sense for Haskell, in effect creating XHB ("X > Protocol Haskell Binding"): I guess that the bulk of the code is in the > XCB_Protocol layer, and that layer is already generated via an XML > description for the C binding. If we can use the same technique to > generate Haskell code, "only" a Haskell version of the connection layer > would be needed to get a full XHB. This would have a few advantages: > > * There is no dependency on the XCB library, so XHB should work on > *any* > platform, including e.g. MinGW without any X11 libs. An X11 server is of > course still needed... :-) > > * Data is only (un-)marshaled once. Using XCB, there would be 2 steps: > Haskell <=> C <=> X protocol > > * The availability of protocol extensions is determined by XHB alone, > not > by any underlying XCB implementation. I agree that this would be nice. (Disclaimer: I haven't the slightest clue about XSLT and how it is used to generate code from XML protocol descriptions. However, I assume this won't be that much harder than to find some method to 'auto-ffi' the huge XCB_Protocol API into Haskell.) Have you seen this: lists.freedesktop.org/archives/xcb/2006-January/001278.html ? The sources are here http://webcvs.freedesktop.org/xcb/xhsb/ It could be starting point, at least... > I am not sure if this is a realistic way to go, especially I am unsure > about the amount of work needed to implement the functionality of the > XCB_Connection layer directly in Haskell. Yes, this is going to be the most difficult part. I have taken a look at another XCB paper, which is about the XCB_Connection layer and explains how the problem has been modeled using the Z specification language (freedesktop.org/software/xcb/usenix-zxcb.pdf). Very interesting, this. I wonder if one could derive a Haskell solution (more or less) directly from the Z spec. Or, maybe, even simplify the spec, leveraging Haskell's more high-level interface to multithreading (STM?). > Let's see if I can find a more > or less stand-alone version of XCB (with no need to build all of X.Org) > and understand how it is actually implemented. Sources can be downloaded from the XCB site (a handful of tar.gz files). Build and install was rather uncomplicated here (debian/etch, amd64). Unfortunately, freedesktop.org seems to be down at the moment, so none of the above links will work until they are online again. Ben From sven.panne at aedion.de Mon Feb 12 14:07:19 2007 From: sven.panne at aedion.de (Sven Panne) Date: Mon Feb 12 14:01:36 2007 Subject: [Haskell] Haskell Xlib bindings In-Reply-To: References: <20070204160044.7c87f8d8@localhost.localdomain> <200702101804.32638.sven.panne@aedion.de> Message-ID: <200702122007.19415.sven.panne@aedion.de> On Monday 12 February 2007 18:34, Benjamin Franksen wrote: > I agree that this would be nice. (Disclaimer: I haven't the slightest clue > about XSLT and how it is used to generate code from XML protocol > descriptions. However, I assume this won't be that much harder than to find > some method to 'auto-ffi' the huge XCB_Protocol API into Haskell.) The XSLT code to generate the C binding (c-client.xsl) is about 56kB. :-P Depending on the build system, personal preferences etc. it might make more sense to use Haskell code to transform the XML protocol description. > Have you seen this: > > lists.freedesktop.org/archives/xcb/2006-January/001278.html ? The sources > are here http://webcvs.freedesktop.org/xcb/xhsb/ It could be starting > point, at least... The code needs some tweaks to make it compile and work with my local XCB library. Anyway, this is only a tiny hand-written demo, not a starting point for a project. > Yes, this is going to be the most difficult part. I have taken a look at > another XCB paper, which is about the XCB_Connection layer and explains how > the problem has been modeled using the Z specification language > (freedesktop.org/software/xcb/usenix-zxcb.pdf). Very interesting, this. I > wonder if one could derive a Haskell solution (more or less) directly from > the Z spec. Or, maybe, even simplify the spec, leveraging Haskell's more > high-level interface to multithreading (STM?). Ignoring Z for the moment, I've started to hack the connection layer for XHB, which seems to be feasible. Two problems: * XCB depends on a handful XauFOO routines for authentication. It is not clear to me yet if we should do so in Haskell, too, or if we should re-implement that in Haskell, too. So for first tests no authentication will be offered. Welcome "xhost +"! ;-) * Haskell's standard networking libraries are really, really awful: No IPv6 support, no getaddrinfo & friends, slightly obscure combination of features, one has to be careful about the byte order etc. etc. This has been mentioned several times already, but I don't know if there is currently anybody working actively on this. :-( Using formal methods somehow would be nice, but there are more fundamental things waiting to be solved, as it seems... > Sources can be downloaded from the XCB site (a handful of tar.gz files). > Build and install was rather uncomplicated here (debian/etch, amd64). > Unfortunately, freedesktop.org seems to be down at the moment, so none of > the above links will work until they are online again. Using version control system no. x in my life (where x > 10 :-P * * *) to download the latest stuff, I've been able to build XCB locally. This is very straightforward after one has figured out the minimum amount of code to download. Cheers, S. From benjamin.franksen at bessy.de Mon Feb 12 16:49:37 2007 From: benjamin.franksen at bessy.de (Benjamin Franksen) Date: Mon Feb 12 16:44:50 2007 Subject: [Haskell] Haskell Xlib bindings References: <20070204160044.7c87f8d8@localhost.localdomain> <200702101804.32638.sven.panne@aedion.de> <200702122007.19415.sven.panne@aedion.de> Message-ID: Sven Panne wrote: > On Monday 12 February 2007 18:34, Benjamin Franksen wrote: >> I agree that this would be nice. (Disclaimer: I haven't the slightest >> clue about XSLT and how it is used to generate code from XML protocol >> descriptions. However, I assume this won't be that much harder than to >> find some method to 'auto-ffi' the huge XCB_Protocol API into Haskell.) > > The XSLT code to generate the C binding (c-client.xsl) is about 56kB. :-P > Depending on the build system, personal preferences etc. it might make > more sense to use Haskell code to transform the XML protocol description. Yup. I didn't look at teh XSLT code before, but I have now: it looks awefully baroque. The /must/ be a simpler way, or at least a less verbose one. >> Have you seen this: >> >> lists.freedesktop.org/archives/xcb/2006-January/001278.html ? The sources >> are here http://webcvs.freedesktop.org/xcb/xhsb/ It could be starting >> point, at least... > > The code needs some tweaks to make it compile and work with my local XCB > library. Anyway, this is only a tiny hand-written demo, not a starting > point for a project. Ok; I haven't looked at it very closely. >> Yes, this is going to be the most difficult part. I have taken a look at >> another XCB paper, which is about the XCB_Connection layer and explains >> how the problem has been modeled using the Z specification language >> (freedesktop.org/software/xcb/usenix-zxcb.pdf). Very interesting, this. I >> wonder if one could derive a Haskell solution (more or less) directly >> from the Z spec. Or, maybe, even simplify the spec, leveraging Haskell's >> more high-level interface to multithreading (STM?). > > Ignoring Z for the moment, I've started to hack the connection layer for > XHB, which seems to be feasible. Two problems: > > * XCB depends on a handful XauFOO routines for authentication. It is > not > clear to me yet if we should do so in Haskell, too, or if we should > re-implement that in Haskell, too. So for first tests no authentication > will be offered. Welcome "xhost +"! ;-) I agree that this can be postponed. > * Haskell's standard networking libraries are really, really awful: No > IPv6 > support, no getaddrinfo & friends, slightly obscure combination of > features, > one has to be careful about the byte order etc. etc. This has been > mentioned several times already, but I don't know if there is currently > anybody working actively on this. :-( > > Using formal methods somehow would be nice, but there are more fundamental > things waiting to be solved, as it seems... >From what I read in the ZXCB paper, the specification of the connection layer is somewhat tricky to implement correctly, at least when based on the semantics of Posix threads (and with the stated requirement for an API that can be used equally well for single and multi threaded clients). It could well be that an implementation in Haskell would have less problems with this aspect, and more with insufficient library support. Disclaimer: I haven't done any serious network programming in Haskell yet, so I'll have to take your word on this. And before I forget it, another one: I find this (potential) project very fascinating, but I doubt my Haskell programming abilities are good enough to contribute significant amounts of code to it. Cheers Ben From jeanphilippe.bernardy at gmail.com Tue Feb 13 07:51:53 2007 From: jeanphilippe.bernardy at gmail.com (Jean-Philippe Bernardy) Date: Tue Feb 13 07:46:11 2007 Subject: swap minView/maxView return value. In-Reply-To: <953e0d250702060554o757ee142n74ba111aa3a7799c@mail.gmail.com> References: <953e0d250702060554o757ee142n74ba111aa3a7799c@mail.gmail.com> Message-ID: <953e0d250702130451w6e3397eauf37074e35bc5770f@mail.gmail.com> I've attached a (obvious) patch to the ticket. I propose to apply it the 19th. Cheers, JP. On 2/6/07, Jean-Philippe Bernardy wrote: > Some time ago (before ghc 6.6 / base 2.0 release), I introduced > minView and maxView in Data.Set and Data.Map (at a user's request). I > agreed with Robert Dockins to implement the same functionality as in > his version of the Edison library. Unfortunately, I uselessly swapped > the return values of minView and maxView, introducing a difference > both with the corresponding functions in the edison library and > similar functions in Data.Map/Set. > > I propose to restore the symmetry, at the cost of incompatibility. > The incompatibility is probably acceptable because the functions are > still short-lived. > > See the trac ticket for details. > http://hackage.haskell.org/trac/ghc/ticket/1134 > > I provide no patch nor QuickCheck properties because of the triviality > of the change. > > Cheers, > JP. > From simonmarhaskell at gmail.com Tue Feb 13 08:15:35 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Tue Feb 13 08:09:53 2007 Subject: [Haskell] Haskell Xlib bindings In-Reply-To: <200702101804.32638.sven.panne@aedion.de> References: <20070204160044.7c87f8d8@localhost.localdomain> <200702071517.31127.sven.panne@aedion.de> <200702101804.32638.sven.panne@aedion.de> Message-ID: <45D1B9F7.7080208@gmail.com> Sven Panne wrote: > Am Mittwoch, 7. Februar 2007 20:51 schrieb Benjamin Franksen: >> [...] >> XCB implements the full protocol (which already makes for a daunting amount >> of data types and routines). On top of that it implements a very lean >> connection management and request handling API that allows (this is one of >> the highlights) single-threaded as well as multi-threaded access. > > Hmmm, the presentation in the paper is the other way round: The lower layer is > the XCB_Connection layer, handling connections, requests and replies. On top > of that, the XCB_Protocol layer implements, well, the protocol, including > (un-)marshaling to/from C. > >> See the very readable paper >> http://www.linuxshowcase.org/2001/full_papers/massey/massey.pdf > > After reading that paper and browsing around a bit, I think a slightly bolder > approach might make sense for Haskell, in effect creating XHB ("X Protocol > Haskell Binding"): I guess that the bulk of the code is in the XCB_Protocol > layer, and that layer is already generated via an XML description for the C > binding. If we can use the same technique to generate Haskell code, "only" a > Haskell version of the connection layer would be needed to get a full XHB. > This would have a few advantages: > > * There is no dependency on the XCB library, so XHB should work on *any* > platform, including e.g. MinGW without any X11 libs. An X11 server is of > course still needed... :-) > > * Data is only (un-)marshaled once. Using XCB, there would be 2 steps: > Haskell <=> C <=> X protocol > > * The availability of protocol extensions is determined by XHB alone, not > by any underlying XCB implementation. > > I am not sure if this is a realistic way to go, especially I am unsure about > the amount of work needed to implement the functionality of the > XCB_Connection layer directly in Haskell. Let's see if I can find a more or > less stand-alone version of XCB (with no need to build all of X.Org) and > understand how it is actually implemented. This all seems reasonable if the goal is to provide an XCB layer in Haskell. But I have to ask the question: why? The only user of the X11 lib is HGL, and that's been ported to GtkHs now (ISTR), so who are the clients for an XCB layer? This isn't intended to be inflamatory, I'm genuinely curious - it's certainly an interesting exercise, if nothing else. Cheers, Simon From sven.panne at aedion.de Tue Feb 13 11:20:29 2007 From: sven.panne at aedion.de (Sven Panne) Date: Tue Feb 13 11:14:43 2007 Subject: [Haskell] Haskell Xlib bindings In-Reply-To: <45D1B9F7.7080208@gmail.com> References: <20070204160044.7c87f8d8@localhost.localdomain> <200702101804.32638.sven.panne@aedion.de> <45D1B9F7.7080208@gmail.com> Message-ID: <200702131720.30082.sven.panne@aedion.de> On Tuesday 13 February 2007 14:15, Simon Marlow wrote: > This all seems reasonable if the goal is to provide an XCB layer in > Haskell. But I have to ask the question: why? The only user of the X11 lib > is HGL, and that's been ported to GtkHs now (ISTR), so who are the clients > for an XCB layer? [...] The conclusion of the above reasoning would be "rm -rf libraries/X11", but I wouldn't go that far... ;-) And similar arguments could be made for Win32. Anyway, I think there are a few reasons why something like XHB could make sense: * Fewer dependencies (no Xlib needed) * Automatic generation of almost all parts, leading to a very consistent API * Availability of dozens of protocol extensions for X11 for free, the X11 package has only the bare bones X11 * The possibility to use XHB in a multi-threaded setting (Xlib has only very arcane support for this, so everything is basically single-threaded) * Although Xlib will definitely stay with us for a long, long time, it seems to be a bit "deprecated". * The current X11 package needs a serious code review to fix the types. Apart from that, there are a few personal interests: * Improve my rusty XSLT skills * Test the available XML tools in/for Haskell * Get some ideas for a better networking package. BTW: What is the status of this? Is anybody already working on this? The current package has no clean layering, lacks most modern networking features, does a few things "behind the back" (which is often not what one wants), etc. Although I do not have enough time to push this actively, I would be very interested in joining such a "Let's build a better network package" task force... Cheers, S. From simonmarhaskell at gmail.com Tue Feb 13 12:08:11 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Tue Feb 13 12:02:29 2007 Subject: [Haskell] Haskell Xlib bindings In-Reply-To: <200702131720.30082.sven.panne@aedion.de> References: <20070204160044.7c87f8d8@localhost.localdomain> <200702101804.32638.sven.panne@aedion.de> <45D1B9F7.7080208@gmail.com> <200702131720.30082.sven.panne@aedion.de> Message-ID: <45D1F07B.3000707@gmail.com> Sven Panne wrote: > On Tuesday 13 February 2007 14:15, Simon Marlow wrote: >> This all seems reasonable if the goal is to provide an XCB layer in >> Haskell. But I have to ask the question: why? The only user of the X11 lib >> is HGL, and that's been ported to GtkHs now (ISTR), so who are the clients >> for an XCB layer? [...] > > The conclusion of the above reasoning would be "rm -rf libraries/X11", but I > wouldn't go that far... ;-) And similar arguments could be made for Win32. > Anyway, I think there are a few reasons why something like XHB could make > sense: > > * Fewer dependencies (no Xlib needed) > > * Automatic generation of almost all parts, leading to a very consistent > API > > * Availability of dozens of protocol extensions for X11 for free, the X11 > package has only the bare bones X11 > > * The possibility to use XHB in a multi-threaded setting (Xlib has only > very arcane support for this, so everything is basically single-threaded) > > * Although Xlib will definitely stay with us for a long, long time, it > seems to be a bit "deprecated". > > * The current X11 package needs a serious code review to fix the types. I think you misinterpreted me slightly: I didn't mean to ask "why XCB when we have an Xlib binding?", I'm asking "why do we need either?". Who is going to use it? Is someone planning to write a widget set in Haskell? Win32 is different: it is a layer used by the vast majority of Windows apps, because it encompasses not just the GUI but also the core OS services. X11, in contrast, is used by hardly any apps. I couldn't find anything in HackageDB that depends on it, apart from HGL. > Apart from that, there are a few personal interests: > > * Improve my rusty XSLT skills > > * Test the available XML tools in/for Haskell > > * Get some ideas for a better networking package. BTW: What is the status > of this? Is anybody already working on this? The current package has no clean > layering, lacks most modern networking features, does a few things "behind > the back" (which is often not what one wants), etc. Although I do not have > enough time to push this actively, I would be very interested in joining such > a "Let's build a better network package" task force... Definitely with you there. Revamping network would be tremendously useful. Cheers, Simon From hoelz at wisc.edu Tue Feb 13 14:24:00 2007 From: hoelz at wisc.edu (Rob Hoelz) Date: Tue Feb 13 14:18:25 2007 Subject: [Haskell] Haskell Xlib bindings In-Reply-To: <45D1F07B.3000707@gmail.com> References: <20070204160044.7c87f8d8@localhost.localdomain> <200702101804.32638.sven.panne@aedion.de> <45D1B9F7.7080208@gmail.com> <200702131720.30082.sven.panne@aedion.de> <45D1F07B.3000707@gmail.com> Message-ID: <20070213132400.7999dbba@TheRing> Simon Marlow wrote: > Sven Panne wrote: > > On Tuesday 13 February 2007 14:15, Simon Marlow wrote: > >> This all seems reasonable if the goal is to provide an XCB layer in > >> Haskell. But I have to ask the question: why? The only user of > >> the X11 lib is HGL, and that's been ported to GtkHs now (ISTR), so > >> who are the clients for an XCB layer? [...] > > > > The conclusion of the above reasoning would be "rm -rf > > libraries/X11", but I wouldn't go that far... ;-) And similar > > arguments could be made for Win32. Anyway, I think there are a few > > reasons why something like XHB could make sense: > > > > * Fewer dependencies (no Xlib needed) > > > > * Automatic generation of almost all parts, leading to a very > > consistent API > > > > * Availability of dozens of protocol extensions for X11 for > > free, the X11 package has only the bare bones X11 > > > > * The possibility to use XHB in a multi-threaded setting (Xlib > > has only very arcane support for this, so everything is basically > > single-threaded) > > > > * Although Xlib will definitely stay with us for a long, long > > time, it seems to be a bit "deprecated". > > > > * The current X11 package needs a serious code review to fix the > > types. > > I think you misinterpreted me slightly: I didn't mean to ask "why XCB > when we have an Xlib binding?", I'm asking "why do we need either?". > Who is going to use it? Is someone planning to write a widget set in > Haskell? > I think having an Xlib module is important; there's low-level stuff you might need to do in Xlib that isn't practical to do using GTK/Qt. Or you might want to build a light-weight application. Etc, etc. > Win32 is different: it is a layer used by the vast majority of > Windows apps, because it encompasses not just the GUI but also the > core OS services. X11, in contrast, is used by hardly any apps. I > couldn't find anything in HackageDB that depends on it, apart from > HGL. > > > Apart from that, there are a few personal interests: > > > > * Improve my rusty XSLT skills > > > > * Test the available XML tools in/for Haskell > > > > * Get some ideas for a better networking package. BTW: What is > > the status of this? Is anybody already working on this? The current > > package has no clean layering, lacks most modern networking > > features, does a few things "behind the back" (which is often not > > what one wants), etc. Although I do not have enough time to push > > this actively, I would be very interested in joining such a "Let's > > build a better network package" task force... > > Definitely with you there. Revamping network would be tremendously > useful. > > Cheers, > Simon > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries -- -Rob Hoelz From kolmodin at dtek.chalmers.se Tue Feb 13 14:30:16 2007 From: kolmodin at dtek.chalmers.se (Lennart Kolmodin) Date: Tue Feb 13 14:24:31 2007 Subject: [Haskell] Haskell Xlib bindings In-Reply-To: <20070213132400.7999dbba@TheRing> References: <20070204160044.7c87f8d8@localhost.localdomain> <200702101804.32638.sven.panne@aedion.de> <45D1B9F7.7080208@gmail.com> <200702131720.30082.sven.panne@aedion.de> <45D1F07B.3000707@gmail.com> <20070213132400.7999dbba@TheRing> Message-ID: <45D211C8.7090001@dtek.chalmers.se> Rob Hoelz wrote: > Simon Marlow wrote: >> I think you misinterpreted me slightly: I didn't mean to ask "why XCB >> when we have an Xlib binding?", I'm asking "why do we need either?". >> Who is going to use it? Is someone planning to write a widget set in >> Haskell? >> > > I think having an Xlib module is important; there's low-level stuff you > might need to do in Xlib that isn't practical to do using GTK/Qt. Or > you might want to build a light-weight application. Etc, etc. > Or, rather, you want to write a window manager. This is already work in progress by sjanssen. Cheers, Lennart Kolmodin From hoelz at wisc.edu Tue Feb 13 17:46:50 2007 From: hoelz at wisc.edu (Rob Hoelz) Date: Tue Feb 13 17:41:09 2007 Subject: Compiling Haskell X11 bindings Message-ID: <20070213164650.735e1a20@TheRing> Hello everyone, I've been trying to improve the Haskell X11 bindings so they're more usable. So I tried to compile with my changes, and here's the output: rob@TheRing ~/programming/src/darcs/X11 $ runhaskell Setup.hs configure configure: creating ./config.status config.status: creating config.mk config.status: creating X11.buildinfo config.status: error: cannot find input file: include/HsX11Config.h.in How can I remedy this? I'm looking forward to seeing my changes in action! Thanks, Rob Hoelz From simonmarhaskell at gmail.com Wed Feb 14 05:00:07 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Wed Feb 14 04:54:28 2007 Subject: [Haskell] Haskell Xlib bindings In-Reply-To: <45D211C8.7090001@dtek.chalmers.se> References: <20070204160044.7c87f8d8@localhost.localdomain> <200702101804.32638.sven.panne@aedion.de> <45D1B9F7.7080208@gmail.com> <200702131720.30082.sven.panne@aedion.de> <45D1F07B.3000707@gmail.com> <20070213132400.7999dbba@TheRing> <45D211C8.7090001@dtek.chalmers.se> Message-ID: <45D2DDA7.1010206@gmail.com> Lennart Kolmodin wrote: > Rob Hoelz wrote: >> Simon Marlow wrote: >>> I think you misinterpreted me slightly: I didn't mean to ask "why XCB >>> when we have an Xlib binding?", I'm asking "why do we need either?". >>> Who is going to use it? Is someone planning to write a widget set in >>> Haskell? >>> >> >> I think having an Xlib module is important; there's low-level stuff you >> might need to do in Xlib that isn't practical to do using GTK/Qt. Or >> you might want to build a light-weight application. Etc, etc. >> > > Or, rather, you want to write a window manager. This is already work in > progress by sjanssen. Those answer my question, thanks! SImon From ross at soi.city.ac.uk Wed Feb 14 05:46:59 2007 From: ross at soi.city.ac.uk (Ross Paterson) Date: Wed Feb 14 05:41:13 2007 Subject: Compiling Haskell X11 bindings In-Reply-To: <20070213164650.735e1a20@TheRing> References: <20070213164650.735e1a20@TheRing> Message-ID: <20070214104659.GB3351@soi.city.ac.uk> On Tue, Feb 13, 2007 at 04:46:50PM -0600, Rob Hoelz wrote: > I've been trying to improve the Haskell X11 bindings so they're more > usable. So I tried to compile with my changes, and here's the output: > > rob@TheRing ~/programming/src/darcs/X11 $ runhaskell Setup.hs configure > > configure: creating ./config.status > config.status: creating config.mk > config.status: creating X11.buildinfo > config.status: error: cannot find input file: include/HsX11Config.h.in > > How can I remedy this? I'm looking forward to seeing my changes in > action! Run autoreconf first. From simonmarhaskell at gmail.com Thu Feb 15 05:42:40 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Thu Feb 15 05:36:51 2007 Subject: Proposal: System.Timeout module for base In-Reply-To: <1923347863.20070201134923@gmail.com> References: <878xfpv1yd.fsf@write-only.cryp.to> <20070128121623.GB10874@localdomain> <871wlfruk7.fsf@write-only.cryp.to> <20070129222926.GA17786@localdomain> <45BF3823.5080205@gmail.com> <20070130163806.GA15160@localdomain> <45C1B6F5.8080002@gmail.com> <1923347863.20070201134923@gmail.com> Message-ID: <45D43920.3030609@gmail.com> Bulat Ziganshin wrote: > Hello Simon, > > Thursday, February 1, 2007, 12:46:29 PM, you wrote: > >> Any other suggestions? > > may be, we can raise exception in foreign language? at least for > 'safe' calls. i.e., we establish in RTS signal handler. this handler > checks whether we are performing safe call and if so - raise > language-specific exception... hmm, if that's possible There's no way to raise an exception in C, in general. > btw, how about using for *Haskell* code *default* signal handler that > raise Haskell exception? i think that using signal handlers to process > OS-generated events is just legacy from the C days. i.e. 'main' > should be called by RTS inside code like this: > > mainThread <- myThreadId > let onBreak event = do > throwTo mainThread BreakException > bracket (installHandler$ Catch onBreak) (installHandler) $ \oldHandler -> do > main > > (of course, this handles only ^Break and only on Windows) > > among other things, this should make signal handling portable between > Win/Unix Yes, we've discussed this in the past (e.g. there was a thread about this on the haskell-prime list). I'm definitely in favour of doing something along these lines. Cheers, Simon From hoelz at wisc.edu Thu Feb 15 06:08:12 2007 From: hoelz at wisc.edu (Rob Hoelz) Date: Thu Feb 15 06:02:29 2007 Subject: Submitting a darcs patch Message-ID: <20070215050812.2a91c518@TheRing.javasnob.homelinux.net> I just made some small changes (I figure smaller would be better for my first patch, and I'm also new to Haskell) to the Xlib bindings, adding support for property events and implementing an XGetAtomName function. Seeing as I'm new to darcs, how do I submit a patch and to whom do I submit it? I've already made the patch with darcs record. Thanks, Rob Hoelz From dons at cse.unsw.edu.au Thu Feb 15 06:33:39 2007 From: dons at cse.unsw.edu.au (Donald Bruce Stewart) Date: Thu Feb 15 06:27:51 2007 Subject: Submitting a darcs patch In-Reply-To: <20070215050812.2a91c518@TheRing.javasnob.homelinux.net> References: <20070215050812.2a91c518@TheRing.javasnob.homelinux.net> Message-ID: <20070215113338.GA13609@cse.unsw.EDU.AU> hoelz: > I just made some small changes (I figure smaller would be better for > my first patch, and I'm also new to Haskell) to the Xlib bindings, > adding support for property events and implementing an XGetAtomName > function. Seeing as I'm new to darcs, how do I submit a patch and to > whom do I submit it? I've already made the patch with darcs record. > great! The best way to have your patch added is to either a) if its a non-core library like Xlib, send to the maintainer. you can do this with darcs send -o /tmp/my.patch And then attach and mail that patch to the library maintainer. (should be listed in the .cabal file) b) if its for a core library, like 'base' , you follow the library submission process, http://haskell.org/haskellwiki/How_to_write_a_Haskell_program which also has some useful advice that applies to case a). In this case you should follow part a). Cheers, Don From bulat.ziganshin at gmail.com Thu Feb 15 15:35:25 2007 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Thu Feb 15 15:30:29 2007 Subject: raising exceptions for signals In-Reply-To: <45D43920.3030609@gmail.com> References: <878xfpv1yd.fsf@write-only.cryp.to> <20070128121623.GB10874@localdomain> <871wlfruk7.fsf@write-only.cryp.to> <20070129222926.GA17786@localdomain> <45BF3823.5080205@gmail.com> <20070130163806.GA15160@localdomain> <45C1B6F5.8080002@gmail.com> <1923347863.20070201134923@gmail.com> <45D43920.3030609@gmail.com> Message-ID: <8610129304.20070215233525@gmail.com> >> btw, how about using for *Haskell* code *default* signal handler that >> raise Haskell exception? i think that using signal handlers to process >> OS-generated events is just legacy from the C days. i.e. 'main' >> should be called by RTS inside code like this: >> >> mainThread <- myThreadId >> let onBreak event = do >> throwTo mainThread BreakException >> bracket (installHandler$ Catch onBreak) (installHandler) $ \oldHandler -> do >> main >> >> (of course, this handles only ^Break and only on Windows) >> >> among other things, this should make signal handling portable between >> Win/Unix > Yes, we've discussed this in the past (e.g. there was a thread about this on the > haskell-prime list). I'm definitely in favour of doing something along these lines. how about adding such facility to ghc HEAD? i can write initial windows implementation and put it to discussion here or in ghc maillist -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From jeremy.shaw at linspireinc.com Fri Feb 16 19:38:31 2007 From: jeremy.shaw at linspireinc.com (Jeremy Shaw) Date: Fri Feb 16 19:32:33 2007 Subject: [Haskell] Haskell Xlib bindings In-Reply-To: <45D1F07B.3000707@gmail.com> References: <20070204160044.7c87f8d8@localhost.localdomain> <200702101804.32638.sven.panne@aedion.de> <45D1B9F7.7080208@gmail.com> <200702131720.30082.sven.panne@aedion.de> <45D1F07B.3000707@gmail.com> Message-ID: <7iuhy5x4.wl%jeremy.shaw@linspireinc.com> At Tue, 13 Feb 2007 17:08:11 +0000, Simon Marlow wrote: > I think you misinterpreted me slightly: I didn't mean to ask "why XCB when we > have an Xlib binding?", I'm asking "why do we need either?". Who is going to > use it? Is someone planning to write a widget set in Haskell? If you want to use OpenGL, you still need some way to open a window, get keyboard/mouse events, etc. Some possibilities are: - OpenGL+SDL - OpenGL+GLUT - OpenGL+Gtk2HS - OpenGL+Xlib+GLX - OpenGL+wxWidgets(??) So far I have liked the OpenGL+Xlib+GLX solution the best -- in part, because it has the least number of extra dependencies. Though, it is also the least portable, and most verbose. Some of the applications I would like to write would have mostly non-standard widgets. So building on top of an existing widget set would add an extra layer of (mostly unused) indirection. j. ps. Some (minimal) Haskell GLX bindings and Example.hs can be found at: http://www.n-heptane.com/nhlab/repos/haskell-glx/ From marco-oweber at gmx.de Sat Feb 17 11:48:15 2007 From: marco-oweber at gmx.de (Marc Weber) Date: Sat Feb 17 10:43:00 2007 Subject: Where prelude alternatives/ classes and types to get values? Message-ID: <20070217164815.GA24388@gmx.de> The prelude has some issues such like Map.empty, Sequnce.empty, Set.empty It would be much nicer to use class Empty where empty :: a except of more complicated error messages (especially for newbies) Are there already some proposals? Is this the right place to discuss these topics? I got this idea because I'm currently learning more about webfunctions. Some states (eg counters) are implemented using IORefs. I could imagine a class class ModifyIO m c where modify :: IORef a -> ( a -> a ) -> m c data Old a data New a data OldNew a = OldNew a a; modify f = do a <- readIORef io let new = f a writeIORef io new return $ f old new instance ModifyIO IO (Old a) = modify io f = modify io (\old _ -> Old old) instance ModifyIO IO (New a) = modify io f = modify io (\_ new -> New new) instance ModifyIO IO (OldNew a) = modify io f = modify io OldNew which would lead to code such as ... = do (New count) <- modify ioCounterRef (+1) ... compared to ... = do count <- readIORef ioCounterRef let count = count + 1 writeIORef ioCounterRef count ... Do you think this style is insane? Marc Weber From ndmitchell at gmail.com Sat Feb 17 11:01:17 2007 From: ndmitchell at gmail.com (Neil Mitchell) Date: Sat Feb 17 10:55:18 2007 Subject: Where prelude alternatives/ classes and types to get values? In-Reply-To: <20070217164815.GA24388@gmx.de> References: <20070217164815.GA24388@gmx.de> Message-ID: <404396ef0702170801w23630250n7fe4a2967649d2f2@mail.gmail.com> Hi > I could imagine a class > > class ModifyIO m c where > modify :: IORef a -> ( a -> a ) -> m c m would have to be IO, c would be a bit pointless - so IO () is a better return type. You can then Hoogle for it: IORef a -> (a -> a) -> IO () http://haskell.org/hoogle/?q=IORef%20a%20-%3E%20(a%20-%3E%20a)%20-%3E%20IO%20() ... = do (New count) <- modify ioCounterRef (+1) = do newcount <- modifyIORef ioCounterRef (+1) It already exists :) Thanks Neil From stefanor at cox.net Sat Feb 17 11:19:36 2007 From: stefanor at cox.net (Stefan O'Rear) Date: Sat Feb 17 11:13:38 2007 Subject: Where prelude alternatives/ classes and types to get values? In-Reply-To: <20070217164815.GA24388@gmx.de> References: <20070217164815.GA24388@gmx.de> Message-ID: <20070217161936.GA3792@localhost.localdomain> On Sat, Feb 17, 2007 at 05:48:15PM +0100, Marc Weber wrote: > The prelude has some issues such like > Map.empty, > Sequnce.empty, > Set.empty > > It would be much nicer to use > class Empty where > empty :: a > except of more complicated error messages (especially for newbies) > > Are there already some proposals? > Is this the right place to discuss these topics? Yes, and Yes. In my opinion, Haskell should take a cue from the videogame industry and create an EasyPrelude, normal Prelude, and HardPrelude. The EasyPrelude would be something like the Helium prelude - very little overloading. The normal prelude would be the Haskell 98 prelude, modulo bugfixes. The hard prelude would be everything we want, newbies can be ignored. Classes for functors, emptyable functors, catenable functors, applicative functors, monoids, semigroups, (+) and (++) overloaded, etc, etc, etc. > I got this idea because I'm currently learning more about webfunctions. > Some states (eg counters) are implemented using IORefs. > > I could imagine a class > ... Look at Bulat's ArrayRef library. http://haskell.org/haskellwiki/Library/ArrayRef From ndmitchell at gmail.com Sat Feb 17 11:40:21 2007 From: ndmitchell at gmail.com (Neil Mitchell) Date: Sat Feb 17 11:34:22 2007 Subject: Where prelude alternatives/ classes and types to get values? In-Reply-To: <20070217161936.GA3792@localhost.localdomain> References: <20070217164815.GA24388@gmx.de> <20070217161936.GA3792@localhost.localdomain> Message-ID: <404396ef0702170840v4ab084eem4687889b4b2b7e25@mail.gmail.com> Hi > In my opinion, Haskell should take a cue from the videogame industry > and create an EasyPrelude, normal Prelude, and HardPrelude. > > The EasyPrelude would be something like the Helium prelude - very > little overloading. The main reason for something like this is that error messages aren't as clear. Wouldn't a better solution be a "-beginner" flag which on seeing x ++ xs gives the hint "x is not a list, it doesn't have to be, but you probably wanted it to be". Or perhaps someone could research good type error messages? I don't like the idea of partitioning Haskell users into discrete sets based on their ability - its not a nice culture to have, but more practically it makes a painful jump between each stage. Thanks Neil From bulat.ziganshin at gmail.com Sat Feb 17 11:48:41 2007 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sat Feb 17 11:42:56 2007 Subject: Where prelude alternatives/ classes and types to get values? In-Reply-To: <20070217164815.GA24388@gmx.de> References: <20070217164815.GA24388@gmx.de> Message-ID: <1562378790.20070217194841@gmail.com> Hello Marc, Saturday, February 17, 2007, 7:48:15 PM, you wrote: > It would be much nicer to use > class Empty where > empty :: a there are two libraries, Edisson and Collections, which includes large hierarchies of collection type classes about references. my program includes the following minilib: infixl 0 =:, +=, -=, ++=, .=, .<-, <<= -- Simple variables ref = newIORef new = newIORef val = readIORef a=:b = writeIORef a b a+=b = modifyIORef a (\a->a+b) a-=b = modifyIORef a (\a->a-b) a.=b = modifyIORef a (\a->b a) a++=b = modifyIORef a (\a->a++b) a.<-b = modifyIORefIO a (\a->b a) withRef init = with' (ref init) val -- Accumulation lists newtype AccList a = AccList [a] newList = ref$ AccList [] a<<=b = a .= (\(AccList x) -> AccList$ b:x) listVal a = val a >>== (\(AccList x) -> reverse x) withList = with' newList listVal addToIORef :: IORef [a] -> a -> IO () addToIORef var x = var .= (x:) modifyIORefIO :: IORef a -> (a -> IO a) -> IO () modifyIORefIO var action = do readIORef var >>= action >>= writeIORef var with' init finish action = do a <- init; action a; finish a usage examples: blocks <- withList $ \found -> do scanArchiveSearchingDescriptors archive arcname found buf arcsize scanArchiveSearchingDescriptors archive arcname found buf arcsize = do pos' <- ref base_pos ... pos' =: blPos block found <<= block pos <- val pos' if pos > base_pos ... processDir filelist = do let (dirs,files) = partition fiIsDir filelist files2delete ++= files dirs2delete ++= dirs let update_crc buf len = do when (block_type/=DATA_BLOCK) $ do crc .<- updateCRC buf len origsize += len errors' <- ref (length bad) ... when (crc/=original_crc) $ do errors' += 1 ... errors <- val errors' when (errors>0) $ do uiStartDeCompression = do time <- getCPUTime refArchiveProcessingTime -= time uiFinishDeCompression = do time <- getCPUTime refArchiveProcessingTime += time -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From marco-oweber at gmx.de Sat Feb 17 13:13:08 2007 From: marco-oweber at gmx.de (Marc Weber) Date: Sat Feb 17 12:07:54 2007 Subject: Where prelude alternatives/ classes and types to get values? In-Reply-To: <404396ef0702170801w23630250n7fe4a2967649d2f2@mail.gmail.com> References: <20070217164815.GA24388@gmx.de> <404396ef0702170801w23630250n7fe4a2967649d2f2@mail.gmail.com> Message-ID: <20070217181308.GA11942@gmx.de> > m would have to be IO, c would be a bit pointless - so IO () is a > better return type. It doesn't have to be IO. It can also be implemented using liftIO . modify .. Then you can use htis modify function from any monad beeing an instance of IOMonad.. > > You can then Hoogle for it: IORef a -> (a -> a) -> IO () > > http://haskell.org/hoogle/?q=IORef%20a%20-%3E%20(a%20-%3E%20a)%20-%3E%20IO%20() > > > ... = do (New count) <- modify ioCounterRef (+1) > > = do newcount <- modifyIORef ioCounterRef (+1) > > It already exists :) Hi Neil. Thanks for your hint. This time I already have found modifyIORef ;) But as hoogle states: Searched for modifyIORef Results 1 - 2 of 2 Data.IORef. modifyIORef :: IORef a -> (a -> a) -> IO () Data.IORef. atomicModifyIORef :: IORef a -> (a -> (a, b)) -> IO b the return type of modifyIORef is IO (), not IO So only using this function wouldn't solve the problem, right? Marc From bos at serpentine.com Sat Feb 17 19:28:21 2007 From: bos at serpentine.com (Bryan O'Sullivan) Date: Sat Feb 17 19:20:33 2007 Subject: time package needs a tiny README file Message-ID: <45D79DA5.6000309@serpentine.com> Hello, Ashley - There's a bug open against ghc 6.6 regarding the time package, which notes that it doesn't install HsTime.h or HsTimeConfig.h when being installed. If one already has a copy of the time darcs repo, it's still not obvious how to build it. Please add a README with something like the following instructions, as a bit of Googling shows that I am not the first person to have spent a few minutes confused by this: To build the time package, you must have GNU autoconf installed. Run "autoreconf" before the usual Cabal build steps (configure/build/install). There is no need to run the "configure" script; the Cabal build process will do this for you. Thank you for your help, References: <878xfpv1yd.fsf@write-only.cryp.to> <20070128121623.GB10874@localdomain> <871wlfruk7.fsf@write-only.cryp.to> <20070129222926.GA17786@localdomain> <45BF3823.5080205@gmail.com> <20070130163806.GA15160@localdomain> <45C1B6F5.8080002@gmail.com> <1923347863.20070201134923@gmail.com> <45D43920.3030609@gmail.com> <8610129304.20070215233525@gmail.com> Message-ID: <45D9A633.7070609@gmail.com> Bulat Ziganshin wrote: >>> btw, how about using for *Haskell* code *default* signal handler that >>> raise Haskell exception? i think that using signal handlers to process >>> OS-generated events is just legacy from the C days. i.e. 'main' >>> should be called by RTS inside code like this: >>> >>> mainThread <- myThreadId >>> let onBreak event = do >>> throwTo mainThread BreakException >>> bracket (installHandler$ Catch onBreak) (installHandler) $ \oldHandler -> do >>> main >>> >>> (of course, this handles only ^Break and only on Windows) >>> >>> among other things, this should make signal handling portable between >>> Win/Unix > >> Yes, we've discussed this in the past (e.g. there was a thread about this on the >> haskell-prime list). I'm definitely in favour of doing something along these lines. > > how about adding such facility to ghc HEAD? i can write initial > windows implementation and put it to discussion here or in ghc > maillist I don't have a clear idea for the design, I'd have to go back and look at the haskell prime discussion. Do you want to propose something? Cheers, Simon From sven.panne at aedion.de Mon Feb 19 09:56:14 2007 From: sven.panne at aedion.de (Sven Panne) Date: Mon Feb 19 09:50:09 2007 Subject: [Haskell] Haskell Xlib bindings In-Reply-To: <7iuhy5x4.wl%jeremy.shaw@linspireinc.com> References: <20070204160044.7c87f8d8@localhost.localdomain> <45D1F07B.3000707@gmail.com> <7iuhy5x4.wl%jeremy.shaw@linspireinc.com> Message-ID: <200702191556.14981.sven.panne@aedion.de> On Saturday 17 February 2007 01:38, Jeremy Shaw wrote: > [...] > ps. Some (minimal) Haskell GLX bindings and Example.hs can be found at: > > http://www.n-heptane.com/nhlab/repos/haskell-glx/ Just a small note: One of the protocol extensions in XCB is GLX, so XHB would inherit this, of course. I don't have an idea how the GLX API will look like then, a thin "beauty layer" might be needed. Cheers, S. From ross at soi.city.ac.uk Wed Feb 21 19:39:13 2007 From: ross at soi.city.ac.uk (Ross Paterson) Date: Wed Feb 21 19:33:01 2007 Subject: [Haskell] Composing applicative functors? In-Reply-To: References: Message-ID: <20070222003913.GA24253@soi.city.ac.uk> [redirecting to libraries] On Wed, Feb 21, 2007 at 04:23:50PM -0800, Conal Elliott wrote: > Is the composition instance of Control.Applicative defined somewhere? I see > it in the McBride & Paterson paper [1], but not in the library docs [2]. > I'd rather pull it in from a library than (re)define it myself. > > [1] http://www.soi.city.ac.uk/~ross/papers/Applicative.pdf > [2] > http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Applicative.html It's not defined in the libraries. The type (and the identity functor) should probably go in the module that defines Functor (currently Control.Monad) with a Functor instance, and an Applicative instance in Control.Applicative. From haskell at list.mightyreason.com Fri Feb 23 10:24:27 2007 From: haskell at list.mightyreason.com (Chris Kuklewicz) Date: Fri Feb 23 10:18:24 2007 Subject: EnumSet and EnumMap Message-ID: <45DF072B.20502@list.mightyreason.com> I could not quickly find anyone else writing this boiler plate, so I have posted this useful wrapper on the Haskell wiki at http://haskell.org/haskellwiki/EnumSet_EnumMap This uses a cheap newtype to wrap IntSet and IntMap so that you can store any Enum in them. It saves either writing many toEnum/fromEnum functions or using the slower and more generic Data.Set and Data.Map. The original motivation was to go from Map Char to IntMap. And as a bonus, the type signature of the newtype is the same kind as Data.Set and Data.Map (which matters when declaring instances...) > newtype EnumSet e = EnumSet {unEnumSet :: S.IntSet} > deriving (Monoid,Eq,Read,Show,Ord) > newtype EnumMap k a = EnumMap {unEnumMap :: M.IntMap a} > deriving (Eq,Read,Show,Ord,Monoid,Foldable,Functor) This has been quickly tested with GHC 6.6 and may contain typographical errors I have not caught yet. -- Chris From claus.reinke at talk21.com Fri Feb 23 12:41:57 2007 From: claus.reinke at talk21.com (Claus Reinke) Date: Fri Feb 23 12:35:43 2007 Subject: hasktags - small patch References: <45DC145A.1010002@gmail.com> <00b001c755cb$1ffc77f0$20147ad5@cr3lt><1E6A71FC-3B5E-4B4D-A6B8-F372336F2566@cs.uu.nl><00e301c755ed$1525aff0$20147ad5@cr3lt> <20070222024205.GB21774@gmx.de> Message-ID: <013b01c75771$eb5cd8c0$854d7ad5@cr3lt> [cc-ed to libraries, as they seem to be more appropriate for cabal topics] > Some time ago I've tweaked cabal to start ghci with package options > given in the .cabal file. > > Perhaps it might be useful for someone: yes, i'd like to see something like this in cabal. cf also http://www.mail-archive.com/glasgow-haskell-users@haskell.org/msg11101.html claus > module Main where > import Distribution.Simple > import Distribution.Simple.Configure > import Distribution.Simple.LocalBuildInfo > import System > import System.Process > import System.Exit > import Monad > > main= do > args <- getArgs -- check args to launch ghci > when (length args > 0) $ do > when ((args!!0) == "ghci") $ do > lbi <- getPersistBuildConfig > let packageArgs = (concat.concat) [ [" -package ", showPackageId pkg] | pkg <- packageDeps lbi ] > system("ghci " ++ packageArgs) > exitWith ExitSuccess > defaultMain -- fallback to defaultMain > > Then you can use ./setup ghci to start ghci > It is incomplete but should work for default packages.. > > Marc > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From apa3a at yahoo.com Fri Feb 23 21:56:31 2007 From: apa3a at yahoo.com (Andriy Palamarchuk) Date: Fri Feb 23 21:50:10 2007 Subject: Control.Monad.Cont documentation Message-ID: <205356.71978.qm@web56409.mail.re3.yahoo.com> Documentation for the Continuation monad. Right now this module does not have any haddock comments. Per Jeff Newbern's gracious permission included relevant information from his cool tutorial "All About Monads" http://www.nomaware.com/monads/, created a couple of examples. The source of the module and haddock output for it are attached to the ticket: http://hackage.haskell.org/trac/ghc/ticket/1169 Here is the generated haddock output: http://hackage.haskell.org/trac/ghc/attachment/ticket/1169/Control-Monad-Cont.html?format=raw Deadline for the proposal - 2 weeks. Questions, comments, suggestions? Andriy Palamarchuk ____________________________________________________________________________________ Yahoo! Music Unlimited Access over 1 million songs. http://music.yahoo.com/unlimited From gale at sefer.org Sun Feb 25 03:30:13 2007 From: gale at sefer.org (Yitzchak Gale) Date: Sun Feb 25 03:23:48 2007 Subject: [Haskell-cafe] EnumSet and EnumMap In-Reply-To: <45DF072B.20502@list.mightyreason.com> References: <45DF072B.20502@list.mightyreason.com> Message-ID: <2608b8a80702250030m4caf790ai1108f5e272f18ae1@mail.gmail.com> Chris Kuklewicz wrote: > I have posted > this useful wrapper on the Haskell wiki at > http://haskell.org/haskellwiki/EnumSet_EnumMap In my opinion, this is important enough that IntMap and IntSet should be deprecated from the standard libraries in favor of EnumMap and EnumSet. Besides the obvious advantage of a huge increase in generality at no performance cost (I think), there is another reason. The difference in interface been the Int and non-Int versions of Set and Map forces you to make an early decision about which to use. That decision get pervasively hard-wired into your code. The result is that it is sometimes hard to write flexible polymorphic Haskell while still reserving the option of switching to Int as an optimization. Chris' idea fixes that problem. Regards, Yitz From haskell at list.mightyreason.com Sun Feb 25 06:35:13 2007 From: haskell at list.mightyreason.com (Chris Kuklewicz) Date: Sun Feb 25 06:28:50 2007 Subject: [Haskell-cafe] EnumSet and EnumMap In-Reply-To: <2608b8a80702250030m4caf790ai1108f5e272f18ae1@mail.gmail.com> References: <45DF072B.20502@list.mightyreason.com> <2608b8a80702250030m4caf790ai1108f5e272f18ae1@mail.gmail.com> Message-ID: <45E17471.60801@list.mightyreason.com> Yitzchak Gale wrote: > Chris Kuklewicz wrote: >> I have posted >> this useful wrapper on the Haskell wiki at >> http://haskell.org/haskellwiki/EnumSet_EnumMap > > In my opinion, this is important enough that IntMap > and IntSet should be deprecated from the standard > libraries in favor of EnumMap and EnumSet. I disagree. > > Besides the obvious advantage of a huge increase > in generality at no performance cost (I think), there > is another reason. > There is a performance cost. Each use of Data.List.map in that code is a performance cost. And if toEnum/fromEnum is non-trivial there is a performance cost. For instance, I have abandoned (EnumMap Char) and made a specific CharMap module that uses GHC.Base.unsafeChr to avoid the bounds checks. If you want zero performance penalty you need to stop using Enum and create an UnsafeEnum type class that does casting without bounds checking, and knows how to cast things like "[Char]" to "[Int]" and back without touching each element. > The difference in interface been the Int and non-Int > versions of Set and Map forces you to make an > early decision about which to use. That decision > get pervasively hard-wired into your code. This is true. The solution for real application is to adopt a type class interface to collections, for which a few examples exist. > > Chris' idea fixes that problem. EnumMap and EnumSet increase type safety but not always efficiency. > > Regards, > Yitz From gale at sefer.org Sun Feb 25 14:36:38 2007 From: gale at sefer.org (Yitzchak Gale) Date: Sun Feb 25 14:30:15 2007 Subject: [Haskell-cafe] EnumSet and EnumMap In-Reply-To: <45E17471.60801@list.mightyreason.com> References: <45DF072B.20502@list.mightyreason.com> <2608b8a80702250030m4caf790ai1108f5e272f18ae1@mail.gmail.com> <45E17471.60801@list.mightyreason.com> Message-ID: <2608b8a80702251136q5b6a541pc7d2b706c35173d2@mail.gmail.com> Chris Kuklewicz wrote: > There is a performance cost. Each use of > Data.List.map in that code is a performance > cost. And if toEnum/fromEnum is non-trivial > there is a performance cost. Are you sure? I am under the impression that at least for GHC, toEnum/fromEnum on Int is free. And every Data.List.map in your code is mapping one of toEnum, fromEnum, or a newtype constructor, so those should also be free, or perhaps could be made free with a pragma. Expert opinions on this? On types other than Int, you'll incur a very small cost. It should still be much better than generic Map and Set. If the difference between that and building something by hand for types other than Int is important, you can still do that, as now. >> The difference in interface been the Int and non-Int >> versions of Set and Map forces you to make an >> early decision about which to use. That decision >> gets pervasively hard-wired into your code. > This is true. The solution for real application is to > adopt a type class interface to collections, for which > a few examples exist. That is a far-reaching change. I hope it happens some day. In the meantime,