March 2003 - Libraries

RE: Problem with hierarchical libraries.
by Simon Marlow 12 Mar '03

12 Mar '03

> > IIRC, something very similar was suggested a while back on > the libraries > > list, except that the form beginning with a dot was the > relative module > > name (actually I think I prefer it that way). > > this seems exactly the opposite of what all file systems do. i know > lateral thinking is great, but why do we have to be backwards > all the time? Because it seems strange to have to add the prefix dot to all of our existing imports ('import Prelude' becomes 'import .Prelude'). Besides, I like the idea that the prefix dot is an indication that the current module name has been omitted. > > Personally, I've been using the hierarchical module names > for a while > > and I really don't mind writing out the whole name each > time. It means > > you have less context to think about when reading the source. > oh come on :-) most of the time you don't get to see the > module name > at all -- you have to keep scrolling to the top of the file. > virtually > every editor can tell you what is the name of the file you are > editing... (:f in vim). and tools like haddoc can display > the name of > the module anyways. I think you misunderstand me - my point was that currently, an import declaration means the same regardless of what the current module name is. With relative imports, that's not true any more (but you're right that the editor usually helps by showing the filename). It's a minor point I grant you, but simplicity at the expense of a bit of extra typing is sometimes a good thing. > > This arises because the meaning of a module is defined > independently of > > the mapping between modules and filenames. > > the meaning of modules can still be independent of the > mapping between > modules and filesnames. all that has to be specified is how > to compute this mapping. And that's exactly what we don't want to do (IMO). Filesystems are too different - what about filesystems that don't have directories? What if I want to store my source code in a database or on the web? What about non-case-sensitive filesystems, or ones with restrictions on the length of filenames? > and one has to do that anyways, even if the haskell > report pretends that this can be ommited. Yes, but the point is that it is done by the compiler, not the language specification, so compilers are free to implement different policies, and the spec doesn't have to acquire any platform-specific warts. The mapping between filenames and module names in GHC is rather complicated, see recent discussions on glasgow-haskell-users(a)haskell.org. The mapping in Hugs is different - more liberal in some ways, but less complicated because of the lack of interface files. [snip] > in fact if one decides to ignore this mapping, > all that the "hirarchical modules" proposal does is allow one > to write "." in a module name. Bingo :-) Cheers, Simon

1 0

RE: documentation for Control.Monad.State
by Simon Marlow 12 Mar '03

12 Mar '03

> Here's a patch which adds some Haddock documentation to the > Control.Monad.State module. I collected examples together that I had > found useful when trying to understand this module, and haddock-ized > some of the comments that were already in the code. I also got > permission from the original authors to include these examples. > > The resulting haddock output can be seen here: > http://www.syntaxpolice.org/~ijones/tmp/Control.Monad.State.html > > Any comments before I commit this patch are welcome. I think moving the examples into a separate "Examples" section on that page would be better. As it is, the examples cause too much of a gap between the data types and their constructors. Cheers, Simon

1 0

RE: Problem with hierarchical libraries.
by Simon Marlow 11 Mar '03

11 Mar '03

[ moved to libraries(a)haskell.org ] > why not fix the design to take this into account? one can > have two ways > to refer to modules - relative and absolute (just like in the file > system, which years of experience show works pretty well). > > import .Test.A -- refers to an absolute path > -- (relative to a user specified root) > -- i.e. $HS_PATH/Test/A.hs > import Test.A -- is a path relative to the location of > -- the current module, i.e. > -- [location of module]/Test/A.hs IIRC, something very similar was suggested a while back on the libraries list, except that the form beginning with a dot was the relative module name (actually I think I prefer it that way). Personally, I've been using the hierarchical module names for a while and I really don't mind writing out the whole name each time. It means you have less context to think about when reading the source. > i also have another question about the hirarchical modules > design -- why > does one have to duplicate the path to a particular file > inside the file > itself? i.e. what is the point of the module name within the file? > it seems that all haskell implementations assume that the module name > and file name are the same (and this seems perfectly reasonable), and > with the hirarchical name space this is even more the case. and for > example C programers never specify the name of the current > file within > the file. why do we want to do it? This arises because the meaning of a module is defined independently of the mapping between modules and filenames. I agree that this leads to some redundancy, and it can be annoying that moving modules from one place in the hierarchy to another requires editing the source. Building knowledge of the filesystem into the spec is the wrong thing to do, given that filesystems tend to have platform-specific differences (eg. single quote is allowed in a module name - is it allowed in a filename? on which operating systems?). There are other approaches - perhaps defining a module as a pair of a module name and module text, where the compiler is free to infer the module name from other information it is supplied. But personally, I'm not convinced it's that big a problem. Cheers, Simon

