- Libraries - Haskell.org

System.Directory (was RE: Proposal for a new I/O library design)
by Hal Daume 28 Jul '03

28 Jul '03

Hi guys, I'm not replying to anything in the message, but... > Is the idea > to abstract away from the syntax of pathnames on the platform (eg. > directory separator characters)? If so, I'm not sure it's worthwhile. > There are lots of differences between pathname conventions: case > sensitivity, arbitrary limits on the lengh of filenames, filename > extensions, and so on. Would there be any way to get some of these differences into the System.Directory structure? At least the following would be nice: > pathSeparator :: Char > '\\' on Windows, '/' on unices, ':' (I believe) on macs, etc... > directorySeparator :: Char > ';' on Windows, ':' on unices, i have no idea on macs > isCaseSensitive :: Bool > False on Windows, True on (all?) unices, i have no idea on macs given just these, i think we'd all be a lot happier. I also don't particularly care whether these are IO operations or just values (so long as they are constant, they might as well be values with unsafePerformIO wrapped around them if necessary). My current approach to figuring this out is to create a directory, change to that directory, get the current path name and try to parse it. This is bad for so many reasons I won't enumerate them here. ...unless this stuff is hiding somewhere else, please let me know (but System.Directory would probably be a good place for it to end up)... - Hal

2 1

ENQUIRY
by MR. DAVID LARSON 25 Jul '03

25 Jul '03

FROM: MR. DAVID LARSON ANTHONY EZE & CO. SIR, SUBJECT: TRUST NEED YOUR KIND RESPONSE TO THE FOLLOWING REQUEST: I HAVE A MANDATE TO SOURCE FOR A FINANCIAL MANAGEMENT PERSONNEL ASIDE AFRICA, BE IT YOUR PROFFESSION OR NOT, ITS NATURE DOES NOT COUNT, BUT ONLY HONESTY IS NEEDED AT ITS PEAK AND WANTED AS MOST PRIORTY TO ACTUALIZE THIS EXPECTED GOAL. HAS CLOSE LINK WITH THE PERSONNELS IN THE CORRIDORS OF POWER IN MY COUNTRY HAS BEEN DELEGATED TO SOURCE FOR A COMPETENT ASSOCIATE OUTSIDE AFRICA IF YOU ARE WORTHY OF BEEN TRUSTED WITH HUGE CAPITAL FOR ESTABLISHMENT IN YOUR COUNTRY CONTACT ME FOR FULL PERSONAL SECRETIVE INFORMATION OR DETIALS FOR COMMENCEMENT AND TERMS OF REWARD FOR YOUR EXPERTED INTEREST AND CONTRIBUTION. THE VOLUME OF CAPITAL WILL BE DISCLOSED TO YOU ON MY RECEIPT OF YOUR RETURN CORRESPONDENCE INDICATING YOUR WILLINGNESS TO PER-TAKE. KINDLY RESPOND TO THIS MAIL INCLUDING YOUR PERSONAL CONTACT DATA'S FOR FULL DISCLOSURE OF PROCEEDURES. JUST WAITING FOR YOUR REVERT THANKS MR. DAVID LARSON

1 0

Packaging, and GUIs
by Simon Peyton-Jones 23 Jul '03

23 Jul '03

