- Libraries - Haskell.org

HaXml and HXml toolbox; namespace support
by Graham Klyne 19 Mar '04

19 Mar '04

I'm currently looking at the innards of HXml Toolbox and HaXml, with a view to adopting an XML parser with XML namespace support. Based on that requirement alone, HXml Toolbox would be the obvious choice, since it already has namespace support, but I have some concerns. These may simply be my own ignorance, so I'm airing my views here so that any misconceptions can be corrected. I present my thoughts in terms of pro's and con's for each. HXml Toolbox ------------ + XML Namespace support + DTD Entity handling + Good degree of conformance to W3C test suite - difficult to find way around documentation; no obvious high-level description, other than Martin Schmidt's thesis which is out-of-date with respect to the current software. - can't find simple String -> XML tree parsing function (dealing with Internal DTD Entity components) - errors seems to be reported to stderr rather than handed back to the calling program - complex and non-portable distribution: I'm concerned that any attempt distribute my applications based on this library may prove difficult, short of copying (and effectively branching) the complete source code. - not developed with Hugs/Windows as an intended target ? efficiency: some problems parsing large XML files with Hugs 98 are noted. ? still actively supported ? HaXml ----- + Already part of the common hierarchical library + XML handling is cleanly separated from other functions + separate, hand-coded lexer which I assume will give better performance + appears to be actively supported - no namespace support ? DTD Entity handling ? - errors returned to caller. As far as I can tell, errors are raised using the 'error' function... [which I see results in program termination when evaluated]. Ouch! (Why not 'fail' instead of 'error'?) - source code needs CPP preprocessing * no external DTD support [this is not a problem for me, and I'd certainly prefer it to be optional, or at least separated from the XML parsing, to avoid dependency on an HTTP library]. ... A weakness of both packages seems to be the handling of syntax errors in the input. HaXml uses HuttonMeijerWallace combinators - could these be extended in the style of Parsec to return an error description, thus making it possible to provide an interface that allows the calling program to handle any errors? E.g. [[ newtype Parser s t a = P (s -> [t] -> [(a,s,[t])]) ]] becomes, say: [[ newtype Parser s t a = P (s -> [t] -> Either String [(a,s,[t])]) ]] and define fail accordingly. Or, even, just use Parsec? HXml Toolbox makes mention of reporting errors to stderr, I think [lost reference]. It appears that I can isolate the XML parser, which uses Parsec, but I'm not sure if I can isolate the DTD processing logic that deals with entity substitutions.... This looks problematic: it seems that entity substitution is done in an XmlStateFilter Monad. I'm finding it really hard to tease apart the various strands of processing here, which is indicative of my concerns about using this package. ... So, any pointers that help me decide which way to jump would be appreciated... #g ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

2 1

DData revision
by JP Bernardy 19 Mar '04

19 Mar '04

Hi, A revision of DData. http://users.skynet.be/jyp/DData/doc http://users.skynet.be/jyp/DData/ddata.tar.gz New sequences are added. I've tried to reflect settled issues in the code. If it is not so, tell me. I haven't done anything to argument ordering yet. I have nothing against the right bias, so, I can implement it, but it is easy to forget some cases... That change would need review. Cheers, JP. __________________________________ Do you Yahoo!? Yahoo! Mail - More reliable, more storage, less spam http://mail.yahoo.com

6 15

DData in hierarchical libraries
by JP Bernardy 19 Mar '04

19 Mar '04