2 1

documentation for Control.Monad.State
by Isaac Jones 11 Mar '03

11 Mar '03

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Here's a patch which adds some Haddock documentation to the Control.Monad.State module. I collected examples together that I had found useful when trying to understand this module, and haddock-ized some of the comments that were already in the code. I also got permission from the original authors to include these examples. The resulting haddock output can be seen here: http://www.syntaxpolice.org/~ijones/tmp/Control.Monad.State.html Any comments before I commit this patch are welcome. peace, isaac -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/> iD8DBQE+bf6HBLPTZ7K4MaIRAlcAAJ0e6O8g0ioHHFS0BgkP41uXjF8m8QCgop4N Vvrn8eliUnvyk2rOfUW0gwE= =i5Tb -----END PGP SIGNATURE-----

1 0

RE: Persistant (as in on disk) data
by Simon Marlow 11 Mar '03

11 Mar '03

> > I'm not convinced that the binary library should "natively" support > > cyclic data. I think that if saying: > > > > print x > > > > would not terminate, then there's no reason that > > > > puts bh x > > > > should terminate. I like to think of "puts" as a binary version of > > print. (That is, of course, unless the instance writer for the > > Binary/Show instances of the type of x is smart enough to not keep > > writing the same thing over and over again.) I would challenge the > > interested party to write a Show instance of String which > wouldn't loop > > indefinitely on "repeat 'x'". > well, it is your choice to think of it as you like, but this > is not what > my original mail was about. i think the ability to make data > persistant > is a useful one and it should be as transperant to the programmer as > possible. when i write something like: > ones = 1 : ones > > i don't think of "printing infinately many ones in memory" > and i don't see > why i should start thinking of it that way just because i > want to make the > object persistant. after all, one can think of the disk as a verys low > memory. Ok, it seems that you're really after persistence as opposed to just serialisation, which is what the Binary library provides. I'm not aware of any working implementations of this kind of persistence for current compilers, but it wouldn't be too much work to implement in GHC, as long as you don't mind the persistent data being only readable by particular binary that generated it, and refrain from any dynamic linking of Haskell code. Cheers, Simon

3 2

Re: hierarchical libraries
by Olaf Chitil 11 Mar '03

11 Mar '03

Simon Marlow wrote: > > > Currently the hierarchical library proposal > > http://www.haskell.org/~simonmar/libraries/libraries.html > > does not say much about the semantics of the hierarchical > > module names. > > It really should. > > I'm open to suggestions - in fact I thought the semantics were fairly > clear, but perhaps not? Or do you mean that the document should say > more about file names and searching policies? (that would be difficult > without getting compiler-specific). Simon, thinking a bit more about why I misunderstood the description, I realise how difficult it is to be more clear. I think the problem is not so much that something is missing, but that the association with file names and paths subconsciously suggests that you can do everything with hierarchical module names that you can do with file names. I'd suggest to move the two paragraphs in Section 3 about file structure into a separate subsection (3.1 File System) and add something along the following line: Note that the hierarchical module namespace is far simpler than a file directory structure, in that hierarchical module names do not provide any operations such as relative paths or parent directory. Olaf -- OLAF CHITIL, Dept. of Computer Science, The University of York, York YO10 5DD, UK. URL: http://www.cs.york.ac.uk/~olaf/ Tel: +44 1904 434756; Fax: +44 1904 432767

1 0

RE: Persistant (as in on disk) data
by Simon Peyton-Jones 11 Mar '03

11 Mar '03