Dear Haskell library and GUI folk, Here's an interesting message from the Caml mailing list, largely focusing on a) packaging b) GUIs Interestingly, the very two topics on which we have active groups working! I wonder if it'd be a good time for a status report from both efforts? Both have been very quiet of late, but I see that Daan and Krasimir have both published new GUI libraries recently, so GUI stuff is still going on. Simon -----Original Message----- From: owner-caml-list(a)pauillac.inria.fr [mailto:owner-caml-list@pauillac.inria.fr] On Behalf Of Chris Clearwater Sent: 18 July 2003 22:21 To: caml-list(a)inria.fr Subject: [Caml-list] Roadplan for world domination (or constructive criticism of ocaml facilities) I have come across the Ocaml language several months ago and after much investigation and trial coding I have come to several conclusions. Most importantly I think Ocaml is a wonderful language to program in. It has all the features I would expect from a modern language and on top of that it's compiled native code appears to rival that of C in many areas. It truly is the language of the future. Now that I have expressed how much I am growing to love Ocaml I would like to share with you my initial experiences as a new user. First I would like to single out some issues that I believe threaten Ocaml from being taken seriously and then i would like to offer some solutions that would improve the usability of ocaml greatly. - Support on win32 could certainly be much better - Compiling and distributing Ocaml source is a very delicate process - There exists much fragmentation among usage of different GUI toolkits and they are limited to C/C++ conventions. (Is it possible to create your own custom GTK widgets within ocaml?) And without further ado I present to you 10 steps to world domination: 1) Support for Ocaml on win32 (both as a development and target enviroment) is very crucial for the adoption and practicality of Ocaml. For example, look at the trouble some developers must go through to get their application running under win32: http://groups.yahoo.com/group/unison-hackers/message/31. Forutnately this doesn't have to be the case. The mingw32 toolset allow compilation and linking to be done very similarily to how it is done on Unix. Also, it enables one to develop win32 apps without shelling out hundeds of dollars to Microsoft: http://msdn.microsoft.com/visualc/howtobuy/pricing.aspx I propose mingw32 be made the default compiler/linker for native win32 binaries (or even drop MSVC support entirely). 2) Take the idea of ocamlmklib further to generalize the compilation of both Ocaml programs and libraries into a module called "Ocamlmake". Also create a binary of ocamlmake which makes use of the module for command line compiling and include these in the standard distribution on all platforms. 3) Now that we have a easy cross-platform way to compile ocaml applications we can just distibute our code with Makefiles that call ocamlmake! WRONG. Makefiles suck. Now we standardize on the idea of an Ocaml "package". Each package would include in it's toplevel directory a file called setup.ml (This is starting to resemble python's distutils indeed). setup.ml would make use of the Ocamlmake module by building a record and passing it to Ocamlmake.setup. This record might be static or it might be created by self-configuration. For example, the ocamlsdl package would call sdl-config to retrieve some compilation flags. You _would_ rather configure in ocaml than "portable shell script", right? Then to build the application you would execute "ocamlrun setup.ml build" and "ocamlrun setup.ml install" to install it. Also the record would contain meta-information such as the author, copyright, etc. 4) Change the ocaml distribution to compile using Ocamlmake :) (except for bootstrapping if you dont already have a previous version of ocaml installed) 5) Create a module called Framebuffer which parallels the primtives found in OpenGL/DirectX. The Graphics module is close, but the design doesn't match well with these two APIs (We want hardware acceleration). Implement for each platform a Framebuffer module (DirectX or OpenGL where available, Xlib or other native graphics system otherwise). Include this in the standard distribution. 6) Create a cross-platform Event module. Include this in the standard distribution. 7) Create a cross-platform Font module (wrap freetype or create an Ocaml implementation). Include this in the standard distribution. 8) Create a GUI on top of the Framebuffer, Event, and Font modules, implemented in Ocaml :) Include this in the standard distribution. 9) Now the big payoff, we write a standard Ocaml IDE, to be included with the Ocaml distribution. It would be well integrated with the distribution. Ocamlmake module for compiling, the ocaml lexer for syntax highlighting, exporting packages (setup.ml). This would make it incredably easy to get started creating cross-platform libraries and modules. Realating to point #1, now a win32 user need only grab the mingw32 and Ocaml distributions and they are set. They can even easily export their code to a ocaml package for distribution. Obviously the benefit extends to all other platforms as well. 10) World domination. I would greatly appreciate any feedback. ------------------- To unsubscribe, mail caml-list-request(a)inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

2 1

Packaging
by Simon Peyton-Jones 23 Jul '03

23 Jul '03

Here's another thread on packaging from the OCaml mailing list: http://caml.inria.fr/archives/200307/msg00193.html (go to the thread to see more). I don't know what it has to contribute to our packaging discussion, but someone informed might want to mine it for useful ideas. Simon

1 0

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