October 2003 - Libraries

RE: Calling an external command from a Haskell program
by Simon Marlow 22 Oct '03

22 Oct '03

> I've cc-ed to the libraries list - perhaps someone there could > comment on the state of portable replacements for Posix > functionality, especially for popen and friends? I seem to > recall a very promising discussion about portable and flexible > ways to start subprocesses a while ago - has that led to any > concrete libraries? Regarding processes, I made this proposal: http://www.haskell.org/pipermail/libraries/2003-May/000958.html but didn't get any further. The sticking point is that GHC needs a thread-safe wait() implementation, which means some hacking in the scheduler (there isn't even a good way to do this portably, because select() doesn't let you wait for process termination). Cheers, Simon

3 2

Re: Calling an external command from a Haskell program
by C.Reinke 21 Oct '03

21 Oct '03

> If you want access to its I/O streams as well, you can use > Posix.popen, which is not standard Haskell 98, I think, but it's > in GHC. Even worse, it is not portable (AFAICT)! I'm worried by the tendency towards Posix, at a time when, e.g., GHC by default no longer supports this on Windows (went missing in the move from cygwin to mingw). Some also thought Posix overkill, and wanted a portable replacement for the most-commonly-wanted functionality subset.. Could someone in the know please summarise the state of Posix-support in Haskell implementations in general? I've cc-ed to the libraries list - perhaps someone there could comment on the state of portable replacements for Posix functionality, especially for popen and friends? I seem to recall a very promising discussion about portable and flexible ways to start subprocesses a while ago - has that led to any concrete libraries? Cheers, Claus

1 0

RE: XML DTD for the package configuration file
by Simon Marlow 20 Oct '03

20 Oct '03

