- Libraries - Haskell.org

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

RE: version control and LIP
by Simon Marlow 15 Mar '04

15 Mar '04

> >The original question was whether to move the LIP repository > to CVS or > >keep it in an arch repository, or use something else. This seems to > >have lead on to the question of whether the whole of fptools > should move > >to a new VC system. > > > >My opinion: I hate CVS, but I don't think we should switch at this > >stage. The main problems in CVS that affect us every day are: > > > > - lack of support for versioning of directories (I'd like to > > rearrange bits of the tree, but find that the fact that we'd > > lose history means it isn't worth it). > > > > > > This can be done in CVS. (I'm not a CVS fan, but that is > neither here > nor there.) CVS can't do it automatically. However, you can easily > move the RCS files and in this manner change the directory > structure. > What you lose is any history of the directory operations themselves. > But it is possible to move files. Yes, I'm aware of this. If you move the RCS file, then you lose the ability to check out the tree at an earlier date. You have to copy the RCS file, and then edit the copy to mark all the old revisions as "dead", thus keeping the history and allowing checkouts of old trees. One gets the feeling that this isn't a well-supported feature ;-p Cheers, Simon

2 1