Hello, I've compiled a haddock documentation for my proposal "DData in hierarchical libraries". I submit it to you for review. http://users.skynet.be/jyp/DData/doc/index.html The source code is available too. http://users.skynet.be/jyp/DData/doc/ddata.tar.gz Daan: I take the liberty to "publish" this without knowing the exact terms of your license. Given the audience of this list, I think it will be no problem. Cheers, JP. --------------- For easier review, a summary of changes follow. The source distribution also contains a diff. * Scc module removed More an algorithm than a data structure. Sort of (but not quite) redundant with SCC in Data.Graph * renamed "single" to "singleton" more explicit, more usual. * removed find, favouring (!) and lookup. avoids incoherency with Data.List.find Map.find :: Map k v -> k -> v List.find :: (a -> Bool) -> [a] -> Maybe a * removed (<>), prefering append More explicit. Besides, operators might be a problem in the current scheme of using modules qualified. * rename "isEmpty" to "null" to match List.null * foldL, foldR, foldI -> foldl, foldr, foldi to match Prelude.fold[lr] * Added instances * renamed "subset" to "isSubsetOf" this matches isPrefixOf, isSuffixOf * Added documentation / changed it to reflect changes incl. hints on how to use the module system. ----- I think I should explain why I wanted to change the interface of Maps. Consider the type of these functions: Set.fromList :: Ord a => [a] -> Set a Set.member :: Ord a => a -> Set a -> Bool Set.fold :: (a -> b -> b) -> b -> Set a -> b Set.filter :: Ord a => (a -> Bool) -> Set a -> Set a Map.fromList :: Ord k => [(k, a)] -> Map k a Map.member :: Ord k => k -> Map k a -> Bool Map.fold :: (a -> b -> b) -> b -> Map k a -> b Map.filter :: Ord k => (a -> Bool) -> Map k a -> Map k a With respect to fold and filter (and most functions), maps have the shape of collections of values. (The key type does not appear as such in the functions' signiatures) Yet, a few functions break this conventions. For example, "member" tests the presence of a key, not a value. This is justified by the implementation. I've come to think it is the way to go (given it is a "concrete" library). It makes me slightly uneasy that a few functions stand out, still. __________________________________ Do you Yahoo!? Get better spam protection with Yahoo! Mail. http://antispam.yahoo.com/tools

4 3

RE: Win32 process spawning, POpen and Hugs, revisited
by Simon Marlow 18 Mar '04

18 Mar '04

> The only thing I'd like to check on that I can't tell about is whether > passing stdin and stdout to runProcess will behave "correctly". Some > programs (e.g. gpg) can figure out how to get control of the tty by > themselves (to ask for passwords in the case of gpg), but others (some > versions of vi) will fail if their stdin and stdout > correspond to a tty. > It would be nice to be able to run "user-interactive" > commands such as text > editors in a safe and consistent manner. I'm not clear from your code > whether there will be a problem with passing stdin and stdout to > runProcess. If the process closes stdin, will it be closed > for me? If the > process changes the buffering of stdin, will that change it for me? > Enquiring minds want to know! :) Good questions, none of which I have given any thought to :-) You're almost certainly in a better position than me to decide what reasonable answers to these are, so would you like to propose some? Cheers, Simon

1 0

RE: DData revision (isSubsetOf / shorter names)
by Simon Marlow 18 Mar '04

18 Mar '04

> JP Bernardy wrote: > > http://users.skynet.be/jyp/DData/doc > > Now, where "isEmpty" is replaced by "null", I'ld rather see "subset" > instead of "isSubsetOf", particularly also because > "isProperSubsetOf" is so long. I vote for consistently using isXXXX for predicates. Cheers, Simon

6 9

RE: Win32 process spawning, POpen and Hugs, revisited
by Simon Marlow 18 Mar '04

18 Mar '04

My apologies to those who couldn't read the attachment. I've put it here; http://www.haskell.org/~simonmar/process/Process.hs Haddock docs here: http://www.haskell.org/~simonmar/process/System.Process.html > The abstraction could use an option to control whether > exiting or killing the parent process also terminates the child. Good point. > I'm not sure on what Windows foundation you are thinking of > implementing this, > but it's not easy to handle the command and arguments on the > Win32 API. The > arguments are handled by the API as a raw string, so the > caller must quote > the arguments according to awkard (possibly undocumented) > rules. I've worked > with this both in the Win32 API and using Perl. Perl didn't > have it right, so > in one case I was unable to invoke a certain command using > the full pathname, > because it contained spaces. We've already solved this problem: see System.Cmd.rawSystem in GHC 6.2. On Windows this translates the command line in such a way that the program will see exactly the arguments that you pass to rawSystem. Well, there's a small caveat: the target program has to be using Microsoft's standard C runtime semantics for parsing the command line (which pretty much everything does, I believe). Cheers, Simon

