July 2003 - Libraries

RE: FW: showing Handle is impure
by Simon Marlow 22 Jul '03

22 Jul '03

> I'm a little surprised that there always is a filename though > - I thought (but > haven't bothered to check) that Handles were used for > anything that can > contain a file descriptor: files, pipes, network connections, > etc. No big > deal but what is the output in these cases? (The file > descriptor number > suggests itself - immutable though not necessarily unique.) And one other point I just remembered: if we allow hDuplicateTo: hDuplicateTo :: Handle -> Handle -> IO () (which is currently available from GHC.Handle), then there is very little that is immutable in the Handle. In fact, even the "handle description" I talked about before is not really immutable, but it doesn't do much harm to consider it immutable. For example, if I say h <- openFile "/dev/null" hDuplicateTo h stdout print stdout should I get "/dev/null" or "<stdout>"? (currently GHC will say "<stdout>", because I'm treating the handle description as immutable). Cheers, Simon

1 0

RE: FW: showing Handle is impure
by Simon Marlow 22 Jul '03

22 Jul '03

> I share Alastair's concern about the possibility that a > handle may not always > contain a filename. I think it would be cleaner to assume > that the only immutable > part of a handle is its identity. And it is important that > the identity be shown (that is, as by `show`). First, on the filename: it was misleading of me to call it a filename. I should really have called it something like the "handle description" - it's just a string telling you something about the Handle. In the case of a Handle to a file, we use the filename for the description. For stdin, we use the string "<stdin>", for a socket we use the string "<socket: FD>" (where FD is the file descriptor). It's clearly useful to be able to display this stuff when showing a Handle. On Handle identities: yes, Handles have an identity, but in GHC's implementation there isn't a way to encode this identity as a String (because the identity is inherrent in the Handle's location in memory, and that location changes from time to time due to GC). We could embed another Integer identity in the Handle, but I'm not convinced it's that useful. If you want to get at the Handle identity, say for making a mapping from Handles, you can use StableNames (hey, a use for StableNames :-). Cheers, Simon

1 0

FW: showing Handle is impure
by Simon Marlow 21 Jul '03

21 Jul '03

Folks, Dean Herrington points out (see msg below from the ghc-bugs list) that GHC's instance of Show on Handles is incorrect because it is impure. This is because it includes parts of the Handle that are mutable, such as the buffering state. I've changed GHC's implementation so that it now displays just the filename from the Handle (this is the the only immutable part of the Handle). This raises another question though: should there be an IO operation for displaying the more interesting parts of a Handle? I propose: System.IO.hShow :: Handle -> IO String Comments? Cheers, Simon -----Original Message----- From: glasgow-haskell-bugs-admin(a)haskell.org [mailto:glasgow-haskell-bugs-admin@haskell.org] On Behalf Of Dean Herington Sent: 15 July 2003 19:35 To: glasgow-haskell-bugs(a)haskell.org Subject: showing Handle is impure The `shows` function for type `Handle` is inappropriately impure. In my opinion, showing a handle should merely identify it as a handle and distinguish it from other handles. The information currently provided by showing a handle should be provided with some other function; that function should be in the IO monad. swan(102)% ghci ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 5.04.3, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \____/\/ /_/\____/|_| Type :? for help. Loading package base ... linking ... done. Loading package haskell98 ... linking ... done. Prelude> :m IO Prelude IO> h <- openFile "/dev/null" ReadMode Prelude IO> h {loc=/dev/null,type=readable,binary=False,buffering=block (8192)} Prelude IO> c <- hGetContents h Prelude IO> h {closed} _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs(a)haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

3 2

basic haskell DistUtils
by Isaac Jones 16 Jul '03

