- Libraries - Haskell.org

RE: [darcs-devel] [darcs #279] [wish] Use readline for line-editing
by Simon Marlow 21 Mar '05

21 Mar '05

To enable signals to be caught by Haskell code during a call to readline, you need to be using the threaded RTS (-threaded). This is because the call to readline will block the entire RTS in the non-threaded version. However, there's a rather large caveat: signal handling in the threaded RTS isn't really up to scratch, so results might be a bit unreliable. It's on my queue to fix this at some point. I do remember testing this with GHCi once. If you compile GHCi with -threaded then you can ^C at the prompt and it works (or did at one stage, anyway). Cheers, Simon On 19 March 2005 12:54, David Roundy wrote: > I'm CCing the libraries list on this, since it looks like it may be a > bug in signal handling with the readline module. Or at least a highly > unexpected interaction of sorts. > > Are we just out of luck, and should we just not use readline? Or is > there some way to interupt execution, and exit cleanly (such that the > cleanup portion of brackets is performed) in response to a sigINT > while readline is running? > > I took a quick look at this, and also couldn't figure out what's going > wrong. I know that signal handlers run in a separate haskell thread, > so it may be that perhaps the signal handler is just waiting until > the ffi function returns before running. :( I'm feeling pessimistic > at the moment, and thinking that perhaps we simply can't use readline > in darcs, since it's hard to imagine that a thrown asynchronous > exception will be able to interrupt a FFI call... > > On Fri, Mar 18, 2005 at 03:15:53PM -0500, Martin Bays via RT wrote: >> * Thursday, 2005-03-17 at 07:39 -0500 - David Roundy via RT >> <bugs(a)darcs.net>: >>> A quick look suggests that maybe you can use setCatchSignals? Alas, >>> the readline module seems almost 100% undocumented... :( >> >> I did try that, to no avail. Which is to be expected, as signals are >> meant to be set to be caught by default. >> >> There is indeed no documentation, but afaict the bits we're dealing >> with >> are just straight wrappers round the library calls. In particular >> >> readline :: String -> IO (Maybe String) >> readline prompt = do >> ptr <- withCString prompt readlineC >> flip maybePeek ptr $ \ptr' -> do >> line <- peekCString ptr' >> free ptr' >> return line >> foreign import ccall "readline" readlineC :: Ptr CChar -> IO (Ptr >> CChar) >> >>> It may be that the problem is that readline blocks asynchronous >>> exceptions, and if that's the case, I'm not sure what we can do, >>> since darcs responds to sigINT by throwing an asynchronous >>> exception, so that we can use block in sensitive code to make sure >>> hitting ctrl-C doesn't corrupt anything. >> >> I don't think that's the problem - it appears that the exceptions >> aren't being thrown until too late. What confuses me is just how >> late that >> is. AFAICT, the signals aren't being handled (in the sense of >> causing a throwDynTo) until some point well after the readline has >> finished. In particular, with the following cheap debugging >> redefinition in SignalHandler.lhs: >> >> ih :: ThreadId -> Signal -> IO () >> ih thid s = >> do installHandler s (Catch $ >> (\sig -> (print $ "throwing") >> >> throwDynTo thid sig) $ >> SignalException s) Nothing >> return () >> >> we get the following behaviour: >> >> What is the version name? ^C >> What is the version name? ao^C^Ceu >> "throwing" >> "throwing" >> "throwing" >> Interrupted! >> >> A signal is thrown for each SIGINT, but not until some point I >> haven't >> been able to determine. I do not understand this, so can't see how >> to fix it! >> >> I'm not sure exactly how this fits into the picture, but >> interestingly >> there are issues even with something as simple as >> >> import System.Console.Readline ( readline ) >> import Maybe ( fromMaybe ) >> main = do s <- readline "test" >> print $ fromMaybe "noda" s >> >> Here two INTs are required to actually exit... why, I can't figure >> out. >> >> I fear I don't know what's going on with any of this, nor how to fix >> it. Hopefully the above will be of some use to someone who does.

1 0

RE: The FunctorM library
by Simon Marlow 21 Mar '05

21 Mar '05

On 21 March 2005 01:46, Iavor Diatchki wrote: > On Mon, 21 Mar 2005 00:29:38 +0100, Thomas Jäger <thjaeger(a)gmail.com> >> It is already annyoing enough that `Funtor' isn't a subclass of >> `Monad' although every monad must also be functor. > > I think you are right. Does anyone remember why "Functor" is not a > superclass of "Monad"? I think it is because it doesn't need to be. The current situation is slightly more flexible: you don't *have* to provide a Functor instance for every Monad instance. On the other hand, it means you occasionally have to write an additional Functor context in types. You can always get around that by defining class (Functor m, Monad m) => Monad' m where {} Cheers, Simon

3 2

cabal: library archive index and Mac OS X?
by Isaac Jones 21 Mar '05

21 Mar '05

I've gotten a bug report that Mac OS X complains when trying to link against cabal-generated archives, because it lacks an index: > ghc --make Main -o prog > Chasing modules from: Test > Compiling Main ( Test.hs, Test.o ) > Linking ... > ld: archive: /usr/local/lib/uust-1.0/libHSuust-1.0.a has no table of > contents, add one with ranlib(1) (can't load from it) In reading the man page of ranlib (on Linux), it sounds like an optional optimization. It also looks like a "-s" flag to ar will generate the index, so that's easy enough to fix. Can anyone explain to me whether / why Mac OS X needs this index, and whether it'll hurt for any other arches? Should we just pass the -s flag to ar? peace, isaac

4 4

The FunctorM library
by Iavor Diatchki 21 Mar '05

21 Mar '05

Hello, I was just looking at the FunctorM library that was recently added. I have a few comments: * Why is this library under "Data" and the rest of the monadic stuff is under "Control" (Related to this, what does the Reader monad have to do with Control?) * A better name for this might be "forEach". This is what I added to the Prelude of my monad library: -- | Apply a monadic function to each element in a container. -- In theory speak, this is a class that identifies functors which -- distribute over all monads. class ForEach f where forEach :: Monad m => f a -> (a -> m b) -> m (f b) instance ForEach [] where forEach xs f = mapM f xs instance ForEach Maybe where forEach Nothing f = return Nothing forEach (Just x) f = Just # f x forEach_ :: (Monad m, ForEach f) => f a -> (a -> m b) -> m () forEach_ xs f = forEach xs f >> return () -Iavor

2 2

Fwd: Broken Cabal
by Lemmih 19 Mar '05

19 Mar '05

---------- Forwarded message ---------- From: Iavor Diatchki <iavor.diatchki(a)gmail.com> Date: Mon, 14 Mar 2005 11:38:19 -0800 Subject: Broken Cabal To: glasgow-haskell-bugs(a)haskell.org Hello, I am not sure if this is the correct place to report this problem, but there is a bug in the Cabal distributed with GHC. I used the simplest possible Setup.hs file as shown in the documentation. All the modules in my library are in a directory Monad, e.g. Monad/State.hs, Monad/Reader.hs, etc. When I type: > runhaskell Setup.lhs sdist I get a source tar-ball but when I extract the files I get the following: monadLib-1.2.2/ monadLib-1.2.2/nad/ monadLib-1.2.2/nad/BackT.hs monadLib-1.2.2/nad/ExceptT.hs monadLib-1.2.2/nad/Reader.hs Notice that the "Mo" part of the directory name is missing. -Iavor _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs(a)haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

2 2

Re: [darcs-devel] [darcs #279] [wish] Use readline for line-editing
by David Roundy 19 Mar '05

19 Mar '05

I'm CCing the libraries list on this, since it looks like it may be a bug in signal handling with the readline module. Or at least a highly unexpected interaction of sorts. Are we just out of luck, and should we just not use readline? Or is there some way to interupt execution, and exit cleanly (such that the cleanup portion of brackets is performed) in response to a sigINT while readline is running? I took a quick look at this, and also couldn't figure out what's going wrong. I know that signal handlers run in a separate haskell thread, so it may be that perhaps the signal handler is just waiting until the ffi function returns before running. :( I'm feeling pessimistic at the moment, and thinking that perhaps we simply can't use readline in darcs, since it's hard to imagine that a thrown asynchronous exception will be able to interrupt a FFI call... On Fri, Mar 18, 2005 at 03:15:53PM -0500, Martin Bays via RT wrote: > * Thursday, 2005-03-17 at 07:39 -0500 - David Roundy via RT <bugs(a)darcs.net>: > > A quick look suggests that maybe you can use setCatchSignals? Alas, the > > readline module seems almost 100% undocumented... :( > > I did try that, to no avail. Which is to be expected, as signals are > meant to be set to be caught by default. > > There is indeed no documentation, but afaict the bits we're dealing with > are just straight wrappers round the library calls. In particular > > readline :: String -> IO (Maybe String) > readline prompt = do > ptr <- withCString prompt readlineC > flip maybePeek ptr $ \ptr' -> do > line <- peekCString ptr' > free ptr' > return line > foreign import ccall "readline" readlineC :: Ptr CChar -> IO (Ptr CChar) > > > It may be that the problem is that readline blocks asynchronous > > exceptions, and if that's the case, I'm not sure what we can do, since > > darcs responds to sigINT by throwing an asynchronous exception, so that > > we can use block in sensitive code to make sure hitting ctrl-C doesn't > > corrupt anything. > > I don't think that's the problem - it appears that the exceptions aren't > being thrown until too late. What confuses me is just how late that > is. AFAICT, the signals aren't being handled (in the sense of causing a > throwDynTo) until some point well after the readline has finished. In > particular, with the following cheap debugging redefinition in > SignalHandler.lhs: > > ih :: ThreadId -> Signal -> IO () > ih thid s = > do installHandler s (Catch $ > (\sig -> (print $ "throwing") >> > throwDynTo thid sig) $ > SignalException s) Nothing > return () > > we get the following behaviour: > > What is the version name? ^C > What is the version name? ao^C^Ceu > "throwing" > "throwing" > "throwing" > Interrupted! > > A signal is thrown for each SIGINT, but not until some point I haven't > been able to determine. I do not understand this, so can't see how to fix > it! > > I'm not sure exactly how this fits into the picture, but interestingly > there are issues even with something as simple as > > import System.Console.Readline ( readline ) > import Maybe ( fromMaybe ) > main = do s <- readline "test" > print $ fromMaybe "noda" s > > Here two INTs are required to actually exit... why, I can't figure out. > > I fear I don't know what's going on with any of this, nor how to fix it. > Hopefully the above will be of some use to someone who does. -- David Roundy http://www.darcs.net

1 0

RE: Cabal GHC-6.4
by Simon Marlow 16 Mar '05

16 Mar '05

Looks like you need to add the mtl package to Build-Depends. Cheers, Simon ________________________________ From: libraries-bounces(a)haskell.org [mailto:libraries-bounces@haskell.org] On Behalf Of Satnam Singh Sent: 16 March 2005 02:23 To: libraries(a)haskell.org Subject: Cabal GHC-6.4 I am trying to use Cabal in GHC-6.4 to build my software. However, I get the following error when I try and use the package I made: satnam@xpc> make examples ghc -fglasgow-exts -package lava LavaExamples/OneBitAdder.hs compilation IS NOT required C:\Program Files\lava\lava-1.0/libHSlava-1.0.a(Instance.o)(.text+0x56):fake: und efined reference to `ControlziMonadziState_zdfMonadStates_closure' C:\Program Files\lava\lava-1.0/libHSlava-1.0.a(Instance.o)(.text+0xc6):fake: und efined reference to `ControlziMonadziState_zdfMonadStates_closure' C:\Program Files\lava\lava-1.0/libHSlava-1.0.a(Instance.o)(.text+0x136):fake: un defined reference to `ControlziMonadziState_zdfMonadStates_closure' C:\Program Files\lava\lava-1.0/libHSlava-1.0.a(Instance.o)(.text+0x198):fake: un defined reference to `ControlziMonadziState_zdfMonadStates_closure' C:\Program Files\lava\lava-1.0/libHSlava-1.0.a(Instance.o)(.text+0x19d):fake: un defined reference to `ControlziMonadziState_modify_closure' C:\Program Files\lava\lava-1.0/libHSlava-1.0.a(Instance.o)(.text+0x20a):fake: un defined reference to `ControlziMonadziState_zdfMonadStates_closure' C:\Program Files\lava\lava-1.0/libHSlava-1.0.a(Instance.o)(.text+0x27a):fake: un defined reference to `ControlziMonadziState_zdfMonadStates_closure' C:\Program Files\lava\lava-1.0/libHSlava-1.0.a(Instance.o)(.text+0x137b):fake: u ndefined reference to `ControlziMonadziState_zdfMonadStates_closure' C:\Program Files\lava\lava-1.0/libHSlava-1.0.a(Instance.o)(.text+0x158f):fake: u ndefined reference to `ControlziMonadziState_zdfMonadStates_closure' C:\Program Files\lava\lava-1.0/libHSlava-1.0.a(Instance.o)(.text+0x1847):fake: u ndefined reference to `ControlziMonadziState_zdfMonadStates_closure' C:\Program Files\lava\lava-1.0/libHSlava-1.0.a(Instance.o)(.text+0x2a2d):fake: m ore undefined references to `ControlziMonadziState_zdfMonadStates_closure' follo w C:\Program Files\lava\lava-1.0/libHSlava-1.0.a(Instance.o)(.text+0x2de5):fake: u ndefined reference to `__stginit_ControlziMonadziState_' C:\Program Files\lava\lava-1.0/libHSlava-1.0.a(Instance.o)(.data+0x8):fake: unde fined reference to `ControlziMonadziState_zdfMonadStates_closure' C:\Program Files\lava\lava-1.0/libHSlava-1.0.a(Instance.o)(.data+0x1c):fake: und efined reference to `ControlziMonadziState_zdfMonadStates_closure' C:\Program Files\lava\lava-1.0/libHSlava-1.0.a(Instance.o)(.data+0x30):fake: und efined reference to `ControlziMonadziState_zdfMonadStates_closure' C:\Program Files\lava\lava-1.0/libHSlava-1.0.a(Instance.o)(.data+0x44):fake: und efined reference to `ControlziMonadziState_modify_closure' C:\Program Files\lava\lava-1.0/libHSlava-1.0.a(Instance.o)(.data+0x48):fake: und efined reference to `ControlziMonadziState_zdfMonadStates_closure' C:\Program Files\lava\lava-1.0/libHSlava-1.0.a(Instance.o)(.data+0x5c):fake: und efined reference to `ControlziMonadziState_zdfMonadStates_closure' C:\Program Files\lava\lava-1.0/libHSlava-1.0.a(Instance.o)(.data+0x70):fake: und efined reference to `ControlziMonadziState_zdfMonadStates_closure' C:\Program Files\lava\lava-1.0/libHSlava-1.0.a(Instance.o)(.data+0x17c):fake: un defined reference to `ControlziMonadziState_zdfMonadStates_closure' C:\Program Files\lava\lava-1.0/libHSlava-1.0.a(Instance.o)(.data+0x198):fake: un defined reference to `ControlziMonadziState_zdfMonadStates_closure' C:\Program Files\lava\lava-1.0/libHSlava-1.0.a(Instance.o)(.data+0x1b4):fake: mo re undefined references to `ControlziMonadziState_zdfMonadStates_closure' follow C:\Program Files\lava\lava-1.0/libHSlava-1.0.a(Instance.o)(.data+0x278):fake: un defined reference to `ControlziMonadziState_zdfMonadState_closure' C:\Program Files\lava\lava-1.0/libHSlava-1.0.a(Instance.o)(.data+0x294):fake: un defined reference to `ControlziMonadziState_zdfMonadStates_closure' C:\Program Files\lava\lava-1.0/libHSlava-1.0.a(Netlist.o)(.text+0x135):fake: und efined reference to `ControlziMonadziState_execState_closure' C:\Program Files\lava\lava-1.0/libHSlava-1.0.a(Netlist.o)(.text+0x11fd):fake: un defined reference to `__stginit_ControlziMonadziState_' C:\Program Files\lava\lava-1.0/libHSlava-1.0.a(Netlist.o)(.data+0x38):fake: unde fined reference to `ControlziMonadziState_execState_closure' C:\Program Files\lava\lava-1.0/libHSlava-1.0.a(PutTreeNetlist.o)(.text+0x989):fa ke: undefined reference to `ControlziMonadziState_execState_closure' C:\Program Files\lava\lava-1.0/libHSlava-1.0.a(PutTreeNetlist.o)(.text+0xc95):fa ke: undefined reference to `__stginit_ControlziMonadziState_' C:\Program Files\lava\lava-1.0/libHSlava-1.0.a(PutTreeNetlist.o)(.data+0x8c):fak e: undefined reference to `ControlziMonadziState_execState_closure' make: *** [examples] Error 1 satnam@xpc> Here is my lava.cabal file: ------------------------------------------------------------------------ ------- -- $Id: lava.cabal,v 1.3 2005/03/15 22:39:47 satnams Exp $ ------------------------------------------------------------------------ ------- Name: lava Version: 1.0 License: BSD3 Author: Satnam Singh Synopsis: The Lava system for FPGA design. Copyright: Satnam Singh, 2005. Stability: Experimental Package-URL: http://www.raintown.org/wiki/index.php/Lava Maintainer: s.singh(a)acm.org Build-Depends: haskell98 Extensions: MultiParamTypeClasses Exposed-Modules: Lava, Xilinx Other-Modules: Lava.Bit Lava.Classes Lava.CombinationalSimulation Lava.Elabora te Lava.Gates Lava.Instance Lava.Netlist Lava.Primitives Lava.PutTreeNetlist Lav a.RPM Lava.Serial Lava.SequentialSimulation Lava.Sim Lava.TypeExpr Lava.Utils La va.XST_VHDL Xilinx.Components

1 0

Cabal GHC-6.4
by Satnam Singh 16 Mar '05

16 Mar '05

I am trying to use Cabal in GHC-6.4 to build my software. However, I get the following error when I try and use the package I made: satnam@xpc> make examples ghc -fglasgow-exts -package lava LavaExamples/OneBitAdder.hs compilation IS NOT required C:\Program Files\lava\lava-1.0/libHSlava-1.0.a(Instance.o)(.text+0x56):fake: und efined reference to `ControlziMonadziState_zdfMonadStates_closure' C:\Program Files\lava\lava-1.0/libHSlava-1.0.a(Instance.o)(.text+0xc6):fake: und efined reference to `ControlziMonadziState_zdfMonadStates_closure' C:\Program Files\lava\lava-1.0/libHSlava-1.0.a(Instance.o)(.text+0x136):fake: un defined reference to `ControlziMonadziState_zdfMonadStates_closure' C:\Program Files\lava\lava-1.0/libHSlava-1.0.a(Instance.o)(.text+0x198):fake: un defined reference to `ControlziMonadziState_zdfMonadStates_closure' C:\Program Files\lava\lava-1.0/libHSlava-1.0.a(Instance.o)(.text+0x19d):fake: un defined reference to `ControlziMonadziState_modify_closure' C:\Program Files\lava\lava-1.0/libHSlava-1.0.a(Instance.o)(.text+0x20a):fake: un defined reference to `ControlziMonadziState_zdfMonadStates_closure' C:\Program Files\lava\lava-1.0/libHSlava-1.0.a(Instance.o)(.text+0x27a):fake: un defined reference to `ControlziMonadziState_zdfMonadStates_closure' C:\Program Files\lava\lava-1.0/libHSlava-1.0.a(Instance.o)(.text+0x137b):fake: u ndefined reference to `ControlziMonadziState_zdfMonadStates_closure' C:\Program Files\lava\lava-1.0/libHSlava-1.0.a(Instance.o)(.text+0x158f):fake: u ndefined reference to `ControlziMonadziState_zdfMonadStates_closure' C:\Program Files\lava\lava-1.0/libHSlava-1.0.a(Instance.o)(.text+0x1847):fake: u ndefined reference to `ControlziMonadziState_zdfMonadStates_closure' C:\Program Files\lava\lava-1.0/libHSlava-1.0.a(Instance.o)(.text+0x2a2d):fake: m ore undefined references to `ControlziMonadziState_zdfMonadStates_closure' follo w C:\Program Files\lava\lava-1.0/libHSlava-1.0.a(Instance.o)(.text+0x2de5):fake: u ndefined reference to `__stginit_ControlziMonadziState_' C:\Program Files\lava\lava-1.0/libHSlava-1.0.a(Instance.o)(.data+0x8):fake: unde fined reference to `ControlziMonadziState_zdfMonadStates_closure' C:\Program Files\lava\lava-1.0/libHSlava-1.0.a(Instance.o)(.data+0x1c):fake: und efined reference to `ControlziMonadziState_zdfMonadStates_closure' C:\Program Files\lava\lava-1.0/libHSlava-1.0.a(Instance.o)(.data+0x30):fake: und efined reference to `ControlziMonadziState_zdfMonadStates_closure' C:\Program Files\lava\lava-1.0/libHSlava-1.0.a(Instance.o)(.data+0x44):fake: und efined reference to `ControlziMonadziState_modify_closure' C:\Program Files\lava\lava-1.0/libHSlava-1.0.a(Instance.o)(.data+0x48):fake: und efined reference to `ControlziMonadziState_zdfMonadStates_closure' C:\Program Files\lava\lava-1.0/libHSlava-1.0.a(Instance.o)(.data+0x5c):fake: und efined reference to `ControlziMonadziState_zdfMonadStates_closure' C:\Program Files\lava\lava-1.0/libHSlava-1.0.a(Instance.o)(.data+0x70):fake: und efined reference to `ControlziMonadziState_zdfMonadStates_closure' C:\Program Files\lava\lava-1.0/libHSlava-1.0.a(Instance.o)(.data+0x17c):fake: un defined reference to `ControlziMonadziState_zdfMonadStates_closure' C:\Program Files\lava\lava-1.0/libHSlava-1.0.a(Instance.o)(.data+0x198):fake: un defined reference to `ControlziMonadziState_zdfMonadStates_closure' C:\Program Files\lava\lava-1.0/libHSlava-1.0.a(Instance.o)(.data+0x1b4):fake: mo re undefined references to `ControlziMonadziState_zdfMonadStates_closure' follow C:\Program Files\lava\lava-1.0/libHSlava-1.0.a(Instance.o)(.data+0x278):fake: un defined reference to `ControlziMonadziState_zdfMonadState_closure' C:\Program Files\lava\lava-1.0/libHSlava-1.0.a(Instance.o)(.data+0x294):fake: un defined reference to `ControlziMonadziState_zdfMonadStates_closure' C:\Program Files\lava\lava-1.0/libHSlava-1.0.a(Netlist.o)(.text+0x135):fake: und efined reference to `ControlziMonadziState_execState_closure' C:\Program Files\lava\lava-1.0/libHSlava-1.0.a(Netlist.o)(.text+0x11fd):fake: un defined reference to `__stginit_ControlziMonadziState_' C:\Program Files\lava\lava-1.0/libHSlava-1.0.a(Netlist.o)(.data+0x38):fake: unde fined reference to `ControlziMonadziState_execState_closure' C:\Program Files\lava\lava-1.0/libHSlava-1.0.a(PutTreeNetlist.o)(.text+0x989):fa ke: undefined reference to `ControlziMonadziState_execState_closure' C:\Program Files\lava\lava-1.0/libHSlava-1.0.a(PutTreeNetlist.o)(.text+0xc95):fa ke: undefined reference to `__stginit_ControlziMonadziState_' C:\Program Files\lava\lava-1.0/libHSlava-1.0.a(PutTreeNetlist.o)(.data+0x8c):fak e: undefined reference to `ControlziMonadziState_execState_closure' make: *** [examples] Error 1 satnam@xpc> Here is my lava.cabal file: ------------------------------------------------------------------------ ------- -- $Id: lava.cabal,v 1.3 2005/03/15 22:39:47 satnams Exp $ ------------------------------------------------------------------------ ------- Name: lava Version: 1.0 License: BSD3 Author: Satnam Singh Synopsis: The Lava system for FPGA design. Copyright: Satnam Singh, 2005. Stability: Experimental Package-URL: http://www.raintown.org/wiki/index.php/Lava Maintainer: s.singh(a)acm.org Build-Depends: haskell98 Extensions: MultiParamTypeClasses Exposed-Modules: Lava, Xilinx Other-Modules: Lava.Bit Lava.Classes Lava.CombinationalSimulation Lava.Elabora te Lava.Gates Lava.Instance Lava.Netlist Lava.Primitives Lava.PutTreeNetlist Lav a.RPM Lava.Serial Lava.SequentialSimulation Lava.Sim Lava.TypeExpr Lava.Utils La va.XST_VHDL Xilinx.Components

1 0

RE: Libraries needing documentation
by Simon Marlow 15 Mar '05

15 Mar '05

On 15 March 2005 07:04, Isaac Jones wrote: > Folks have listed these libraries as needing better documentation. Is > anyone around who is familiar with these who can add some haddock > patches? > > http://www.haskell.org/hawiki/LibraryDocsNeedingHelp Are people using Text.Html? I've been wondering whether it ought to be replaced, or at least revamped. Haddock uses a local version of this library with a number of fixes. The HTML library in WASH seems better, but I haven't investigated it thoroughly. Or perhaps HTML (XHTML to be precise) should just be a special case of an XML library? Anyone interested enough to take this on? Cheers, Simon

3 2

RE: Libraries needing documentation
by Simon Marlow 15 Mar '05

15 Mar '05

On 15 March 2005 12:40, Simon Marlow wrote: > On 15 March 2005 12:36, Henning Thielemann wrote: > >> On Tue, 15 Mar 2005, Simon Marlow wrote: >> >>> On 15 March 2005 07:04, Isaac Jones wrote: >>> >>>> Folks have listed these libraries as needing better documentation. >>>> Is anyone around who is familiar with these who can add some >>>> haddock patches? >>>> >>>> http://www.haskell.org/hawiki/LibraryDocsNeedingHelp >>> >>> Are people using Text.Html? >> >> Yes, I used it because it was shipped with GHC ... Is it outdated? > > Not necessarily outdated, but it's never really been through a > critical review, and I think there are a number of areas in which it > could be improved. It hasn't been updated [accidentally hit send...] with respect to the latest revisions of the HTML spec. Cheers, Simon

1 0