1 0

Data.Typeable
by Simon Peyton-Jones 18 Mar '04

18 Mar '04

Folks Ralf Laemmel and I have been making good progress with "scrap your boilerplate". (In fact there's a new paper at http://research.microsoft.com/~simonpj/papers/hmap/gmap2.ps; we'd love your comments.) Section 7 describes how to extend the Typeable story to higher kinds, in a manner that I know George Russell has already tried. It's rather beautiful, aside from the need to define a family of classes Typeable1, Typeable2, etc. But we've turned up a bad shortcoming in the Data.Typeable library. The present construction signature is like this: mkAppTy :: TyCon -> [TypeRep] -> TypeRep funTc :: TyCon mkFunTy :: TypeRep -> TypeRep -> TypeRep -- | Applies a type to a function type. Returns: @'Just' u@ if the -- first argument represents a function of type @t -> u@ and the -- second argument represents a function of type @t@. applyTy :: TypeRep -> TypeRep -> Maybe TypeRep What is missing is a function that takes two TypeReps and simply applies one to the other. So if one TypeRep is (ST T), and the other is Int, we want to build (ST T Int). The obvious name for this is 'applyTy' or 'mkAppTy', but they are both taken. Indeed, 'applyTy' is a bad name, because it only applies to *function* types. I'd like to suggest some re-naming mkTyConApp :: TyCon -> [TypeRep] -> TypeRep -- renaming of mkAppTy mkAppTy :: TypeRep -> TypeRep -> TypeRep -- new function mkFunTy -- no change funResultTy :: TypeRep -> TypeRep -> Maybe TypeRep -- ranming of applyTy I'm pretty sure about the first three. The last is the only "take this TypeRep apart" function that is currently offered, and it seems pretty specialised. Perhaps a more generic function would be splitTyConApp :: TypeRep -> (TyCon, [TypeRep]) (Remember, TypeReps only represent monotypes, so they are always a TyConApp.) Then we could build funResultTy from splitTyConApp. Is everyone happy with this? The main thing that seems unclear is what 'funResultTy' should be called. I guess we could just about stick with 'applyTy'. Opinions? Simon

1 0

RE: Win32 process spawning, POpen and Hugs, revisited
by Graham Klyne 17 Mar '04

17 Mar '04

Simon, Further to my previous message, this abstraction looks reasonable to me. If I ever manage to get the POpen module working, I think the code will adapt very easily to most of this interface. I do think your naming is more helpful. One area where I'm wary: your runInteractiveProcess returns a process handle, which can be used for further synchronization with the offspring process. I wonder if (a) this is really needed, and (b) if it might expose some awkward interactions with the interactive I/O streams. I don't have a particular problem in mind, just concerned that this might turn tricky in the future. #g -- At 12:01 17/03/04 +0000, Simon Marlow wrote: > >On a related note, I recently implemented a System.Process library on >Unix. Source code attached. The Windows implementation should be >relatively straightforward. Porting it to Hugs will require >System.Posix.forkProcess, but I don't see any great difficulties there. > >One warning: if you want to use it in a concurrent environment with GHC, >you need to use GHC's threaded RTS (i.e. use the -threaded option in the >forthcoming GHC 6.2.1), otherwise waitForProcess will block all threads. > >POpen-type abstractions can easily be layered on top of the >functionality here - indeed the library should probably contain some >higher-level versions which correspond to common usage. > >I think this is a good platform-independent abstraction for process >management. What do others think? > >Cheers, > Simon > >_______________________________________________ >Libraries mailing list >Libraries(a)haskell.org >http://www.haskell.org/mailman/listinfo/libraries ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