16 Jul '03

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Greetings! For those interested in the LibraryInfrastructure project, I'd like you to take a look at some example source code I wrote (about 650 not completely beautiful lines) for a haskell-based build and install system: http://www.syntaxpolice.org/tmp/DistUtils-0.0.1.tgz BTW, I'm taking suggestions for the name of this project / module. This is a basic prototype for my vision of a pure haskell based system for building, installing, & packaging pure haskell stuff (like hunit, which is included as an example). This system will, in the future, act as a wrapper around a more complex build system (there are two such systems in the works). Hopefully "DistUtils" can provide extra targets, like bdist-deb, to such systems for free. What it does now is build stuff for ghc and make a distribution for Hugs. It can create a packages.conf file for ghc registration, and does something funny for hugs registration (see the README). I promise I'll make it do something for nhc soon. Commands for this version include "sdist" for a tarball, "install-hugs", "install-ghc", "register-ghc" etc. The library author will only have to provide information like [1], and DistUtils will do the rest. The module hierarchy is not exactly what I _want_ it to be. I really envision something more like [2]. I also envision the "ToolInfo" module to be merged with Ghc's Package module and hugs and nhc be made to use it (perhaps nhc already does). DistUtils also provides a means by which applications can easily add an --toolinfo flag so that other tools can interrogate executable programs (see the Example example). So in the long term, I see DistUtils as a module to each of the Haskell Implementations, including whatever /usr/bin/haskell is. Users can run ./Setup.lhs which will ask the compilers about themselves (or read packages.conf to get information about the compilers or maybe it'll use autoconf or something), then create possible targets based on the compilers and versions of available tools. Peter Simons seems to have a lot of ideas for building Haskell code, and some stuff can definitely be taken from HMake. Right now we just do some simple stuff. peace, isaac [1] - -- Setup.hs module Main where import DistUtils.Core import DistUtils.ToolInfo toolInfo = (basicPackage (OtherTool "DistUtils") (Version 0 0 1)) {haskellSources= map ("DistUtils/" ++) ["Info.hs", "Core.hs", "Compilers.hs", "ToolInfo.hs", "GhcPackage.hs" ], haskellMainMods=["Setup.lhs"], docs =["etc", "hugsWrap", "examples", "README"] } main :: IO () main = distUtilsMain toolInfo - ------------------------------------------------------------ [2] .distributionMain :: ToolInfo -> IO () -- implements standard functionality /Package .SystemConfig { installedPackages :: [Package], installedCompilers :: [Compiler], defaultCompiler :: Compiler } .getSystemConfig :: IO SystemConfig .defaultFlags (like --toolInfo) .emptyPackage .Package {depends :: [Package], buildDepends :: [Package], } .depends :: [Package] -> Graph Package .buildDepends :: [Package] -> Graph Package /Compiler .installedCompilers :: [Compiler] .defaultCompiler :: Compiler /Compilation .dependancies :: [HaskellModule] -> Graph HaskellModule .build :: Package -> Compiler -> IO () /Installation .install :: Package -> Compiler -> IO () .register :: Package -> Compiler -> IO () .export :: Package -> IO () --put the sources somewhere .sourceDist :: Package -> IO () -- make a tarball -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/> iD8DBQE/FGV/BLPTZ7K4MaIRAoB0AKCraBFr9IGzyF3329oCY3oeX7VZaQCfTxlV 6D1zX9yhNsk/TUIza3h3H3w= =lj7M -----END PGP SIGNATURE-----

2 2

Re: some bugs in Language.Haskell.Parser
by Hal Daume III 13 Jul '03

13 Jul '03

> Message: 2 > Date: Sun, 13 Jul 2003 12:52:40 +0100 > To: libraries(a)haskell.org > Subject: Re: some bugs in Language.Haskell.Parser > From: Ross Paterson <ross(a)soi.city.ac.uk> > > > this gives a parse error because it's waiting for a real declaration > > inside of the first where clause. > > Thanks for the report. All these are due to the implementation of layout > omitting the rule about inserting empty braces (now fixed in CVS). No problem :). > > it also can't deal with empty statements: > > > > > v = do {return 'a';;} > > > > should be accepted but results in a parser error. > > This isn't Haskell. I think you're right :). GHC accepts it, Hugs does not: 10:21am moussor:~/ cat > Foo.hs main = do {putStrLn "Hi";;} 10:21am moussor:~/ ghc Foo.hs 10:21am moussor:~/ ./a.out Hi 10:21am moussor:~/ hugs Foo.hs __ __ __ __ ____ ___ _________________________________________ || || || || || || ||__ Hugs 98: Based on the Haskell 98 standard ||___|| ||__|| ||__|| __|| Copyright (c) 1994-2001 ||---|| ___|| World Wide Web: http://haskell.org/hugs || || Report bugs to: hugs-bugs(a)haskell.org || || Version: December 2001 _________________________________________ Haskell 98 mode: Restart with command line option -98 to enable extensions Reading file "/nfs/moussor/hdaume/share/hugs/lib/Prelude.hs": Reading file "Foo.hs": Parsing ERROR "Foo.hs":1 - Syntax error in definition (unexpected `;', possibly due to b ad layout) I think GHC is in error here. According to the report: 3.14 Do Expressions exp -> do { stmts } (do expression) stmts -> stmt1 ... stmtn exp [;] (n>=0) stmt -> exp ; | pat <- exp ; | let decls ; | ; (empty statement) There's clearly no final exp in the stmts. That's what I get for trusting GHC too much :) - Hal

1 0

some bugs in Language.Haskell.Parser
by Hal Daume 13 Jul '03

13 Jul '03

