April 2001 - Libraries

Re: Dimensional analysis with fundeps (some physics comments)
by Ashley Yakeley 10 Apr '01

10 Apr '01

I'm cross-posting this to the Libraries list... At 2001-04-10 18:02, Fergus Henderson wrote: >Still, the need to insert explicit `toUnits' is >annoying, and it would be nice to have a system where every number was >already a dimensionless unit. That's easy: -- type Unit rep = Dimensioned Zero Zero Zero rep; instance (Real a) => Real (Unit a) where { -- put instances here }; -- Of course you'll have to appropriately declare superclasses of Real, such as Num, Ord, Show, Eq etc. -- Ashley Yakeley, Seattle WA

3 2

Dimensions
by Ashley Yakeley 10 Apr '01

10 Apr '01

This builds on anatoli's work. -- Ashley Yakeley, Seattle WA

1 0

Re: Dimensional analysis with fundeps (some physics comments)
by Ashley Yakeley 10 Apr '01

10 Apr '01

At 2001-05-01 18:28, Terrence Brannon wrote: >"has Ashley >shown in her example a means of automating a toUnits imperative in >Haskell that must be done explicitly in Mercury?" ...his... -- Ashley Yakeley, Seattle WA

1 0

RE: FW: lazy file reading in H98
by Simon Peyton-Jones 09 Apr '01

09 Apr '01

I'm working on this text right now. Check out http://research.microsoft.com/~simonpj/tmp/haskell98-library-html/ and see if you think it's improved Simon | -----Original Message----- | From: Malcolm Wallace [mailto:Malcolm.Wallace@cs.york.ac.uk] | Sent: 03 April 2001 17:04 | To: libraries(a)haskell.org | Subject: Re: FW: lazy file reading in H98 | | | > (1) At least, the definition should say that the behaviour | > is undefined if a program ever writes to a file that it | > has read with `readFile' or `hGetContents' before. | | The Library Report is already stronger than this. The | behaviour is fully defined: an error should be raised. | Here's what it says: | | > Implementations should enforce as far as possible, locally | to the Haskell | > process, multiple-reader single-writer locking on files. | ... If any | > open or semi-closed handle is managing a file for input, | new handles | > can only be allocated if they do not manage output. | > ... | > Error reporting: the openFile computation may fail with | > isAlreadyInUseError if the file is already open and cannot be | > reopened. | | The only very slightly confusing aspect is that the handles | used by "readFile" and "writeFile" are internal, not written | directly by the programmer. Perhaps the description of this | behaviour should be moved up from the 11.3.1 "Opening Files" | subsection to the enclosing 11.3 section, because it is more | generally applicable. | | Subsection 11.2.1 "Semi-closed Handles" should mention | "readFile" in addition to "hGetContents". It could also | explicitly refer to the multiple-reader single-writer | restriction, which is not otherwise mentioned here. | | Regards, | Malcolm | | _______________________________________________ | Libraries mailing list | Libraries(a)haskell.org | http://www.haskell.org/mailman/listinfo/libraries |

3 4

RE: FW: lazy file reading in H98
by Simon Peyton-Jones 09 Apr '01

09 Apr '01

| Simon doesn't want to make changes to Haskell. My opinion is | that the current definition of readFile and hGetContents is | fine. They are useful when used with a bit of care. Some | remarks should make the reader of the report aware of the | caveats. (I'm not saying that I couldn't imagine some useful | additional functions for lazy reading and writing.) That's exactly what I think. The current IO libraries are far from perfect, but what I want to do in the H98 Report is simply to document clearly what they do and don't do. Improving them is a job for the Libraries group, and I hope we'll take up the challenge. Simon

1 0

RE: FW: lazy file reading in H98
by Simon Marlow 03 Apr '01

03 Apr '01