> Isaac will surely correct me in case I got this wrong, but I > thought the XML format is meant to be _one_ possible > representation of the Haskell data types, which constitute a > "package". If you prefer to write Haskell syntax, just do. > Dumping your data into an XML file takes _one_ function call > with HaXml. > > The important part is the _internal_ data format. Whether > these records are written to disk as XML, ATerm, RPM specs, > Gentoo ebuilds, or Microsoft Word documents does not matter. Absolutely. I don't think the storage format for the package configuration should receive any attention at all, unless library writers are expected to write package specs in that form, and it is my understanding that they're not (correct me if I'm wrong). The storage format for the package config is hidden behind the Distribution API, is it not? > Why is there so much excitement about this issue? :-) Because it is a bikeshed discussion http://www.unixguide.net/freebsd/faq/16.19.shtml Cheers, Simon

2 1

RE: implementation of file-related modules
by Simon Marlow 20 Oct '03

20 Oct '03

> I've been looking over some of the file-related modules such as > System.Directory and System.Posix.{Directory,Files}, and I have some > questions. My 2p: > * Some languages have a means of building paths in a portable way. It > would be nice if we had access a file separator (like "/" in unix > and "\" in windows). I've been against doing this in the past, because filename conventions differ so much between platforms (case sensitivity, length restrictions on components, syntax for drivenames, what is the meaning of consecutive pathname separators, etc.). However, there's clearly a need for some way to do simple pathname manipulations in a portable way. So my suggestion is to have something like: parentDirectory :: FilePath -> Mabye FilePath relativeToDirectory :: FilePath -> FilePath -> Maybe FilePath normaliseFilePath :: FilePath -> FilePath so you could say things like "my.conf" `relativeToDirectory` configDir It occurs to me that FilePath should be an abstract type. That would force the issue: we'd have to deal with all those existing cases which manipulate FilePaths and work out what abstractions we need. I don't like the idea of having a System.Directory.Native whose interface changes depending on the host platform. I think it's because platform-dependent APIs tend to lead to fine-grained #ifdefing in client code, and hence subtle portability problems. In libraries I try to stick to modules whose presence (only) depends on the platform, but there are definitely existing cases which violate this principle. > "path.separator" Path separator (for example, ":") looks like a bad idea to me: application dependent. > "file.separator" File separator (for example, "/") > "user.home" User home directory > "user.name" User account name > > // might come in useful: > "os.arch" Operating system architecture > "os.name" Operating system name > "os.version" Operating system version System.Info already provides these (except the version). > * Another item that would be useful in the System.Directory class > would be some kind of config file path. On Debian, that would be > "/etc", on some systems, it might tend to be more often > "/usr/local/etc". (I'm not sure if there's a good way to abstract > the difference between a user config file and a system config file. > User config files tend to be in ~/ and start with a dot whereas > system config files end up in /etc, and don't start with a dot.) The location of config files is something you want to specify via the build system. eg. ./configure --prefix=/opt should cause configuration files to be placed under /opt instead of the default location (/usr/local?). Which means that if the config file location were provided via a Haskell library, that library would have to consult an environment variable or something. ( looking through the followups, it looks like Ketil already mentioned this point). This just doesn't look like the right abstraction to me. I think it's better to let the build system (or library infrastructure) provide this kind of information, perhaps by auto-generating a module. Cheers, Simon

1 0

implementation of file-related modules
by Isaac Jones 20 Oct '03

20 Oct '03

Greetings, I've been looking over some of the file-related modules such as System.Directory and System.Posix.{Directory,Files}, and I have some questions. * Excuse my ignorance of Windows, but I'm assuming that the System.Posix module does not exist on Windows? Is windows the only system where this is the case? * I've noticed that System.Directory.renameFile behaves differently between ghci, nhc, and hugs. In particular, ghc is the only one who complains when it's a directory. Is there anything evil about using renameFile to rename a directory? It would be nice if they all acted the same, particularly since renameDirectory is conveniently located in the same module. * Speaking of which, in System.Posix, the Directory and File operations are broken up into separate modules. It is a little odd to have file related functions in System.Directory. Should they be moved? * Some languages have a means of building paths in a portable way. It would be nice if we had access a file separator (like "/" in unix and "\" in windows). These would probably belong in the System.Directory module? Java (for instance) allows access to these things through the java.lang.system.getProprerty function. That function takes a string and returns a string: "path.separator" Path separator (for example, ":") "file.separator" File separator (for example, "/") "user.home" User home directory "user.name" User account name // might come in useful: "os.arch" Operating system architecture "os.name" Operating system name "os.version" Operating system version Now using getProperty for this makes sense in Java, but for Haskell, I would expect to have functions for these. I'm not sure where all of them would go. Is there any roadblock to implementing something like this? * Another item that would be useful in the System.Directory class would be some kind of config file path. On Debian, that would be "/etc", on some systems, it might tend to be more often "/usr/local/etc". (I'm not sure if there's a good way to abstract the difference between a user config file and a system config file. User config files tend to be in ~/ and start with a dot whereas system config files end up in /etc, and don't start with a dot.) These last few points are rather related in that they are both dependent on particular operating systems, and a means of abstracting away system-specific details in order to write more portable code. Are any of these good ideas? peace, isaac

10 16

XML DTD for the package configuration file
by Isaac Jones 20 Oct '03

20 Oct '03

This is my first attempt at an XML DTD. Does anyone have any suggestions for good XML references either a book or a web site? Google seems to be suffering from too much XML information. Is there a Haddock / Javadoc type way to notate a DTD? Should I be using schemas? Are they overkill? What do you think of the style? Sometimes I have trouble choosing between using an attribute, and using a nested element. For instance: <envitem><var>x</var><val>y</val></envitem> verses <envitem var="x">y</envitem> Here's a shot at a DTD for the packages configuration file and an example config file that validates with the DTD (I used xmllint --noout --valid) and the Haskell datatype that it's meant to reflect. I expect it will change a lot as I learn more about XML and about packaging, but I wanted to get it out there in case I'm going horribly wrong somehow. I'm not really satisfied with the version stuff or the versionrange stuff (mostly the Haskell code). Slight background for people who know less about xml than me: a DTD is a means of verifying that an XML file has the correct structure. It seems rather limited in that there are no types, and the regular expressions are weaker than one might expect (I can't say "the data in this field should correspond to the following regexp). XML Schemas seem to fix some of these problems. But DTDs seem to be a nice way to document and share information about the format of an XML file. peace, isaac ------------------------------------------------------------ Packages.dtd ------------------------------------------------------------ -- CUT HERE -- <!ELEMENT packageconf (package+)> <!ATTLIST packageconf version CDATA #REQUIRED>  <!ELEMENT package (version?,importdirs?,sourcedirs?,librarydirs?,hslibraries?,extralibraries?,depends?,builddepends?,ccopts?,ldopts?,environment?,graftpoint?,extraframeworks?)> <!ATTLIST package version CDATA #IMPLIED> <!ATTLIST package name CDATA #REQUIRED> <!ATTLIST package auto (false | true) "false"> <!ELEMENT packageident (#PCDATA)>  <!ELEMENT filepath (#PCDATA)> <!ELEMENT sourcedirs (filepath+)> <!ELEMENT importdirs (filepath+)> <!ELEMENT librarydirs (filepath+)>  <!ELEMENT hslibraries (library+)> <!ELEMENT cincludes (include+)> <!ELEMENT extralibraries (library+)> <!ELEMENT library (#PCDATA)> <!ELEMENT include (#PCDATA)>  <!ELEMENT ccopts (option+)> <!ELEMENT ldopts (option+)> <!ELEMENT option (#PCDATA)> <!ATTLIST option type (short | long | verbatim) "verbatim">  <!ELEMENT builddepends (dependency+)> <!ELEMENT depends (dependency+)> <!ELEMENT dependency (versionrange?)> <!ATTLIST dependency name CDATA #REQUIRED> <!ATTLIST dependency version CDATA #IMPLIED>  <!ELEMENT haddockhtmlroot (#PCDATA)> <!ELEMENT haddockinterface (#PCDATA)>  <!ELEMENT versionrange (version,version?)>  <!ATTLIST versionrange type (any | orlater | exactly | orearlier | between) "orlater">   <!ELEMENT version (numberversion | simpleversion | dateversion)> <!ELEMENT numberversion (major?,minor?,patch?)> <!ELEMENT simpleversion (#PCDATA)> <!ELEMENT major (#PCDATA)> <!ELEMENT minor (#PCDATA)> <!ELEMENT patch (#PCDATA)> <!ELEMENT dateversion (year,month?,day?,patch?)> <!ELEMENT year (#PCDATA)> <!ELEMENT month (#PCDATA)> <!ELEMENT day (#PCDATA)>   <!ELEMENT environment (envitem+)> <!ELEMENT envitem (var,val)+> <!ELEMENT var (#PCDATA)> <!ELEMENT val (#PCDATA)>    <!ELEMENT graftpoint (#PCDATA)> <!ELEMENT extraframeworks (framework+)> <!ELEMENT framework (#PCDATA)> -- CUT HERE -- ------------------------------------------------------------ Packages.xml ------------------------------------------------------------ -- CUT HERE -- <?xml version="1.0"?> <!DOCTYPE packageconf SYSTEM "Packages.dtd"> <packageconf version="0.1"> <package name="packageName" version="1.0" auto="true"> <importdirs><filepath>/foo</filepath> <filepath>/foo/bar/bang</filepath></importdirs> <sourcedirs><filepath>/foo</filepath> <filepath>/foo/bar/bang</filepath></sourcedirs> <graftpoint>System.IO</graftpoint> </package>  <package name="dependExample" version="3"> <builddepends> <dependency name="otherPkg"> <versionrange type="exactly"> <version><simpleversion>3.4.5-6</simpleversion></version> </versionrange> </dependency> <dependency name="otherPkg2"> <versionrange type="orlater"> <version><dateversion><year>1998</year></dateversion></version> </versionrange> </dependency> <dependency name="otherPkg3" version="2.0.0-0" /> <dependency name="otherPkg3"> <versionrange type="between"> <version><simpleversion>3.3</simpleversion></version> <version><simpleversion>3.5</simpleversion></version> </versionrange> </dependency> </builddepends> </package>  <package name="optionExample"> <version><numberedversion><major>10</major> <minor>11</minor> <patch>12</patch></numberedversion></version> <ccopts> <option type="short">b</option> <option type="long">foo</option> <option type="verbatim">--bar</option> <option>--bang</option> </ccopts> <environment> <envitem><var>foo</var><val>bar</val></envitem> <envitem><var>bang</var><val>baz</val></envitem> </environment> </package> </packageconf> -- CUT HERE -- ------------------------------------------------------------ Package Config data structure ------------------------------------------------------------ -- CUT HERE -- data PkgIdentifier = PkgIdentifier {pkgName::String, pkgVersion::Version} {- ^Often need name and version since multiple versions of a single package can exist on a system. -} data PackageConfig = Package { pkgIdent :: PkgIdentifier, license :: License, auto :: Bool,        import_dirs :: [FilePath], source_dirs :: [FilePath], library_dirs :: [FilePath], include_dirs :: [FilePath], hs_libraries :: [String], extra_libraries :: [String], c_includes :: [String], build_deps :: [Dependency], -- build dependencies depends :: [Dependency], -- use dependencies  extra_cc_opts :: [String], extra_ld_opts :: [String], framework_dirs :: [String], haddock_html_root :: String, haddock_interface :: String, default_grafting_point :: String, -- ^Related to new packages proposal vars :: [(String, String)], -- ^Variable, value pairs, whatever author wants here extra_frameworks:: [String]} data Version = DateVersion {versionYear :: Integer, versionMonth :: Month, versionDay :: Integer} | NumberedVersion {versionMajor :: Integer, versionMinor :: Integer, versionPatchLevel :: Integer} data License = GPL | LGPL | BSD | {- ... | -} OtherLicense FilePath data Dependency = Dependency String VersionRange data VersionRange = AnyVersion | OrLaterVersion Version | ExactlyThisVersion Version | OrEarlierVersion Version type PackageMap = FiniteMap PkgIdentifier PackageConfig -- CUT HERE --

7 9

Re: XML DTD for the package configuration file
by Iavor Diatchki 16 Oct '03

16 Oct '03

hello, oh, nothing deep... very often though i find it that people argue that there are no reasons _not_ to use a certain technology (a coinductive argument so to speak :-), indicating perhaps that using the technology is more important than achieving the final goal. i myself do that quite often with technologoes that i like. i think however that perhaps the right way is to think about what would a certain technology contribute to a project and then argue for using it. on pretty much all occasions i've seen xml used (including this one) i have not been clear on what are the benefits of using it. as pointed out earlier it is not very well suited for humans, and one needs tools to make heads or tails of it. on the other hand it is hardly suitable for machines as the tools processing xml are not simple. and finally to move away from generalities: it would seem that the haskell libraries are intended for haskell programmers, that are likely to speak haskell, and have a haskell implemntation. however there might be haskell programmers out there that are not keen on learning xml, or installing xml tools (i am one such programmer). and even if the xml is somehow hidden within implementations and haskell programmers never see it (which i doubt is possible anyways) we should keep in mind that haskell implementations are already very complicated and requiring them to understand xml will not make them any simpler. bye iavor Isaac Jones wrote: > Hi Iavor, > > Could you follow up your post with an elaboration? I haven't seen > anyone post reasons NOT to use xml. I'm becoming very curious as to > why people are against it. > > peace, > > isaac > -- ================================================== | Iavor S. Diatchki, Ph.D. student | | Department of Computer Science and Engineering | | School of OGI at OHSU | | http://www.cse.ogi.edu/~diatchki | ==================================================

1 0

RE: XML DTD for the package configuration file
by Simon Peyton-Jones 16 Oct '03

16 Oct '03

As I understand it, XML Schema are the successor for DTDs. My guess is that we should use a Schema unless there's a good reason to use a DTD. Here's a snip from http://www.w3schools.com/schema/schema_intro.asp but I'm sure there are better sources of information: XML Schemas are the Successors of DTDs We think that very soon XML Schemas will be used in most Web applications as a replacement for DTDs. Here are some reasons: XML Schemas are extensible to future additions XML Schemas are richer and more useful than DTDs XML Schemas are written in XML XML Schemas support data types XML Schemas support namespaces Simon | -----Original Message----- | From: libraries-bounces(a)haskell.org [mailto:libraries-bounces@haskell.org] On Behalf Of Isaac Jones | Sent: 15 October 2003 05:55 | To: libraries | Subject: XML DTD for the package configuration file | | This is my first attempt at an XML DTD. Does anyone have any | suggestions for good XML references either a book or a web site? | Google seems to be suffering from too much XML information. Is there | a Haddock / Javadoc type way to notate a DTD? Should I be using | schemas? Are they overkill? What do you think of the style? | Sometimes I have trouble choosing between using an attribute, and | using a nested element. For instance:

7 7

Re: Cgi Library
by Thomas L. Bevan 15 Oct '03

15 Oct '03

If you are using the CGI library in GHC 6.0 I had problems with the functions pwrapper and connectToCGIScript. In their original form the request is buffered and does not get passed on to the server. I had to modify the source and turn all buffering off before it worked. Tom

1 0

ANNOUNCE: Cryptographic Library for Haskell
by Dominic Steinitz 11 Oct '03

11 Oct '03

I would like to annouce the second release of the Haskell Cryptographic Library (0.3.3). See http://www.haskell.org/crypto/ReadMe.html for more details. This library collects together existing Haskell cryptographic functions and augments them so that they: · Have common type signatures. · Can be used with the standard mode and padding algorithms (in the case of block mode ciphers). This release contains: · DES · Blowfish · Cipher Block Chaining (CBC) mode · PKCS5 and nulls padding · SHA-1 · RSA · OAEP Dominic Steinitz

1 0