The program: > x = v where v = 2 where > > main = putStrLn "hello world" parses as: > x = v > where v = 2 > main = putStrLn "hello world" which is incorrect. (in general, the parser can't deal with empty where clauses) as in: > x = 'a' where > class A a where this gives a parse error because it's waiting for a real declaration inside of the first where clause. it also can't deal with empty statements: > v = do {return 'a';;} should be accepted but results in a parser error. in Parser.ly, this essentially boils down to the fact that 'decllist' must be nonempty, but in certain circumstances (all?), it really *can* be empty. the last error (with statements), can be fixed by replacing line 637-639: > stmtlist :: { [HsStmt] } > : '{' stmts '}' { $2 } > | open stmts close { $2 } with: > stmtlist :: { [HsStmt] } > : '{' stmts optsemis '}' { $2 } > | open stmts optsemis close { $2 } i believe. - Hal -- Hal Daume III | hdaume(a)isi.edu "Arrest this man, he talks in maths." | www.isi.edu/~hdaume

2 1

A question about ParseC library
by Yu Di 12 Jul '03

12 Jul '03

Hi, I want to have a parser like: p = do eof return something <|> do patternA update_parser_state p <|> do patternB update_parser_state_in_another_way p <|> do anyToken p i.e., go through the content, if pattern A occurs, update my internal state, if pattern B occurs, update the state in another way. Also, the exact forms of pattern A and pattern B might be dependent on the internal state at that time (e.g., whenever I encount pattern A, I increase a counter in my internal state, and that counter is included in pattern B). Finally, when I reach the end, I will then return something based on the final internal state. I did it in the above recursive fashion, but when I ran it, it caused a stack overflow error. So what is the best way to do this kind of parsing? Thanks! Di, Yu 7.11 __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com

2 1

RE: Reading/Writing Binary Data in Haskell
by Simon Peyton-Jones 09 Jul '03

09 Jul '03

A library for reading and writing binary data, portable across both implementations and platforms, has been a long-standing lack. It comes up regularly, and has been discussed recently on the libraries list (libraries(a)haskell.org) Most recently George Russell posted a library, but I don't know it's portability http://haskell.org/pipermail/libraries/2003-June/001227.html There seem to be two slightly different issues: a) writing Haskell data structures to a file, so they can be recovered (exact binary structure of the file is irrelevant) b) reading and writing files whose exact binary structure is specified but presumably much of the infrastructure for both purposes would be the same. The way stands open for someone to take up the challenge: define an interface, agree it with the community, and build an implementation that works. Maybe someone is doing this already? Perhaps George's library is intended to be such a thing? Anyway, it would be a great service. Simon | -----Original Message----- | From: haskell-admin(a)haskell.org [mailto:haskell-admin@haskell.org] On Behalf Of Wolfgang Jeltsch | Sent: 09 July 2003 09:21 | To: The Haskell Mailing List | Subject: Re: Reading/Writing Binary Data in Haskell | | On Wednesday, 2003-07-09, 05:31, Glynn Clements wrote: | > [...] | | > There isn't a standard mechanism for binary I/O. | | NHC98 contains the York Binary library. Can someone tell me if this is | available for other Haskell systems? And didn't GHC also provide binary I/O? | | > However, a simple and fairly generic mechanism for doing this is: | > | > 1. Read in a list of "Char"s with the standard I/O functions. | | This will most likely cause problems under Windows. The reason is that the | standard I/O functions are intended for reading and writing text, and that's | why under Windows the sequence CRLF (#0D#0A) is interpreted as a single LF | (#0A) and EOF (#1A) is interpreted as the end of the file. | | > 2. Use "map (fromIntegral . ord) ..." to get a list of "Word8"s (octets). | | This assumes that the standard I/O functions use a one byte character | encoding. I don't now whether this is guaranteed by the Haskell report. | | > [...] | | Wolfgang | | _______________________________________________ | Haskell mailing list | Haskell(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell

1 0

Re: Movie
by L-Soft list server at Sun Microsystems Inc. (1.8d) 08 Jul '03

08 Jul '03

> Please see the attached zip file for details. Unknown command - "PLEASE". Try HELP. Summary of resource utilization ------------------------------- CPU time: 0.000 sec Overhead CPU: 0.000 sec CPU model: sun4u Job origin: libraries(a)HASKELL.ORG

1 0

HGL
by John Meacham 08 Jul '03

08 Jul '03

using HGL, I notice that there does not appear to be a way to get at the rendered size of text strings. this makes it very difficult to work with text in any meaningful way. although perhaps i am missing something. John -- --------------------------------------------------------------------------- John Meacham - California Institute of Technology, Alum. - john(a)foo.net ---------------------------------------------------------------------------

2 3