1 0

Win32 process spawning, POpen and Hugs, revisited
by Graham Klyne 16 Mar '04

16 Mar '04

Further to my previous messages: http://www.haskell.org//pipermail/haskell/2004-February/013522.html http://www.haskell.org//pipermail/haskell/2004-February/013679.html I've come back to my stripped-down test case, and recreated the C test program SpawnEchoShiftLetters.c [1] in Haskell SpawnEchoShiftLetters.hs [2]. I've also added some diagnostic code. To recap: the C code demonstrates that that the Win32 API used by spawnProc.c [4] is working as expected, so the problem appears to be in the Haskell interface to it. My problem seems to be occurring about here: [[ spawn cmd = withCString cmd $ \ p_cmd -> withObject 0 $ \ p_wIn -> withObject 0 $ \ p_rOut -> withObject 0 $ \ p_rErr -> do rc <- spawnProc p_cmd p_wIn p_rOut p_rErr when (rc /= 0) (ioError (userError ("runProc: unable to spawn " ++ show cmd))) wIn <- peek p_wIn (-1-} trace ("wIn "++show wIn) $ return () {- : -} (-2-} hIn <- openFd (fromIntegral wIn) False WriteMode False (-3-} trace ("hIn "++show hIn) $ return () ]] -- http://www.ninebynine.org/Software/HaskellUtils/Win32/POpen.hs Specifically: + the trace at {-1-} displays the expected value (i.e. the same as a similar trace in the C version of the code [1], namely the value 3), + the trace at {-3-} is not displayed, indicating... + failure of the openFd call at {-2-}, also indicated by a Hugs error message, thus: [[ SpawnEchoShiftLetters> runTest wIn 3 Program error: openFd: does not exist (file does not exist) SpawnEchoShiftLetters> ]] Thus, it would appear that I'm misunderstanding how to use the openFd function that is part of the Hugs-supplied library code, declared as a primitive: [[ -- Creating a handle from a file descriptor/socket. -- primitive openFd :: Int -- file descriptor -> Bool -- True => it's a socket. -> IOMode -- what mode to open the handle in. -> Bool -- binary? -> IO Handle ]] -- http://cvs.haskell.org/cgi-bin/cvsweb.cgi/hugs98/libraries/Hugs/IO.hs?rev=1… Can anyone help me out here? My current experimental code is all visible at [4]. Thanks. #g -- [1] http://www.ninebynine.org/Software/HaskellUtils/Win32/SpawnEchoShiftLetters… [2] http://www.ninebynine.org/Software/HaskellUtils/Win32/SpawnEchoShiftLetters… [3] http://www.ninebynine.org/Software/HaskellUtils/Win32/spawnProc.c [4] http://www.ninebynine.org/Software/HaskellUtils/Win32/ ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

1 0

RE: [Haskell] New version of the HTTP module
by Simon Marlow 16 Mar '04

16 Mar '04

> > The modified HTTP module is available from: > > > > > http://www.dtek.chalmers.se/~d00bring/haskell-xml-rpc/http.html > > > > In line with Graham Klyne's suggestion [3] that a > > consistent version of > > this module be brought into some "community space", > > it will probably > > move to the haskell-libs project at SourceForge in > > the not too distant > > future. > > Is it possible to move the module to the network > package from the standard libraries > (fptools/libraries). There already exists modules for > CGI,Socket and URI. Possibly. In general we're moving to a more decentralised model for distributing libraries with the Library Infrastructure Project, but it may still be a while before that's stable. Guidelines for fptools/libraries are here: http://www.haskell.org/hierarchical-modules/libraries/libraries.html Parts of that document are out of date, but the "Reference Libraries" section is still relevant for the parts of fptools/libraries that we ship with compilers. Cheers, Simon

1 0