| It seems to me that the only thing that is preventing such a library, is | agreement on the detail, as distinct from "persistence" of the form desired | by iavor, where it appears some experimentation will be required. I think that's right. | I am more than willing to document what appear to be the open issues and | work through this mail list to gain a consensus on them, with the goal at | hand: some document similar to the FFI addendum, provided, of course, there | is some support for this. It'd be a much smaller exercise than the FFI addendum, and perhaps best captured in the library documentation itself (a la Haddock perhaps) but no less desirable for that. Just enumerating the open issues and encouraging resolution would be a help. Simon

1 0

Re: Persistant (as in on disk) data
by mike V 11 Mar '03

11 Mar '03

>well, it is your choice to think of it as you like, but this is not what >my original mail was about. i think the ability to make data persistant >is a useful one and it should be as transperant to the programmer as >possible. when i write something like: I, on the other hand, believe that the original tact - serialisation as in "Show" - is a useful, necessary thing, and something that should be available across Haskell implementations. It seems to me that the only thing that is preventing such a library, is agreement on the detail, as distinct from "persistence" of the form desired by iavor, where it appears some experimentation will be required. I am more than willing to document what appear to be the open issues and work through this mail list to gain a consensus on them, with the goal at hand: some document similar to the FFI addendum, provided, of course, there is some support for this. Michael Vorin _________________________________________________________________ MSN Instant Messenger now available on Australian mobile phones. Go to http://ninemsn.com.au/mobilecentral/hotmail_messenger.asp

1 0

RE: Persistant (as in on disk) data
by Simon Peyton-Jones 09 Mar '03

09 Mar '03

| (c) how do we derive instances of Binary? If you guys can agree an interface that GHC, nhc and Hugs can all support, I'll gladly do the 'deriving' stuff to make 'deriving Binary' work for GHC. What's always inhibited me is that there isn't a single agreed interface. For most users, having a library that works across all Haskell implementations and platforms is much more important than having the most efficient possible library. But (the possibility of an) efficient implementation has to be a goal, just not the only goal. If GHC can't use it directly for interface files, so be it. Simon

4 3

RE: Persistant (as in on disk) data
by Simon Marlow 08 Mar '03

08 Mar '03

> > > i'd like to be able to dump data structures to disk, and > later load > > > them. > > > > A Binary library was discussed recently on the libraries list. > > I think the outstanding issues are ... > > > > (a) is the API for GHC's Binary library acceptable, or do we need > > the extra bells and whistles that the NHC version has? > > In particular, the NHC version is platform-independent with regard > to endian-ness issues, whereas I believe the GHC version is not? No, the GHC version *is* endian-independent. But it's not word-size independent, so moving a binary file from a machine with a 32-bit Int to a machine with a 64-bit Int won't work (unless you avoid Int and stick to fixed-size types and Integer). [snip] > > (c) how do we derive instances of Binary? > > The nhc98 compiler already accepts a `deriving Binary' clause. > DrIFT likewise already supports {-! derives : Binary !-}. I imagine > it wouldn't be too difficult to use GHC's support for Generics to code > up a simple deriving mechanism as well. > > > IMHO: something is better than nothing, so I'd be in favour of just > > plugging in the Binary library from GHC, and marking it > "experimental". > > Something I have never got round to asking before is what were the > perceived defects in the nhc98 Binary library that encouraged (a) Sven > to rewrite it for GHC, and (b) Simon to rewrite it again? >From my point of view, speed was the main driving factor. If Sven's library had worked, I guess I'd probably have started from that. I looked at it and didn't immediately understand it, so I started by throwing out everything from the API that I didn't need and then wrote an implementation of that, using bytes rather than bits on the assumption that the extra simplicity would yield better performace. Most of the changes I made to the API were for performance reasons. eg. using put_ instead of put enables tail-calls to kick in more often (and makes Binary instances slightly easier to write). I needed some laziness, but didn't need the full generality of getF and I was suspicious of its efficiency, so I wrote some more fine-grained lazy-reading operations in the IO monad instead. It would be nice if whatever Binary library we adopted for the hierarchical libraries could be used by GHC, but it's not essential. Since our goals are firmly focussed on performance, that might not fit with the prevailing demand from other users, so I'm agnostic about which Binary implementation gets used. It's more important to get *something* that people can use. Cheers, Simon

2 1