> > (1) At least, the definition should say that the behaviour > > is undefined if a program ever writes to a file that it > > has read with `readFile' or `hGetContents' before. > > The Library Report is already stronger than this. Yes, but the behaviour specified by the report isn't exactly useful. The problem is that a semi-closed handle becomes fully closed at some random point in the future, when the list returned from readFile is fully evaluated. In order to make sure that a subsequent writeFile won't fail due to a locking violation, you have to fully force the string returned from readFile. Incedentally, nhc98 doesn't seem to implement the locking (perhaps this is a known bug, I didn't check). Cheers, Simon

2 1

FW: lazy file reading in H98
by Simon Peyton-Jones 03 Apr '01

03 Apr '01

Here's a library issue. The conclusion of this conversation was that H98 already specifies option (1) below, and I will clarify that in revising the library report. Nevertheless, the absence of a simple way to read-modify-write a file is a pain in the neck. Question: should one of our extended-IO libraries support a version of openFile that guarantees option (2)? Simon -----Original Message----- From: Manuel M. T. Chakravarty [mailto:chak@cse.unsw.edu.au] Sent: 05 September 2000 02:10 To: haskell(a)haskell.org Subject: lazy file reading in H98 In an assignment, in my class, we came across a lack of specification of the behaviour of `Prelude.readFile' and `IO.hGetContents' and IMHO also a lack of functionality. As both operations read a file lazily, subsequent writes to the same file are potentially disastrous. In this assignment, the file was used to make a Haskell data structure persistent over multiple runs of the program - ie, readFile fname >>= return . read at the start of the program and writeFile fname . show at the end of the program. For certain inputs, where the data structure stored in the file was only partially used, the file was overwritten before it was fully read. H98 doesn't really specify what happens in this situation. I think, there are two ways to solve that: (1) At least, the definition should say that the behaviour is undefined if a program every writes to a file that it has read with `readFile' or `hGetContents' before. (2) Alternatively, it could demand more sophistication from the implementation and require that upon opening of a file for writing that is currently semi-closed, the implementation has to make sure that the contents of the semi-closed file is not corrupted before it is fully read.[1] In the case that solution (1) is chosen, I think, we should also have something like `strictReadFile' (and `hStrictGetContents') which reads the whole file before proceeding to the next IO action. Otherwise, in situations like in the mentioned assignment, you have to resort to reading the file character by character, which seems very awkward. So, overall, I think solution (2) is more elegant. Cheers, Manuel [1] On Unix-like (POSIX?) systems, unlinking the file and then opening the writable file would be sufficient. On certain legacy OSes, the implementation would have to read the rest of the file into memory before creating a new file under the same name.

2 1

RE: lazy file reading in H98
by Simon Marlow 03 Apr '01

03 Apr '01

I admit the existing behaviour is unsatisfactory. However, I'd like to point out that a program using the sequence s <- readFile f ... writeFile f s' is arguably wrong, even given semantics (2) for readFile, becuase it's non-atomic. A more correct sequence is s <- readFile f ... writeFile f' s' renameFile f' f where f' is a temporary file name. Cheers, Simon > -----Original Message----- > From: Simon Peyton-Jones > Sent: Tuesday, April 03, 2001 12:01 PM > To: Libraries for Haskell List > Subject: FW: lazy file reading in H98 > > > Here's a library issue. > > The conclusion of this conversation was that H98 already specifies > option (1) below, and I will clarify that in revising the library > report. > Nevertheless, the absence of a simple way to read-modify-write a file > is a pain in the neck. > > Question: should one of our extended-IO libraries support a version of > openFile that guarantees option (2)? > > Simon > > -----Original Message----- > From: Manuel M. T. Chakravarty [mailto:chak@cse.unsw.edu.au] > Sent: 05 September 2000 02:10 > To: haskell(a)haskell.org > Subject: lazy file reading in H98 > > > In an assignment, in my class, we came across a lack of > specification of > the behaviour of `Prelude.readFile' and `IO.hGetContents' and > IMHO also > a lack of functionality. As both operations read a file lazily, > subsequent writes to the same file are potentially > disastrous. In this > assignment, the file was used to make a Haskell data structure > persistent over multiple runs of the program - ie, > > readFile fname >>= return . read > > at the start of the program and > > writeFile fname . show > > at the end of the program. For certain inputs, where the > data structure stored in the file was only partially used, > the file was overwritten before it was fully read. > > H98 doesn't really specify what happens in this situation. > I think, there are two ways to solve that: > > (1) At least, the definition should say that the behaviour > is undefined if a program every writes to a file that it > has read with `readFile' or `hGetContents' before. > > (2) Alternatively, it could demand more sophistication from > the implementation and require that upon opening of a > file for writing that is currently semi-closed, the > implementation has to make sure that the contents of the > semi-closed file is not corrupted before it is fully > read.[1] > > In the case that solution (1) is chosen, I think, we should also have > something like `strictReadFile' (and > `hStrictGetContents') which reads the whole file before proceeding to > the next IO action. Otherwise, in situations like in the mentioned > assignment, you have to resort to reading the file character by > character, which seems very awkward. > > So, overall, I think solution (2) is more elegant. > > Cheers, > Manuel > > [1] On Unix-like (POSIX?) systems, unlinking the file and > then opening the writable file would be sufficient. On > certain legacy OSes, the implementation would have to > read the rest of the file into memory before creating > a new file under the same name. > > _______________________________________________ > Libraries mailing list > Libraries(a)haskell.org > http://www.haskell.org/mailman/listinfo/libraries >

1 0

RE: Haskell-Java Bridge?
by Simon Peyton-Jones 03 Apr '01

03 Apr '01

Erik Meijer and Sigbjorn Finne built Lambada some while ago http://www.dcs.gla.ac.uk/mail-www/haskell/msg02391.html I honestly don't know what state it's in. Simon | -----Original Message----- | From: Ashley Yakeley [mailto:ashley@semantic.org] | Sent: 03 April 2001 05:48 | To: Libraries for Haskell List | Subject: Haskell-Java Bridge? | | | Has anyone done any work on creating an FFI bridge from | Haskell to Java | via JNI? I'm not talking about compiling Haskell to Java | bytecode, merely | the ability to call the Java VM from Haskell. | | Two points in Java's favour: | | 1. Platform Ubiquity. You can find Java VMs for a wide range | of platforms. | | 2. Java provides a wide range of functionality including GUI, | network, | file access, SQL, etc., etc. | | Contrary to popular belief, it is straightforward to create | and use Java | classes at run-time from the list of bytes that make up the class. | | -- | Ashley Yakeley, Seattle WA | | | _______________________________________________ | Libraries mailing list | Libraries(a)haskell.org | http://www.haskell.org/mailman/listinfo/libraries |

1 0

Haskell-Java Bridge?
by Ashley Yakeley 03 Apr '01

03 Apr '01

Has anyone done any work on creating an FFI bridge from Haskell to Java via JNI? I'm not talking about compiling Haskell to Java bytecode, merely the ability to call the Java VM from Haskell. Two points in Java's favour: 1. Platform Ubiquity. You can find Java VMs for a wide range of platforms. 2. Java provides a wide range of functionality including GUI, network, file access, SQL, etc., etc. Contrary to popular belief, it is straightforward to create and use Java classes at run-time from the list of bytes that make up the class. -- Ashley Yakeley, Seattle WA

1 0