From ashley@semantic.org Tue Apr 3 05:47:39 2001
Date: Mon, 2 Apr 2001 21:47:39 -0700
From: Ashley Yakeley ashley@semantic.org
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
From simonpj@microsoft.com Tue Apr 3 09:04:04 2001
Date: Tue, 3 Apr 2001 01:04:04 -0700
From: Simon Peyton-Jones simonpj@microsoft.com
Subject: Haskell-Java Bridge?
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]=20
| Sent: 03 April 2001 05:48
| To: Libraries for Haskell List
| Subject: Haskell-Java Bridge?
|=20
|=20
| Has anyone done any work on creating an FFI bridge from=20
| Haskell to Java=20
| via JNI? I'm not talking about compiling Haskell to Java=20
| bytecode, merely=20
| the ability to call the Java VM from Haskell.
|=20
| Two points in Java's favour:
|=20
| 1. Platform Ubiquity. You can find Java VMs for a wide range=20
| of platforms.
|=20
| 2. Java provides a wide range of functionality including GUI,=20
| network,=20
| file access, SQL, etc., etc.
|=20
| Contrary to popular belief, it is straightforward to create=20
| and use Java=20
| classes at run-time from the list of bytes that make up the class.
|=20
| --=20
| Ashley Yakeley, Seattle WA
|=20
|=20
| _______________________________________________
| Libraries mailing list
| Libraries@haskell.org=20
| http://www.haskell.org/mailman/listinfo/libraries
|=20
From simonpj@microsoft.com Tue Apr 3 12:00:55 2001
Date: Tue, 3 Apr 2001 04:00:55 -0700
From: Simon Peyton-Jones simonpj@microsoft.com
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.=20
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]=20
Sent: 05 September 2000 02:10
To: haskell@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,=20
readFile fname >>=3D 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.
From simonmar@microsoft.com Tue Apr 3 16:29:00 2001
Date: Tue, 3 Apr 2001 16:29:00 +0100
From: Simon Marlow simonmar@microsoft.com
Subject: lazy file reading in H98
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=20
> Sent: Tuesday, April 03, 2001 12:01 PM
> To: Libraries for Haskell List
> Subject: FW: lazy file reading in H98
>=20
>=20
> Here's a library issue.
>=20
> 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.=20
>=20
> Question: should one of our extended-IO libraries support a version of
> openFile that guarantees option (2)?
>=20
> Simon
>=20
> -----Original Message-----
> From: Manuel M. T. Chakravarty [mailto:chak@cse.unsw.edu.au]=20
> Sent: 05 September 2000 02:10
> To: haskell@haskell.org
> Subject: lazy file reading in H98
>=20
>=20
> In an assignment, in my class, we came across a lack of=20
> specification of
> the behaviour of `Prelude.readFile' and `IO.hGetContents' and=20
> IMHO also
> a lack of functionality. As both operations read a file lazily,
> subsequent writes to the same file are potentially=20
> disastrous. In this
> assignment, the file was used to make a Haskell data structure
> persistent over multiple runs of the program - ie,=20
>=20
> readFile fname >>=3D return . read
>=20
> at the start of the program and
>=20
> writeFile fname . show
>=20
> 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.
>=20
> H98 doesn't really specify what happens in this situation.
> I think, there are two ways to solve that:
>=20
> (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.
>=20
> (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]
>=20
> 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.
>=20
> So, overall, I think solution (2) is more elegant.
>=20
> Cheers,
> Manuel
>=20
> [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.
>=20
> _______________________________________________
> Libraries mailing list
> Libraries@haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>=20
From Malcolm.Wallace@cs.york.ac.uk Tue Apr 3 17:04:07 2001
Date: Tue, 3 Apr 2001 17:04:07 +0100
From: Malcolm Wallace Malcolm.Wallace@cs.york.ac.uk
Subject: 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
From simonmar@microsoft.com Tue Apr 3 17:21:24 2001
Date: Tue, 3 Apr 2001 17:21:24 +0100
From: Simon Marlow simonmar@microsoft.com
Subject: 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.
>=20
> 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
From Malcolm.Wallace@cs.york.ac.uk Tue Apr 3 17:32:16 2001
Date: Tue, 3 Apr 2001 17:32:16 +0100
From: Malcolm Wallace Malcolm.Wallace@cs.york.ac.uk
Subject: FW: lazy file reading in H98
> Yes, but the behaviour specified by the report isn't exactly useful.
I know, but making the definition less defined than at present won't
help much either.
> Incidentally, nhc98 doesn't seem to implement the locking (perhaps this
> is a known bug, I didn't check).
Yes, nhc98 doesn't currently implement file locking. I regard
this as non-conformance to the standard, rather than a bug as such.
We just never got round to implementing it yet.
Regards,
Malcolm
From simonpj@microsoft.com Wed Apr 4 15:36:30 2001
Date: Wed, 4 Apr 2001 07:36:30 -0700
From: Simon Peyton-Jones simonpj@microsoft.com
Subject: FW: lazy file reading in H98
I'm working on this text right now. Check out
=09
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]=20
| Sent: 03 April 2001 17:04
| To: libraries@haskell.org
| Subject: Re: FW: lazy file reading in H98
|=20
|=20
| > (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.
|=20
| The Library Report is already stronger than this. The=20
| behaviour is fully defined: an error should be raised. =20
| Here's what it says:
|=20
| > Implementations should enforce as far as possible, locally=20
| to the Haskell
| > process, multiple-reader single-writer locking on files. =20
| ... If any
| > open or semi-closed handle is managing a file for input,=20
| new handles=20
| > can only be allocated if they do not manage output.
| > ...
| > Error reporting: the openFile computation may fail with=20
| > isAlreadyInUseError if the file is already open and cannot be=20
| > reopened.
|=20
| The only very slightly confusing aspect is that the handles=20
| used by "readFile" and "writeFile" are internal, not written=20
| directly by the programmer. Perhaps the description of this=20
| behaviour should be moved up from the 11.3.1 "Opening Files"=20
| subsection to the enclosing 11.3 section, because it is more=20
| generally applicable.
|=20
| Subsection 11.2.1 "Semi-closed Handles" should mention=20
| "readFile" in addition to "hGetContents". It could also=20
| explicitly refer to the multiple-reader single-writer=20
| restriction, which is not otherwise mentioned here.
|=20
| Regards,
| Malcolm
|=20
| _______________________________________________
| Libraries mailing list
| Libraries@haskell.org=20
| http://www.haskell.org/mailman/listinfo/libraries
|=20
From olaf@cs.york.ac.uk Sat Apr 7 20:35:52 2001
Date: Sat, 07 Apr 2001 20:35:52 +0100
From: Olaf Chitil olaf@cs.york.ac.uk
Subject: 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.
This restriction would be too harsh. It is desirable to be able to write
to a file that has been read before with `readFile' or `hGetContents'.
With hGetContents you can do this safely:
do
handle <- openFile "configuration" ReadMode
contents <- hGetContents
...
hClose handle
writeFile "configuration" newContents
At the point where you write newContents, you should no longer be
interested in contents. Either, because you are at the end of the
program execution anyway (as in Manuel's example), or because you
checked that you could parse the contents and hence processed the whole
contents, e.g.:
...
case parse contents of
Nothing -> error "corrupted file format"
Just info -> ...
I would think that the later case is very common and then you do not
even have to use `hClose'. However, I would prefer to do so and it is
unfortunate that you cannot when you use `readFile'.
Maybe these points should be mentioned in the report.
Another point: I had difficulties parsing the following sentence of
Section 11.2.2 on first reading:
Any operation except for hClose that fails because a handle is closed,
also fails if a handle is semi-closed.
Alternatives:
Any operation (except for hClose) that fails because a handle is closed,
also fails if a handle is semi-closed.
Any operation that fails because a handle is closed, also fails if a
handle is semi-closed. The only exception is hClose.
Olaf
--
OLAF CHITIL,
Dept. of Computer Science, University of York, York YO10 5DD, UK.
URL: http://www.cs.york.ac.uk/~olaf/
Tel: +44 1904 434756; Fax: +44 1904 432767
From qrczak@knm.org.pl Sat Apr 7 22:09:26 2001
Date: 7 Apr 2001 21:09:26 GMT
From: Marcin 'Qrczak' Kowalczyk qrczak@knm.org.pl
Subject: FW: lazy file reading in H98
Sat, 07 Apr 2001 20:35:52 +0100, Olaf Chitil <olaf@cs.york.ac.uk> pisze:
> do
> handle <- openFile "configuration" ReadMode
> contents <- hGetContents
> ...
> hClose handle
> writeFile "configuration" newContents
It will be wrong if the contents is not fully evaluated at the point
of hClose.
Perhaps hClose should arrange to performGC and suck the rest of the
file if it's still needed.
--
__("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTĘPCZA
QRCZAK
From olaf@cs.york.ac.uk Sun Apr 8 19:12:10 2001
Date: Sun, 08 Apr 2001 19:12:10 +0100
From: Olaf Chitil olaf@cs.york.ac.uk
Subject: FW: lazy file reading in H98
Marcin 'Qrczak' Kowalczyk wrote:
>
> Sat, 07 Apr 2001 20:35:52 +0100, Olaf Chitil <olaf@cs.york.ac.uk> pisze:
>
> > do
> > handle <- openFile "configuration" ReadMode
> > contents <- hGetContents
> > ...
> > hClose handle
> > writeFile "configuration" newContents
>
> It will be wrong if the contents is not fully evaluated at the point
> of hClose.
What do you mean by `wrong'? As 11.2.2 says:
Once a semi-closed handle becomes closed, the contents of the associated
stream becomes fixed, and is the list of those items which were
successfully read from that handle.
So only if you continue evaluating `contents' after `hClose' *and*
expect to get the full remaing file contents, then you have a problem.
> Perhaps hClose should arrange to performGC and suck the rest of the
> file if it's still needed.
This would be bad, if you still had a reference to `contents' and were
not interested in the rest of the file (seems to be the case in Manuel's
example). Also, a full garbage collection is quite expensive.
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.)
Olaf
--
OLAF CHITIL,
Dept. of Computer Science, University of York, York YO10 5DD, UK.
URL: http://www.cs.york.ac.uk/~olaf/
Tel: +44 1904 434756; Fax: +44 1904 432767
From simonpj@microsoft.com Mon Apr 9 10:27:40 2001
Date: Mon, 9 Apr 2001 02:27:40 -0700
From: Simon Peyton-Jones simonpj@microsoft.com
Subject: FW: lazy file reading in H98
| Simon doesn't want to make changes to Haskell. My opinion is=20
| that the current definition of readFile and hGetContents is=20
| fine. They are useful when used with a bit of care. Some=20
| remarks should make the reader of the report aware of the=20
| caveats. (I'm not saying that I couldn't imagine some useful=20
| 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=20
clearly what they do and don't do. =20
Improving them is a job for the Libraries group, and I hope
we'll take up the challenge.
Simon
From qrczak@knm.org.pl Mon Apr 9 17:46:05 2001
Date: 9 Apr 2001 16:46:05 GMT
From: Marcin 'Qrczak' Kowalczyk qrczak@knm.org.pl
Subject: FW: lazy file reading in H98
Sun, 08 Apr 2001 19:12:10 +0100, Olaf Chitil <olaf@cs.york.ac.uk> pisze:
> So only if you continue evaluating `contents' after `hClose' *and*
> expect to get the full remaing file contents, then you have a problem.
Indeed. But in a lazy language it's not always obvious that the
evaluation of contents happens after hClose.
Another problem with readFile is that reading many files requires many
open file descriptors if their contents are not evaluated early enough.
This has bitten me in practice.
I agree that reading the rest on hClose would be dangerous, since
the programmer might be no longer interested in it. So perhaps an
explicit operation on a handle should be provided: similar to hClose,
but which causes any remaining contents of a semi-closed handle to be
slurped? Thus for files closed with that operation hGetContents could
be safely treated as if it was strict (assuming that file contents
don't change over time).
Applying 'foldr (const id) (return ())' to the contents string is
not perfect: unintuitive, requires to hold the contents string,
and probably not as efficient as possible.
--
__("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTĘPCZA
QRCZAK
From ashley@semantic.org Wed Apr 11 02:16:51 2001
Date: Tue, 10 Apr 2001 18:16:51 -0700
From: Ashley Yakeley ashley@semantic.org
Subject: Dimensional analysis with fundeps (some physics comments)
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
From ashley@semantic.org Wed Apr 11 03:46:22 2001
Date: Tue, 10 Apr 2001 19:46:22 -0700
From: Ashley Yakeley ashley@semantic.org
Subject: Dimensional analysis with fundeps (some physics comments)
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
From ashley@semantic.org Wed Apr 11 03:52:37 2001
Date: Tue, 10 Apr 2001 19:52:37 -0700
From: Ashley Yakeley ashley@semantic.org
Subject: Dimensions
--Emailer_-1224432122
Content-Type: text/plain; charset="US-ASCII"
This builds on anatoli's work.
--
Ashley Yakeley, Seattle WA
--Emailer_-1224432122
Content-Type: application/octet-stream; name="Dimension.hs";
x-mac-type="54455854";
x-mac-creator="522A6368"
Content-transfer-encoding: base64
Content-Disposition: Attachment; filename="Dimension.hs"
LS0gVGhpcyBpcyB3cml0dGVuIGluIEhhc2tlbGwuCm1vZHVsZSBEaW1lbnNpb24KCShwbHVzLG1p
bnVzLHRpbWVzLGRpdmJ5LAoJRGltZW5zaW9uZWQsCglVbml0LE1hc3MsTGVuZ3RoLFRpbWUsCgl1
bml0LGtpbG9ncmFtbWUsbWV0cmUsc2Vjb25kCgkpIHdoZXJlCgl7CglpbXBvcnQgTWFya2VyVHlw
ZTsKCgl7LS0KCUEgRGltZW5zaW9uZWQgdHlwZSBjYXJyaWVzIGFsb25nIGV4cG9uZW50cyBmb3Ig
dGhyZWUgYmFzaWMKCWRpbWVuc2lvbnM6IG1hc3MsIGxlbmd0aCwgYW5kIHRpbWUuCgktLX0KCglu
ZXd0eXBlIERpbWVuc2lvbmVkIG1hc3MgbGVuZ3RoIHRpbWUgcmVwID0gTWtEaW1lbnNpb25lZCBy
ZXA7CgoJLS0gU29tZSBoYW5keSBhYmJyZXZpYXRpb25zLgoJdHlwZSBVbml0IHJlcAk9IERpbWVu
c2lvbmVkIFplcm8gWmVybyBaZXJvIHJlcDsKCXR5cGUgTWFzcyByZXAJPSBEaW1lbnNpb25lZCBP
bmUgIFplcm8gWmVybyByZXA7Cgl0eXBlIExlbmd0aCByZXAJPSBEaW1lbnNpb25lZCBaZXJvIE9u
ZSAgWmVybyByZXA7Cgl0eXBlIFRpbWUgcmVwCT0gRGltZW5zaW9uZWQgWmVybyBaZXJvIE9uZSAg
cmVwOwoJCgktLSBpbnN0YW5jZSBwcm9wZXJ0aWVzIGZvciBEaW1lbnNpb25lZHMgaW4gZ2VuZXJh
bCBhbmQgVW5pdHMKCS0tIGluIHBhcnRpY3VsYXIKCXVuZGltZW5zaW9uMSAgZiAoTWtEaW1lbnNp
b25lZCB4KSA9IGYgeDsKCXVuZGltZW5zaW9uMXIgZiB4ID0gTWtEaW1lbnNpb25lZCAodW5kaW1l
bnNpb24xIGYgeCk7Cgl1bmRpbWVuc2lvbjIgIGYgKE1rRGltZW5zaW9uZWQgeCkgKE1rRGltZW5z
aW9uZWQgeSkgPSBmIHggeTsKCXVuZGltZW5zaW9uMnIgZiB4IHkgPSBNa0RpbWVuc2lvbmVkICh1
bmRpbWVuc2lvbjIgZiB4IHkpOwoKCWluc3RhbmNlIChFcSByZXApID0+IEVxIChEaW1lbnNpb25l
ZCBtYXNzIGxlbmd0aCB0aW1lIHJlcCkgd2hlcmUKCQl7CgkJKD09KSA9IHVuZGltZW5zaW9uMiAo
PT0pOwoJCX07CgoJaW5zdGFuY2UgKE9yZCByZXApID0+IE9yZCAoRGltZW5zaW9uZWQgbWFzcyBs
ZW5ndGggdGltZSByZXApIHdoZXJlCgkJewoJCWNvbXBhcmUgPSB1bmRpbWVuc2lvbjIgY29tcGFy
ZTsKCQl9OwoKCWluc3RhbmNlIChTaG93IHJlcCkgPT4gU2hvdyAoVW5pdCByZXApIHdoZXJlCgkJ
ewoJCXNob3cgPSB1bmRpbWVuc2lvbjEgc2hvdzsKCQl9OwoKCWluc3RhbmNlIChOdW0gcmVwKSA9
PiBOdW0gKFVuaXQgcmVwKSB3aGVyZQoJCXsKCQkoKykJCQk9IHVuZGltZW5zaW9uMnIgKCspOwoJ
CSgtKQkJCT0gdW5kaW1lbnNpb24yciAoLSk7CgkJKCopCQkJPSB1bmRpbWVuc2lvbjJyICgqKTsK
CQluZWdhdGUJCT0gdW5kaW1lbnNpb24xciBuZWdhdGU7CgkJYWJzCQkJPSB1bmRpbWVuc2lvbjFy
IGFiczsKCQlzaWdudW0JCT0gdW5kaW1lbnNpb24xciBzaWdudW07CgkJZnJvbUludGVnZXIJPSBN
a0RpbWVuc2lvbmVkIC4gZnJvbUludGVnZXI7CgkJZnJvbUludAkJPSBNa0RpbWVuc2lvbmVkIC4g
ZnJvbUludDsKCQl9OwoKCWluc3RhbmNlIChSZWFsIHJlcCkgPT4gUmVhbCAoVW5pdCByZXApIHdo
ZXJlCgkJewoJCXRvUmF0aW9uYWwgPSB1bmRpbWVuc2lvbjEgdG9SYXRpb25hbDsKCQl9OwoKCWlu
c3RhbmNlIChGcmFjdGlvbmFsIHJlcCkgPT4gRnJhY3Rpb25hbCAoVW5pdCByZXApIHdoZXJlCgkJ
ewoJCSgvKQkJCQk9IHVuZGltZW5zaW9uMnIgKC8pOwoJCXJlY2lwCQkJPSB1bmRpbWVuc2lvbjFy
IHJlY2lwOwoJCWZyb21SYXRpb25hbAk9IE1rRGltZW5zaW9uZWQgLiBmcm9tUmF0aW9uYWw7CgkJ
ZnJvbURvdWJsZQkJPSBNa0RpbWVuc2lvbmVkIC4gZnJvbURvdWJsZTsKCQl9OwoKCWluc3RhbmNl
IChGbG9hdGluZyByZXApID0+IEZsb2F0aW5nIChVbml0IHJlcCkgd2hlcmUKCQl7CgkJcGkJCT0J
TWtEaW1lbnNpb25lZCBwaTsKCQlleHAJCT0JdW5kaW1lbnNpb24xciBleHA7CgkJbG9nCQk9CXVu
ZGltZW5zaW9uMXIgbG9nOwoJCXNxcnQJPQl1bmRpbWVuc2lvbjFyIHNxcnQ7CgkJKCoqKQk9CXVu
ZGltZW5zaW9uMnIgKCoqKTsKCQlsb2dCYXNlCT0JdW5kaW1lbnNpb24yciBsb2dCYXNlOwoJCXNp
bgkJPQl1bmRpbWVuc2lvbjFyIHNpbjsKCQljb3MJCT0JdW5kaW1lbnNpb24xciBjb3M7CgkJdGFu
CQk9CXVuZGltZW5zaW9uMXIgdGFuOwoJCWFzaW4JPQl1bmRpbWVuc2lvbjFyIGFzaW47CgkJYWNv
cwk9CXVuZGltZW5zaW9uMXIgYWNvczsKCQlhdGFuCT0JdW5kaW1lbnNpb24xciBhdGFuOwoJCXNp
bmgJPQl1bmRpbWVuc2lvbjFyIHNpbmg7CgkJY29zaAk9CXVuZGltZW5zaW9uMXIgY29zaDsKCQl0
YW5oCT0JdW5kaW1lbnNpb24xciB0YW5oOwoJCWFzaW5oCT0JdW5kaW1lbnNpb24xciBhc2luaDsK
CQlhY29zaAk9CXVuZGltZW5zaW9uMXIgYWNvc2g7CgkJYXRhbmgJPQl1bmRpbWVuc2lvbjFyIGF0
YW5oOwoJCX07CgkKCWluc3RhbmNlIChSZWFsRnJhYyByZXApID0+IFJlYWxGcmFjIChVbml0IHJl
cCkgd2hlcmUKCQl7CgkJcHJvcGVyRnJhY3Rpb24gKE1rRGltZW5zaW9uZWQgeCkgPSAocCxNa0Rp
bWVuc2lvbmVkIHEpIHdoZXJlCgkJCXsKCQkJKHAscSkgPSBwcm9wZXJGcmFjdGlvbiB4OwoJCQl9
OwoJCXRydW5jYXRlCQk9IHVuZGltZW5zaW9uMSB0cnVuY2F0ZTsKCQlyb3VuZAkJCT0gdW5kaW1l
bnNpb24xIHJvdW5kOwoJCWNlaWxpbmcJCQk9IHVuZGltZW5zaW9uMSBjZWlsaW5nOwoJCWZsb29y
CQkJPSB1bmRpbWVuc2lvbjEgZmxvb3I7CgkJfTsKCQoJaW5zdGFuY2UgKFJlYWxGbG9hdCByZXAp
ID0+IFJlYWxGbG9hdCAoVW5pdCByZXApIHdoZXJlCgkJewoJCWZsb2F0UmFkaXgJCT0gdW5kaW1l
bnNpb24xIGZsb2F0UmFkaXg7CgkJZmxvYXREaWdpdHMJCT0gdW5kaW1lbnNpb24xIGZsb2F0RGln
aXRzOwoJCWZsb2F0UmFuZ2UJCT0gdW5kaW1lbnNpb24xIGZsb2F0UmFuZ2U7CgkJZGVjb2RlRmxv
YXQJCT0gdW5kaW1lbnNpb24xIGRlY29kZUZsb2F0OwoJCWVuY29kZUZsb2F0IHggaQk9IE1rRGlt
ZW5zaW9uZWQgKGVuY29kZUZsb2F0IHggaSk7CgkJZXhwb25lbnQJCT0gdW5kaW1lbnNpb24xIGV4
cG9uZW50OwoJCXNpZ25pZmljYW5kCQk9IHVuZGltZW5zaW9uMXIgc2lnbmlmaWNhbmQ7CgkJc2Nh
bGVGbG9hdCBpCT0gdW5kaW1lbnNpb24xciAoc2NhbGVGbG9hdCBpKTsKCQlpc05hTgkJCT0gdW5k
aW1lbnNpb24xIGlzTmFOOwoJCWlzSW5maW5pdGUJCT0gdW5kaW1lbnNpb24xIGlzSW5maW5pdGU7
CgkJaXNEZW5vcm1hbGl6ZWQJPSB1bmRpbWVuc2lvbjEgaXNEZW5vcm1hbGl6ZWQ7CgkJaXNOZWdh
dGl2ZVplcm8JPSB1bmRpbWVuc2lvbjEgaXNOZWdhdGl2ZVplcm87CgkJaXNJRUVFCQkJPSB1bmRp
bWVuc2lvbjEgaXNJRUVFOwoJCWF0YW4yCQkJPSB1bmRpbWVuc2lvbjJyIGF0YW4yOwoJCX07CgoJ
LS0gWW91IGNhbiBhZGQgb3Igc3VidHJhY3Qgb25seSBpZGVudGljYWxseSBkaW1lbnNpb25lZCBx
dWFudGl0aWVzLgoJcGx1cywgbWludXMgOjogTnVtIHJlcCA9PgoJCURpbWVuc2lvbmVkIG1hc3Mg
bGVuZ3RoIHRpbWUgcmVwIC0+CgkJRGltZW5zaW9uZWQgbWFzcyBsZW5ndGggdGltZSByZXAgLT4K
CQlEaW1lbnNpb25lZCBtYXNzIGxlbmd0aCB0aW1lIHJlcDsKCXBsdXMgIChNa0RpbWVuc2lvbmVk
IHgpIChNa0RpbWVuc2lvbmVkIHkpID0gTWtEaW1lbnNpb25lZCAoeCt5KTsKCW1pbnVzIChNa0Rp
bWVuc2lvbmVkIHgpIChNa0RpbWVuc2lvbmVkIHkpID0gTWtEaW1lbnNpb25lZCAoeC15KTsKCgkt
LSBZb3UgY2FuIG11bHRpcGx5IGFueSB0d28gZGltZW5zaW9uZWQgcXVhbnRpdGllczsgZXhwb25l
bnRzCgktLSBmcm9tIHRoZSBvcGVyYW5kcyBhZGQgdXAgaW4gdGhlIHJlc3VsdC4KCXRpbWVzIDo6
IChOdW0gcmVwLAoJCUFkZCBtYXNzIG1hc3MnIG1hc3MnJywKCQlBZGQgbGVuZ3RoIGxlbmd0aCcg
bGVuZ3RoJycsCgkJQWRkIHRpbWUgdGltZScgdGltZScnKSA9PgoJCURpbWVuc2lvbmVkIG1hc3Mg
bGVuZ3RoIHRpbWUgcmVwIC0+CgkJRGltZW5zaW9uZWQgbWFzcycgbGVuZ3RoJyB0aW1lJyByZXAg
LT4KCQlEaW1lbnNpb25lZCBtYXNzJycgbGVuZ3RoJycgdGltZScnIHJlcDsKCXRpbWVzIChNa0Rp
bWVuc2lvbmVkIHgpIChNa0RpbWVuc2lvbmVkIHkpID0gTWtEaW1lbnNpb25lZCAoeCAqIHkpOwoK
CS0tIFNpbWlsYXJseSBmb3IgZGl2aXNpb24sIGV4Y2VwdCBleHBvbmVudHMgYXJlIHN1YnRyYWN0
ZWQuCglkaXZieSA6OiAoRnJhY3Rpb25hbCByZXAsCgkJU3ViIG1hc3MgbWFzcycgbWFzcycnLAoJ
CVN1YiBsZW5ndGggbGVuZ3RoJyBsZW5ndGgnJywKCQlTdWIgdGltZSB0aW1lJyB0aW1lJycpID0+
CgkJRGltZW5zaW9uZWQgbWFzcyBsZW5ndGggdGltZSByZXAgLT4KCQlEaW1lbnNpb25lZCBtYXNz
JyBsZW5ndGgnIHRpbWUnIHJlcCAtPgoJCURpbWVuc2lvbmVkIG1hc3MnJyBsZW5ndGgnJyB0aW1l
JycgcmVwOwoJZGl2YnkgKE1rRGltZW5zaW9uZWQgeCkgKE1rRGltZW5zaW9uZWQgeSkgPSBNa0Rp
bWVuc2lvbmVkICh4IC8geSk7CgoJLS0gYmFzZSB1bml0cyBhcyBTSS4KCWtpbG9ncmFtbWUJOjog
KE51bSByZXApID0+IE1hc3MgcmVwOwoJa2lsb2dyYW1tZQk9IChNa0RpbWVuc2lvbmVkIDEpOwoJ
bWV0cmUJCTo6IChOdW0gcmVwKSA9PiBMZW5ndGggcmVwOwoJbWV0cmUJCT0gKE1rRGltZW5zaW9u
ZWQgMSk7CglzZWNvbmQJCTo6IChOdW0gcmVwKSA9PiBUaW1lIHJlcDsKCXNlY29uZAkJPSAoTWtE
aW1lbnNpb25lZCAxKTsKCXVuaXQJCTo6IChOdW0gcmVwKSA9PiBVbml0IHJlcDsKCXVuaXQJCT0g
MTsKCX0K
--Emailer_-1224432122
Content-Type: application/octet-stream; name="MarkerType.hs";
x-mac-type="54455854";
x-mac-creator="522A6368"
Content-transfer-encoding: base64
Content-Disposition: Attachment; filename="MarkerType.hs"
LS0gVGhpcyBpcyB3cml0dGVuIGluIEhhc2tlbGwuCm1vZHVsZSBNYXJrZXJUeXBlIHdoZXJlCgl7
CgktLSBCb29sZWFucyBleHByZXNzZWQgYXMgSGFza2VsbCB0eXBlcy4KCWRhdGEgVHJ1ZTsKCWRh
dGEgRmFsc2U7CgkKCWNsYXNzIElzIGE7CglpbnN0YW5jZSBJcyBUcnVlOwoKCWNsYXNzIElzbnQg
YTsKCWluc3RhbmNlIElzbnQgRmFsc2U7CgoJY2xhc3MgRWl0aGVySXMgYSBiOwoJaW5zdGFuY2Ug
RWl0aGVySXMgVHJ1ZSBiOwoJaW5zdGFuY2UgRWl0aGVySXMgRmFsc2UgVHJ1ZTsKCgljbGFzcyBC
b3RoQXJlIGEgYjsKCWluc3RhbmNlIEJvdGhBcmUgVHJ1ZSBUcnVlOwoJCgljbGFzcyBOb3QgYSBi
IHwgYSAtPiBiOwoJaW5zdGFuY2UgTm90IFRydWUgRmFsc2U7CglpbnN0YW5jZSBOb3QgRmFsc2Ug
VHJ1ZTsKCQoJY2xhc3MgT3IgYSBiIGMgfCBhIGIgLT4gYzsKCWluc3RhbmNlIE9yIFRydWUgYiBU
cnVlOwoJaW5zdGFuY2UgT3IgRmFsc2UgYiBiOwoJCgljbGFzcyBBbmQgYSBiIGMgfCBhIGIgLT4g
YzsKCWluc3RhbmNlIEFuZCBUcnVlIGIgYjsKCWluc3RhbmNlIEFuZCBGYWxzZSBiIEZhbHNlOwoK
CXstLQoJSW50ZWdlcnMgZXhwcmVzc2VkIGFzIEhhc2tlbGwgdHlwZXMuIFplcm8gaXMgMC4KCUlm
IHR5cGUgYSBpcyBaZXJvIG9yIHBvc2l0aXZlLCB0aGVuIChTdWNjIGEpIGlzIHBvc2l0aXZlOwoJ
aWYgdHlwZSBhIGlzIFplcm8gb3IgbmVnYXRpdmUsIHRoZW4gKFByZWQgYSkgaXMgbmVnYXRpdmUu
CglUaGlzIGlzIHZlcnkgY3J1ZGUgYW5kIHNob3VsZCBiZSByZXBsYWNlZCB3aXRoIHNpZ24tbWFn
bml0dWRlIAoJcmVwcmVzZW50YXRpb24uCgktLX0KCglkYXRhIFplcm87CglkYXRhIFN1Y2MgbjsK
CWRhdGEgUHJlZCBuOwoKCXR5cGUgT25lID0gU3VjYyBaZXJvOwoJdHlwZSBUd28gPSBTdWNjIE9u
ZTsKCXR5cGUgVGhyZWUgPSBTdWNjIFR3bzsKCXR5cGUgTWludXNPbmUgPSBQcmVkIFplcm87Cgl0
eXBlIE1pbnVzVHdvID0gUHJlZCBNaW51c09uZTsKCXR5cGUgTWludXNUaHJlZSA9IFByZWQgTWlu
dXNUd287CgoJY2xhc3MgU3VjY2Vzc29yIGEgYiB8IGEgLT4gYjsKCWluc3RhbmNlIFN1Y2Nlc3Nv
ciBaZXJvIE9uZTsKCWluc3RhbmNlIFN1Y2Nlc3NvciAoU3VjYyBhKSAoU3VjYyAoU3VjYyBhKSk7
CglpbnN0YW5jZSBTdWNjZXNzb3IgKFByZWQgYSkgYTsKCgljbGFzcyBQcmVkZWNlc3NvciBhIGIg
fCBhIC0+IGI7CglpbnN0YW5jZSBQcmVkZWNlc3NvciBaZXJvIE1pbnVzT25lOwoJaW5zdGFuY2Ug
UHJlZGVjZXNzb3IgKFN1Y2MgYSkgYTsKCWluc3RhbmNlIFByZWRlY2Vzc29yIChQcmVkIGEpIChQ
cmVkIChQcmVkIGEpKTsKCgljbGFzcyBBdExlYXN0IGEgYjsgLS0gYSA+PSBiCglpbnN0YW5jZSBB
dExlYXN0IFplcm8gWmVybzsKCWluc3RhbmNlIEF0TGVhc3QgKFN1Y2MgYSkgWmVybzsKCWluc3Rh
bmNlIEF0TGVhc3QgWmVybyAoUHJlZCBiKTsKCWluc3RhbmNlIEF0TGVhc3QgKFN1Y2MgYSkgKFBy
ZWQgYik7CglpbnN0YW5jZSAoQXRMZWFzdCBhIGIpID0+IEF0TGVhc3QgKFN1Y2MgYSkgKFN1Y2Mg
Yik7CglpbnN0YW5jZSAoQXRMZWFzdCBhIGIpID0+IEF0TGVhc3QgKFByZWQgYSkgKFByZWQgYik7
CgoJY2xhc3MgTmF0dXJhbCBhOwoJaW5zdGFuY2UgTmF0dXJhbCBaZXJvOwoJaW5zdGFuY2UgTmF0
dXJhbCAoU3VjYyBhKTsKCgljbGFzcyBBdExlYXN0T25lIGE7CglpbnN0YW5jZSAoTmF0dXJhbCBh
KSA9PiBBdExlYXN0T25lIChTdWNjIGEpOwoKCWNsYXNzIEV2ZW4gYTsKCWluc3RhbmNlIEV2ZW4g
WmVybzsKCWluc3RhbmNlIChFdmVuIGEpID0+IEV2ZW4gKFN1Y2MgKFN1Y2MgYSkpOwoJaW5zdGFu
Y2UgKEV2ZW4gYSkgPT4gRXZlbiAoUHJlZCAoUHJlZCBhKSk7CgoJLS0gSW50ZWdlciBhZGRpdGlv
bi4gQm90aCBvcGVyYW5kcyBhcmUgZWl0aGVyIHBvc2l0aXZlLCBuZWdhdGl2ZQoJLS0gb3IgemVy
bywgc28gd2UgY29uc2lkZXIgMyozPTkgY2FzZXMuCgljbGFzcyBBZGQgYSBiIGMgfCBhIGIgLT4g
YzsKCglpbnN0YW5jZSBBZGQgWmVybyBaZXJvIFplcm87CgoJaW5zdGFuY2UgQWRkIFplcm8gKFN1
Y2MgYikgKFN1Y2MgYik7CglpbnN0YW5jZSBBZGQgWmVybyAoUHJlZCBiKSAoUHJlZCBiKTsKCglp
bnN0YW5jZSBBZGQgKFN1Y2MgYikgWmVybyAoU3VjYyBiKTsKCWluc3RhbmNlIEFkZCAoUHJlZCBi
KSBaZXJvIChQcmVkIGIpOwoKCWluc3RhbmNlIEFkZCBhIGIgYyA9PiBBZGQgKFN1Y2MgYSkgKFN1
Y2MgYikgKFN1Y2MgKFN1Y2MgYykpOwoJaW5zdGFuY2UgQWRkIGEgYiBjID0+IEFkZCAoUHJlZCBh
KSAoUHJlZCBiKSAoUHJlZCAoUHJlZCBjKSk7CgoJaW5zdGFuY2UgQWRkIGEgYiBjID0+IEFkZCAo
U3VjYyBhKSAoUHJlZCBiKSBjOwoJaW5zdGFuY2UgQWRkIGEgYiBjID0+IEFkZCAoUHJlZCBhKSAo
U3VjYyBiKSBjOwoKCS0tIFN1YnRyYWN0aW9uIGlzIHZlcnkgc2ltaWxhciB0byBhZGRpdGlvbi4K
CWNsYXNzIFN1YiBhIGIgYyB8IGEgYiAtPiBjOwoKCWluc3RhbmNlIFN1YiBaZXJvIFplcm8gWmVy
bzsKCglpbnN0YW5jZSBTdWIgWmVybyAoU3VjYyBiKSAoUHJlZCBiKTsKCWluc3RhbmNlIFN1YiBa
ZXJvIChQcmVkIGIpIChTdWNjIGIpOwoKCWluc3RhbmNlIFN1YiAoU3VjYyBiKSBaZXJvIChTdWNj
IGIpOwoJaW5zdGFuY2UgU3ViIChQcmVkIGIpIFplcm8gKFByZWQgYik7CgoJaW5zdGFuY2UgU3Vi
IGEgYiBjID0+IFN1YiAoU3VjYyBhKSAoU3VjYyBiKSBjOwoJaW5zdGFuY2UgU3ViIGEgYiBjID0+
IFN1YiAoUHJlZCBhKSAoUHJlZCBiKSBjOwoKCWluc3RhbmNlIFN1YiBhIGIgYyA9PiBTdWIgKFN1
Y2MgYSkgKFByZWQgYikgKFN1Y2MgKFN1Y2MgYykpOwoJaW5zdGFuY2UgU3ViIGEgYiBjID0+IFN1
YiAoUHJlZCBhKSAoU3VjYyBiKSAoUHJlZCAoUHJlZCBjKSk7Cgl9Cg==
--Emailer_-1224432122--
From reid@cs.utah.edu Wed Apr 11 04:19:22 2001
Date: Tue, 10 Apr 2001 21:19:22 -0600
From: Alastair Reid reid@cs.utah.edu
Subject: Dimensional analysis with fundeps (some physics comments)
> I'm cross-posting this to the Libraries list...
I'm not sure that's an appropriate thing to do.
As I understand it, the libraries list is concerned with libraries which
are currently in the standard, or that are getting stable enough to either add
to the standard or for some non-singular set of compilers to officially
support.
OTOH, the dimensional analysis stuff is not a library, not a proposed library
and, since it seems to be less than a week old, not approaching stability.
--
Alastair Reid
From ashley@semantic.org Tue Apr 3 05:47:39 2001
From: ashley@semantic.org (Ashley Yakeley)
Date: Mon, 2 Apr 2001 21:47:39 -0700
Subject: Haskell-Java Bridge?
Message-ID: <200104030447.VAA11013@mail4.halcyon.com>
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
From simonpj@microsoft.com Tue Apr 3 09:04:04 2001
From: simonpj@microsoft.com (Simon Peyton-Jones)
Date: Tue, 3 Apr 2001 01:04:04 -0700
Subject: Haskell-Java Bridge?
Message-ID: <37DA476A2BC9F64C95379BF66BA2690260DCE3@red-msg-09.redmond.corp.microsoft.com>
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]=20
| Sent: 03 April 2001 05:48
| To: Libraries for Haskell List
| Subject: Haskell-Java Bridge?
|=20
|=20
| Has anyone done any work on creating an FFI bridge from=20
| Haskell to Java=20
| via JNI? I'm not talking about compiling Haskell to Java=20
| bytecode, merely=20
| the ability to call the Java VM from Haskell.
|=20
| Two points in Java's favour:
|=20
| 1. Platform Ubiquity. You can find Java VMs for a wide range=20
| of platforms.
|=20
| 2. Java provides a wide range of functionality including GUI,=20
| network,=20
| file access, SQL, etc., etc.
|=20
| Contrary to popular belief, it is straightforward to create=20
| and use Java=20
| classes at run-time from the list of bytes that make up the class.
|=20
| --=20
| Ashley Yakeley, Seattle WA
|=20
|=20
| _______________________________________________
| Libraries mailing list
| Libraries@haskell.org=20
| http://www.haskell.org/mailman/listinfo/libraries
|=20
From simonpj@microsoft.com Tue Apr 3 12:00:55 2001
From: simonpj@microsoft.com (Simon Peyton-Jones)
Date: Tue, 3 Apr 2001 04:00:55 -0700
Subject: FW: lazy file reading in H98
Message-ID: <37DA476A2BC9F64C95379BF66BA2690260DCED@red-msg-09.redmond.corp.microsoft.com>
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.=20
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]=20
Sent: 05 September 2000 02:10
To: haskell@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,=20
readFile fname >>=3D 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.
From simonmar@microsoft.com Tue Apr 3 16:29:00 2001
From: simonmar@microsoft.com (Simon Marlow)
Date: Tue, 3 Apr 2001 16:29:00 +0100
Subject: lazy file reading in H98
Message-ID: <9584A4A864BD8548932F2F88EB30D1C6115838@TVP-MSG-01.europe.corp.microsoft.com>
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=20
> Sent: Tuesday, April 03, 2001 12:01 PM
> To: Libraries for Haskell List
> Subject: FW: lazy file reading in H98
>=20
>=20
> Here's a library issue.
>=20
> 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.=20
>=20
> Question: should one of our extended-IO libraries support a version of
> openFile that guarantees option (2)?
>=20
> Simon
>=20
> -----Original Message-----
> From: Manuel M. T. Chakravarty [mailto:chak@cse.unsw.edu.au]=20
> Sent: 05 September 2000 02:10
> To: haskell@haskell.org
> Subject: lazy file reading in H98
>=20
>=20
> In an assignment, in my class, we came across a lack of=20
> specification of
> the behaviour of `Prelude.readFile' and `IO.hGetContents' and=20
> IMHO also
> a lack of functionality. As both operations read a file lazily,
> subsequent writes to the same file are potentially=20
> disastrous. In this
> assignment, the file was used to make a Haskell data structure
> persistent over multiple runs of the program - ie,=20
>=20
> readFile fname >>=3D return . read
>=20
> at the start of the program and
>=20
> writeFile fname . show
>=20
> 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.
>=20
> H98 doesn't really specify what happens in this situation.
> I think, there are two ways to solve that:
>=20
> (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.
>=20
> (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]
>=20
> 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.
>=20
> So, overall, I think solution (2) is more elegant.
>=20
> Cheers,
> Manuel
>=20
> [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.
>=20
> _______________________________________________
> Libraries mailing list
> Libraries@haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>=20
From Malcolm.Wallace@cs.york.ac.uk Tue Apr 3 17:04:07 2001
From: Malcolm.Wallace@cs.york.ac.uk (Malcolm Wallace)
Date: Tue, 3 Apr 2001 17:04:07 +0100
Subject: FW: lazy file reading in H98
In-Reply-To: <37DA476A2BC9F64C95379BF66BA2690260DCED@red-msg-09.redmond.corp.microsoft.com>
Message-ID:
> (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
From simonmar@microsoft.com Tue Apr 3 17:21:24 2001
From: simonmar@microsoft.com (Simon Marlow)
Date: Tue, 3 Apr 2001 17:21:24 +0100
Subject: FW: lazy file reading in H98
Message-ID: <9584A4A864BD8548932F2F88EB30D1C611583A@TVP-MSG-01.europe.corp.microsoft.com>
> > (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.
>=20
> 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
From Malcolm.Wallace@cs.york.ac.uk Tue Apr 3 17:32:16 2001
From: Malcolm.Wallace@cs.york.ac.uk (Malcolm Wallace)
Date: Tue, 3 Apr 2001 17:32:16 +0100
Subject: FW: lazy file reading in H98
In-Reply-To: <9584A4A864BD8548932F2F88EB30D1C611583A@TVP-MSG-01.europe.corp.microsoft.com>
Message-ID: <7F8AABD7yTqDwQkA@cs.york.ac.uk>
> Yes, but the behaviour specified by the report isn't exactly useful.
I know, but making the definition less defined than at present won't
help much either.
> Incidentally, nhc98 doesn't seem to implement the locking (perhaps this
> is a known bug, I didn't check).
Yes, nhc98 doesn't currently implement file locking. I regard
this as non-conformance to the standard, rather than a bug as such.
We just never got round to implementing it yet.
Regards,
Malcolm
From simonpj@microsoft.com Wed Apr 4 15:36:30 2001
From: simonpj@microsoft.com (Simon Peyton-Jones)
Date: Wed, 4 Apr 2001 07:36:30 -0700
Subject: FW: lazy file reading in H98
Message-ID: <37DA476A2BC9F64C95379BF66BA2690260DCFD@red-msg-09.redmond.corp.microsoft.com>
I'm working on this text right now. Check out
=09
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]=20
| Sent: 03 April 2001 17:04
| To: libraries@haskell.org
| Subject: Re: FW: lazy file reading in H98
|=20
|=20
| > (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.
|=20
| The Library Report is already stronger than this. The=20
| behaviour is fully defined: an error should be raised. =20
| Here's what it says:
|=20
| > Implementations should enforce as far as possible, locally=20
| to the Haskell
| > process, multiple-reader single-writer locking on files. =20
| ... If any
| > open or semi-closed handle is managing a file for input,=20
| new handles=20
| > can only be allocated if they do not manage output.
| > ...
| > Error reporting: the openFile computation may fail with=20
| > isAlreadyInUseError if the file is already open and cannot be=20
| > reopened.
|=20
| The only very slightly confusing aspect is that the handles=20
| used by "readFile" and "writeFile" are internal, not written=20
| directly by the programmer. Perhaps the description of this=20
| behaviour should be moved up from the 11.3.1 "Opening Files"=20
| subsection to the enclosing 11.3 section, because it is more=20
| generally applicable.
|=20
| Subsection 11.2.1 "Semi-closed Handles" should mention=20
| "readFile" in addition to "hGetContents". It could also=20
| explicitly refer to the multiple-reader single-writer=20
| restriction, which is not otherwise mentioned here.
|=20
| Regards,
| Malcolm
|=20
| _______________________________________________
| Libraries mailing list
| Libraries@haskell.org=20
| http://www.haskell.org/mailman/listinfo/libraries
|=20
From olaf@cs.york.ac.uk Sat Apr 7 20:35:52 2001
From: olaf@cs.york.ac.uk (Olaf Chitil)
Date: Sat, 07 Apr 2001 20:35:52 +0100
Subject: FW: lazy file reading in H98
References: <37DA476A2BC9F64C95379BF66BA2690260DCFD@red-msg-09.redmond.corp.microsoft.com>
Message-ID: <3ACF6C18.F5213335@cs.york.ac.uk>
> (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.
This restriction would be too harsh. It is desirable to be able to write
to a file that has been read before with `readFile' or `hGetContents'.
With hGetContents you can do this safely:
do
handle <- openFile "configuration" ReadMode
contents <- hGetContents
...
hClose handle
writeFile "configuration" newContents
At the point where you write newContents, you should no longer be
interested in contents. Either, because you are at the end of the
program execution anyway (as in Manuel's example), or because you
checked that you could parse the contents and hence processed the whole
contents, e.g.:
...
case parse contents of
Nothing -> error "corrupted file format"
Just info -> ...
I would think that the later case is very common and then you do not
even have to use `hClose'. However, I would prefer to do so and it is
unfortunate that you cannot when you use `readFile'.
Maybe these points should be mentioned in the report.
Another point: I had difficulties parsing the following sentence of
Section 11.2.2 on first reading:
Any operation except for hClose that fails because a handle is closed,
also fails if a handle is semi-closed.
Alternatives:
Any operation (except for hClose) that fails because a handle is closed,
also fails if a handle is semi-closed.
Any operation that fails because a handle is closed, also fails if a
handle is semi-closed. The only exception is hClose.
Olaf
--
OLAF CHITIL,
Dept. of Computer Science, University of York, York YO10 5DD, UK.
URL: http://www.cs.york.ac.uk/~olaf/
Tel: +44 1904 434756; Fax: +44 1904 432767
From qrczak@knm.org.pl Sat Apr 7 22:09:26 2001
From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk)
Date: 7 Apr 2001 21:09:26 GMT
Subject: FW: lazy file reading in H98
References: <37DA476A2BC9F64C95379BF66BA2690260DCFD@red-msg-09.redmond.corp.microsoft.com> <3ACF6C18.F5213335@cs.york.ac.uk>
Message-ID:
Sat, 07 Apr 2001 20:35:52 +0100, Olaf Chitil pisze:
> do
> handle <- openFile "configuration" ReadMode
> contents <- hGetContents
> ...
> hClose handle
> writeFile "configuration" newContents
It will be wrong if the contents is not fully evaluated at the point
of hClose.
Perhaps hClose should arrange to performGC and suck the rest of the
file if it's still needed.
--
__("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTĘPCZA
QRCZAK
From olaf@cs.york.ac.uk Sun Apr 8 19:12:10 2001
From: olaf@cs.york.ac.uk (Olaf Chitil)
Date: Sun, 08 Apr 2001 19:12:10 +0100
Subject: FW: lazy file reading in H98
References: <37DA476A2BC9F64C95379BF66BA2690260DCFD@red-msg-09.redmond.corp.microsoft.com> <3ACF6C18.F5213335@cs.york.ac.uk>
Message-ID: <3AD0A9FA.4B1310D6@cs.york.ac.uk>
Marcin 'Qrczak' Kowalczyk wrote:
>
> Sat, 07 Apr 2001 20:35:52 +0100, Olaf Chitil pisze:
>
> > do
> > handle <- openFile "configuration" ReadMode
> > contents <- hGetContents
> > ...
> > hClose handle
> > writeFile "configuration" newContents
>
> It will be wrong if the contents is not fully evaluated at the point
> of hClose.
What do you mean by `wrong'? As 11.2.2 says:
Once a semi-closed handle becomes closed, the contents of the associated
stream becomes fixed, and is the list of those items which were
successfully read from that handle.
So only if you continue evaluating `contents' after `hClose' *and*
expect to get the full remaing file contents, then you have a problem.
> Perhaps hClose should arrange to performGC and suck the rest of the
> file if it's still needed.
This would be bad, if you still had a reference to `contents' and were
not interested in the rest of the file (seems to be the case in Manuel's
example). Also, a full garbage collection is quite expensive.
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.)
Olaf
--
OLAF CHITIL,
Dept. of Computer Science, University of York, York YO10 5DD, UK.
URL: http://www.cs.york.ac.uk/~olaf/
Tel: +44 1904 434756; Fax: +44 1904 432767
From simonpj@microsoft.com Mon Apr 9 10:27:40 2001
From: simonpj@microsoft.com (Simon Peyton-Jones)
Date: Mon, 9 Apr 2001 02:27:40 -0700
Subject: FW: lazy file reading in H98
Message-ID: <37DA476A2BC9F64C95379BF66BA26902D72E30@red-msg-09.redmond.corp.microsoft.com>
| Simon doesn't want to make changes to Haskell. My opinion is=20
| that the current definition of readFile and hGetContents is=20
| fine. They are useful when used with a bit of care. Some=20
| remarks should make the reader of the report aware of the=20
| caveats. (I'm not saying that I couldn't imagine some useful=20
| 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=20
clearly what they do and don't do. =20
Improving them is a job for the Libraries group, and I hope
we'll take up the challenge.
Simon
From qrczak@knm.org.pl Mon Apr 9 17:46:05 2001
From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk)
Date: 9 Apr 2001 16:46:05 GMT
Subject: FW: lazy file reading in H98
References: <37DA476A2BC9F64C95379BF66BA2690260DCFD@red-msg-09.redmond.corp.microsoft.com> <3ACF6C18.F5213335@cs.york.ac.uk> <3AD0A9FA.4B1310D6@cs.york.ac.uk>
Message-ID:
Sun, 08 Apr 2001 19:12:10 +0100, Olaf Chitil pisze:
> So only if you continue evaluating `contents' after `hClose' *and*
> expect to get the full remaing file contents, then you have a problem.
Indeed. But in a lazy language it's not always obvious that the
evaluation of contents happens after hClose.
Another problem with readFile is that reading many files requires many
open file descriptors if their contents are not evaluated early enough.
This has bitten me in practice.
I agree that reading the rest on hClose would be dangerous, since
the programmer might be no longer interested in it. So perhaps an
explicit operation on a handle should be provided: similar to hClose,
but which causes any remaining contents of a semi-closed handle to be
slurped? Thus for files closed with that operation hGetContents could
be safely treated as if it was strict (assuming that file contents
don't change over time).
Applying 'foldr (const id) (return ())' to the contents string is
not perfect: unintuitive, requires to hold the contents string,
and probably not as efficient as possible.
--
__("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTĘPCZA
QRCZAK
From ashley@semantic.org Wed Apr 11 02:16:51 2001
From: ashley@semantic.org (Ashley Yakeley)
Date: Tue, 10 Apr 2001 18:16:51 -0700
Subject: Dimensional analysis with fundeps (some physics comments)
Message-ID: <200104110116.SAA01777@mail4.halcyon.com>
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
From ashley@semantic.org Wed Apr 11 03:46:22 2001
From: ashley@semantic.org (Ashley Yakeley)
Date: Tue, 10 Apr 2001 19:46:22 -0700
Subject: Dimensional analysis with fundeps (some physics comments)
Message-ID: <200104110246.TAA10096@mail4.halcyon.com>
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
From ashley@semantic.org Wed Apr 11 03:52:37 2001
From: ashley@semantic.org (Ashley Yakeley)
Date: Tue, 10 Apr 2001 19:52:37 -0700
Subject: Dimensions
Message-ID: <200104110252.TAA10666@mail4.halcyon.com>
--Emailer_-1224432122
Content-Type: text/plain; charset="US-ASCII"
This builds on anatoli's work.
--
Ashley Yakeley, Seattle WA
--Emailer_-1224432122
Content-Type: application/octet-stream; name="Dimension.hs";
x-mac-type="54455854";
x-mac-creator="522A6368"
Content-transfer-encoding: base64
Content-Disposition: Attachment; filename="Dimension.hs"
LS0gVGhpcyBpcyB3cml0dGVuIGluIEhhc2tlbGwuCm1vZHVsZSBEaW1lbnNpb24KCShwbHVzLG1p
bnVzLHRpbWVzLGRpdmJ5LAoJRGltZW5zaW9uZWQsCglVbml0LE1hc3MsTGVuZ3RoLFRpbWUsCgl1
bml0LGtpbG9ncmFtbWUsbWV0cmUsc2Vjb25kCgkpIHdoZXJlCgl7CglpbXBvcnQgTWFya2VyVHlw
ZTsKCgl7LS0KCUEgRGltZW5zaW9uZWQgdHlwZSBjYXJyaWVzIGFsb25nIGV4cG9uZW50cyBmb3Ig
dGhyZWUgYmFzaWMKCWRpbWVuc2lvbnM6IG1hc3MsIGxlbmd0aCwgYW5kIHRpbWUuCgktLX0KCglu
ZXd0eXBlIERpbWVuc2lvbmVkIG1hc3MgbGVuZ3RoIHRpbWUgcmVwID0gTWtEaW1lbnNpb25lZCBy
ZXA7CgoJLS0gU29tZSBoYW5keSBhYmJyZXZpYXRpb25zLgoJdHlwZSBVbml0IHJlcAk9IERpbWVu
c2lvbmVkIFplcm8gWmVybyBaZXJvIHJlcDsKCXR5cGUgTWFzcyByZXAJPSBEaW1lbnNpb25lZCBP
bmUgIFplcm8gWmVybyByZXA7Cgl0eXBlIExlbmd0aCByZXAJPSBEaW1lbnNpb25lZCBaZXJvIE9u
ZSAgWmVybyByZXA7Cgl0eXBlIFRpbWUgcmVwCT0gRGltZW5zaW9uZWQgWmVybyBaZXJvIE9uZSAg
cmVwOwoJCgktLSBpbnN0YW5jZSBwcm9wZXJ0aWVzIGZvciBEaW1lbnNpb25lZHMgaW4gZ2VuZXJh
bCBhbmQgVW5pdHMKCS0tIGluIHBhcnRpY3VsYXIKCXVuZGltZW5zaW9uMSAgZiAoTWtEaW1lbnNp
b25lZCB4KSA9IGYgeDsKCXVuZGltZW5zaW9uMXIgZiB4ID0gTWtEaW1lbnNpb25lZCAodW5kaW1l
bnNpb24xIGYgeCk7Cgl1bmRpbWVuc2lvbjIgIGYgKE1rRGltZW5zaW9uZWQgeCkgKE1rRGltZW5z
aW9uZWQgeSkgPSBmIHggeTsKCXVuZGltZW5zaW9uMnIgZiB4IHkgPSBNa0RpbWVuc2lvbmVkICh1
bmRpbWVuc2lvbjIgZiB4IHkpOwoKCWluc3RhbmNlIChFcSByZXApID0+IEVxIChEaW1lbnNpb25l
ZCBtYXNzIGxlbmd0aCB0aW1lIHJlcCkgd2hlcmUKCQl7CgkJKD09KSA9IHVuZGltZW5zaW9uMiAo
PT0pOwoJCX07CgoJaW5zdGFuY2UgKE9yZCByZXApID0+IE9yZCAoRGltZW5zaW9uZWQgbWFzcyBs
ZW5ndGggdGltZSByZXApIHdoZXJlCgkJewoJCWNvbXBhcmUgPSB1bmRpbWVuc2lvbjIgY29tcGFy
ZTsKCQl9OwoKCWluc3RhbmNlIChTaG93IHJlcCkgPT4gU2hvdyAoVW5pdCByZXApIHdoZXJlCgkJ
ewoJCXNob3cgPSB1bmRpbWVuc2lvbjEgc2hvdzsKCQl9OwoKCWluc3RhbmNlIChOdW0gcmVwKSA9
PiBOdW0gKFVuaXQgcmVwKSB3aGVyZQoJCXsKCQkoKykJCQk9IHVuZGltZW5zaW9uMnIgKCspOwoJ
CSgtKQkJCT0gdW5kaW1lbnNpb24yciAoLSk7CgkJKCopCQkJPSB1bmRpbWVuc2lvbjJyICgqKTsK
CQluZWdhdGUJCT0gdW5kaW1lbnNpb24xciBuZWdhdGU7CgkJYWJzCQkJPSB1bmRpbWVuc2lvbjFy
IGFiczsKCQlzaWdudW0JCT0gdW5kaW1lbnNpb24xciBzaWdudW07CgkJZnJvbUludGVnZXIJPSBN
a0RpbWVuc2lvbmVkIC4gZnJvbUludGVnZXI7CgkJZnJvbUludAkJPSBNa0RpbWVuc2lvbmVkIC4g
ZnJvbUludDsKCQl9OwoKCWluc3RhbmNlIChSZWFsIHJlcCkgPT4gUmVhbCAoVW5pdCByZXApIHdo
ZXJlCgkJewoJCXRvUmF0aW9uYWwgPSB1bmRpbWVuc2lvbjEgdG9SYXRpb25hbDsKCQl9OwoKCWlu
c3RhbmNlIChGcmFjdGlvbmFsIHJlcCkgPT4gRnJhY3Rpb25hbCAoVW5pdCByZXApIHdoZXJlCgkJ
ewoJCSgvKQkJCQk9IHVuZGltZW5zaW9uMnIgKC8pOwoJCXJlY2lwCQkJPSB1bmRpbWVuc2lvbjFy
IHJlY2lwOwoJCWZyb21SYXRpb25hbAk9IE1rRGltZW5zaW9uZWQgLiBmcm9tUmF0aW9uYWw7CgkJ
ZnJvbURvdWJsZQkJPSBNa0RpbWVuc2lvbmVkIC4gZnJvbURvdWJsZTsKCQl9OwoKCWluc3RhbmNl
IChGbG9hdGluZyByZXApID0+IEZsb2F0aW5nIChVbml0IHJlcCkgd2hlcmUKCQl7CgkJcGkJCT0J
TWtEaW1lbnNpb25lZCBwaTsKCQlleHAJCT0JdW5kaW1lbnNpb24xciBleHA7CgkJbG9nCQk9CXVu
ZGltZW5zaW9uMXIgbG9nOwoJCXNxcnQJPQl1bmRpbWVuc2lvbjFyIHNxcnQ7CgkJKCoqKQk9CXVu
ZGltZW5zaW9uMnIgKCoqKTsKCQlsb2dCYXNlCT0JdW5kaW1lbnNpb24yciBsb2dCYXNlOwoJCXNp
bgkJPQl1bmRpbWVuc2lvbjFyIHNpbjsKCQljb3MJCT0JdW5kaW1lbnNpb24xciBjb3M7CgkJdGFu
CQk9CXVuZGltZW5zaW9uMXIgdGFuOwoJCWFzaW4JPQl1bmRpbWVuc2lvbjFyIGFzaW47CgkJYWNv
cwk9CXVuZGltZW5zaW9uMXIgYWNvczsKCQlhdGFuCT0JdW5kaW1lbnNpb24xciBhdGFuOwoJCXNp
bmgJPQl1bmRpbWVuc2lvbjFyIHNpbmg7CgkJY29zaAk9CXVuZGltZW5zaW9uMXIgY29zaDsKCQl0
YW5oCT0JdW5kaW1lbnNpb24xciB0YW5oOwoJCWFzaW5oCT0JdW5kaW1lbnNpb24xciBhc2luaDsK
CQlhY29zaAk9CXVuZGltZW5zaW9uMXIgYWNvc2g7CgkJYXRhbmgJPQl1bmRpbWVuc2lvbjFyIGF0
YW5oOwoJCX07CgkKCWluc3RhbmNlIChSZWFsRnJhYyByZXApID0+IFJlYWxGcmFjIChVbml0IHJl
cCkgd2hlcmUKCQl7CgkJcHJvcGVyRnJhY3Rpb24gKE1rRGltZW5zaW9uZWQgeCkgPSAocCxNa0Rp
bWVuc2lvbmVkIHEpIHdoZXJlCgkJCXsKCQkJKHAscSkgPSBwcm9wZXJGcmFjdGlvbiB4OwoJCQl9
OwoJCXRydW5jYXRlCQk9IHVuZGltZW5zaW9uMSB0cnVuY2F0ZTsKCQlyb3VuZAkJCT0gdW5kaW1l
bnNpb24xIHJvdW5kOwoJCWNlaWxpbmcJCQk9IHVuZGltZW5zaW9uMSBjZWlsaW5nOwoJCWZsb29y
CQkJPSB1bmRpbWVuc2lvbjEgZmxvb3I7CgkJfTsKCQoJaW5zdGFuY2UgKFJlYWxGbG9hdCByZXAp
ID0+IFJlYWxGbG9hdCAoVW5pdCByZXApIHdoZXJlCgkJewoJCWZsb2F0UmFkaXgJCT0gdW5kaW1l
bnNpb24xIGZsb2F0UmFkaXg7CgkJZmxvYXREaWdpdHMJCT0gdW5kaW1lbnNpb24xIGZsb2F0RGln
aXRzOwoJCWZsb2F0UmFuZ2UJCT0gdW5kaW1lbnNpb24xIGZsb2F0UmFuZ2U7CgkJZGVjb2RlRmxv
YXQJCT0gdW5kaW1lbnNpb24xIGRlY29kZUZsb2F0OwoJCWVuY29kZUZsb2F0IHggaQk9IE1rRGlt
ZW5zaW9uZWQgKGVuY29kZUZsb2F0IHggaSk7CgkJZXhwb25lbnQJCT0gdW5kaW1lbnNpb24xIGV4
cG9uZW50OwoJCXNpZ25pZmljYW5kCQk9IHVuZGltZW5zaW9uMXIgc2lnbmlmaWNhbmQ7CgkJc2Nh
bGVGbG9hdCBpCT0gdW5kaW1lbnNpb24xciAoc2NhbGVGbG9hdCBpKTsKCQlpc05hTgkJCT0gdW5k
aW1lbnNpb24xIGlzTmFOOwoJCWlzSW5maW5pdGUJCT0gdW5kaW1lbnNpb24xIGlzSW5maW5pdGU7
CgkJaXNEZW5vcm1hbGl6ZWQJPSB1bmRpbWVuc2lvbjEgaXNEZW5vcm1hbGl6ZWQ7CgkJaXNOZWdh
dGl2ZVplcm8JPSB1bmRpbWVuc2lvbjEgaXNOZWdhdGl2ZVplcm87CgkJaXNJRUVFCQkJPSB1bmRp
bWVuc2lvbjEgaXNJRUVFOwoJCWF0YW4yCQkJPSB1bmRpbWVuc2lvbjJyIGF0YW4yOwoJCX07CgoJ
LS0gWW91IGNhbiBhZGQgb3Igc3VidHJhY3Qgb25seSBpZGVudGljYWxseSBkaW1lbnNpb25lZCBx
dWFudGl0aWVzLgoJcGx1cywgbWludXMgOjogTnVtIHJlcCA9PgoJCURpbWVuc2lvbmVkIG1hc3Mg
bGVuZ3RoIHRpbWUgcmVwIC0+CgkJRGltZW5zaW9uZWQgbWFzcyBsZW5ndGggdGltZSByZXAgLT4K
CQlEaW1lbnNpb25lZCBtYXNzIGxlbmd0aCB0aW1lIHJlcDsKCXBsdXMgIChNa0RpbWVuc2lvbmVk
IHgpIChNa0RpbWVuc2lvbmVkIHkpID0gTWtEaW1lbnNpb25lZCAoeCt5KTsKCW1pbnVzIChNa0Rp
bWVuc2lvbmVkIHgpIChNa0RpbWVuc2lvbmVkIHkpID0gTWtEaW1lbnNpb25lZCAoeC15KTsKCgkt
LSBZb3UgY2FuIG11bHRpcGx5IGFueSB0d28gZGltZW5zaW9uZWQgcXVhbnRpdGllczsgZXhwb25l
bnRzCgktLSBmcm9tIHRoZSBvcGVyYW5kcyBhZGQgdXAgaW4gdGhlIHJlc3VsdC4KCXRpbWVzIDo6
IChOdW0gcmVwLAoJCUFkZCBtYXNzIG1hc3MnIG1hc3MnJywKCQlBZGQgbGVuZ3RoIGxlbmd0aCcg
bGVuZ3RoJycsCgkJQWRkIHRpbWUgdGltZScgdGltZScnKSA9PgoJCURpbWVuc2lvbmVkIG1hc3Mg
bGVuZ3RoIHRpbWUgcmVwIC0+CgkJRGltZW5zaW9uZWQgbWFzcycgbGVuZ3RoJyB0aW1lJyByZXAg
LT4KCQlEaW1lbnNpb25lZCBtYXNzJycgbGVuZ3RoJycgdGltZScnIHJlcDsKCXRpbWVzIChNa0Rp
bWVuc2lvbmVkIHgpIChNa0RpbWVuc2lvbmVkIHkpID0gTWtEaW1lbnNpb25lZCAoeCAqIHkpOwoK
CS0tIFNpbWlsYXJseSBmb3IgZGl2aXNpb24sIGV4Y2VwdCBleHBvbmVudHMgYXJlIHN1YnRyYWN0
ZWQuCglkaXZieSA6OiAoRnJhY3Rpb25hbCByZXAsCgkJU3ViIG1hc3MgbWFzcycgbWFzcycnLAoJ
CVN1YiBsZW5ndGggbGVuZ3RoJyBsZW5ndGgnJywKCQlTdWIgdGltZSB0aW1lJyB0aW1lJycpID0+
CgkJRGltZW5zaW9uZWQgbWFzcyBsZW5ndGggdGltZSByZXAgLT4KCQlEaW1lbnNpb25lZCBtYXNz
JyBsZW5ndGgnIHRpbWUnIHJlcCAtPgoJCURpbWVuc2lvbmVkIG1hc3MnJyBsZW5ndGgnJyB0aW1l
JycgcmVwOwoJZGl2YnkgKE1rRGltZW5zaW9uZWQgeCkgKE1rRGltZW5zaW9uZWQgeSkgPSBNa0Rp
bWVuc2lvbmVkICh4IC8geSk7CgoJLS0gYmFzZSB1bml0cyBhcyBTSS4KCWtpbG9ncmFtbWUJOjog
KE51bSByZXApID0+IE1hc3MgcmVwOwoJa2lsb2dyYW1tZQk9IChNa0RpbWVuc2lvbmVkIDEpOwoJ
bWV0cmUJCTo6IChOdW0gcmVwKSA9PiBMZW5ndGggcmVwOwoJbWV0cmUJCT0gKE1rRGltZW5zaW9u
ZWQgMSk7CglzZWNvbmQJCTo6IChOdW0gcmVwKSA9PiBUaW1lIHJlcDsKCXNlY29uZAkJPSAoTWtE
aW1lbnNpb25lZCAxKTsKCXVuaXQJCTo6IChOdW0gcmVwKSA9PiBVbml0IHJlcDsKCXVuaXQJCT0g
MTsKCX0K
--Emailer_-1224432122
Content-Type: application/octet-stream; name="MarkerType.hs";
x-mac-type="54455854";
x-mac-creator="522A6368"
Content-transfer-encoding: base64
Content-Disposition: Attachment; filename="MarkerType.hs"
LS0gVGhpcyBpcyB3cml0dGVuIGluIEhhc2tlbGwuCm1vZHVsZSBNYXJrZXJUeXBlIHdoZXJlCgl7
CgktLSBCb29sZWFucyBleHByZXNzZWQgYXMgSGFza2VsbCB0eXBlcy4KCWRhdGEgVHJ1ZTsKCWRh
dGEgRmFsc2U7CgkKCWNsYXNzIElzIGE7CglpbnN0YW5jZSBJcyBUcnVlOwoKCWNsYXNzIElzbnQg
YTsKCWluc3RhbmNlIElzbnQgRmFsc2U7CgoJY2xhc3MgRWl0aGVySXMgYSBiOwoJaW5zdGFuY2Ug
RWl0aGVySXMgVHJ1ZSBiOwoJaW5zdGFuY2UgRWl0aGVySXMgRmFsc2UgVHJ1ZTsKCgljbGFzcyBC
b3RoQXJlIGEgYjsKCWluc3RhbmNlIEJvdGhBcmUgVHJ1ZSBUcnVlOwoJCgljbGFzcyBOb3QgYSBi
IHwgYSAtPiBiOwoJaW5zdGFuY2UgTm90IFRydWUgRmFsc2U7CglpbnN0YW5jZSBOb3QgRmFsc2Ug
VHJ1ZTsKCQoJY2xhc3MgT3IgYSBiIGMgfCBhIGIgLT4gYzsKCWluc3RhbmNlIE9yIFRydWUgYiBU
cnVlOwoJaW5zdGFuY2UgT3IgRmFsc2UgYiBiOwoJCgljbGFzcyBBbmQgYSBiIGMgfCBhIGIgLT4g
YzsKCWluc3RhbmNlIEFuZCBUcnVlIGIgYjsKCWluc3RhbmNlIEFuZCBGYWxzZSBiIEZhbHNlOwoK
CXstLQoJSW50ZWdlcnMgZXhwcmVzc2VkIGFzIEhhc2tlbGwgdHlwZXMuIFplcm8gaXMgMC4KCUlm
IHR5cGUgYSBpcyBaZXJvIG9yIHBvc2l0aXZlLCB0aGVuIChTdWNjIGEpIGlzIHBvc2l0aXZlOwoJ
aWYgdHlwZSBhIGlzIFplcm8gb3IgbmVnYXRpdmUsIHRoZW4gKFByZWQgYSkgaXMgbmVnYXRpdmUu
CglUaGlzIGlzIHZlcnkgY3J1ZGUgYW5kIHNob3VsZCBiZSByZXBsYWNlZCB3aXRoIHNpZ24tbWFn
bml0dWRlIAoJcmVwcmVzZW50YXRpb24uCgktLX0KCglkYXRhIFplcm87CglkYXRhIFN1Y2MgbjsK
CWRhdGEgUHJlZCBuOwoKCXR5cGUgT25lID0gU3VjYyBaZXJvOwoJdHlwZSBUd28gPSBTdWNjIE9u
ZTsKCXR5cGUgVGhyZWUgPSBTdWNjIFR3bzsKCXR5cGUgTWludXNPbmUgPSBQcmVkIFplcm87Cgl0
eXBlIE1pbnVzVHdvID0gUHJlZCBNaW51c09uZTsKCXR5cGUgTWludXNUaHJlZSA9IFByZWQgTWlu
dXNUd287CgoJY2xhc3MgU3VjY2Vzc29yIGEgYiB8IGEgLT4gYjsKCWluc3RhbmNlIFN1Y2Nlc3Nv
ciBaZXJvIE9uZTsKCWluc3RhbmNlIFN1Y2Nlc3NvciAoU3VjYyBhKSAoU3VjYyAoU3VjYyBhKSk7
CglpbnN0YW5jZSBTdWNjZXNzb3IgKFByZWQgYSkgYTsKCgljbGFzcyBQcmVkZWNlc3NvciBhIGIg
fCBhIC0+IGI7CglpbnN0YW5jZSBQcmVkZWNlc3NvciBaZXJvIE1pbnVzT25lOwoJaW5zdGFuY2Ug
UHJlZGVjZXNzb3IgKFN1Y2MgYSkgYTsKCWluc3RhbmNlIFByZWRlY2Vzc29yIChQcmVkIGEpIChQ
cmVkIChQcmVkIGEpKTsKCgljbGFzcyBBdExlYXN0IGEgYjsgLS0gYSA+PSBiCglpbnN0YW5jZSBB
dExlYXN0IFplcm8gWmVybzsKCWluc3RhbmNlIEF0TGVhc3QgKFN1Y2MgYSkgWmVybzsKCWluc3Rh
bmNlIEF0TGVhc3QgWmVybyAoUHJlZCBiKTsKCWluc3RhbmNlIEF0TGVhc3QgKFN1Y2MgYSkgKFBy
ZWQgYik7CglpbnN0YW5jZSAoQXRMZWFzdCBhIGIpID0+IEF0TGVhc3QgKFN1Y2MgYSkgKFN1Y2Mg
Yik7CglpbnN0YW5jZSAoQXRMZWFzdCBhIGIpID0+IEF0TGVhc3QgKFByZWQgYSkgKFByZWQgYik7
CgoJY2xhc3MgTmF0dXJhbCBhOwoJaW5zdGFuY2UgTmF0dXJhbCBaZXJvOwoJaW5zdGFuY2UgTmF0
dXJhbCAoU3VjYyBhKTsKCgljbGFzcyBBdExlYXN0T25lIGE7CglpbnN0YW5jZSAoTmF0dXJhbCBh
KSA9PiBBdExlYXN0T25lIChTdWNjIGEpOwoKCWNsYXNzIEV2ZW4gYTsKCWluc3RhbmNlIEV2ZW4g
WmVybzsKCWluc3RhbmNlIChFdmVuIGEpID0+IEV2ZW4gKFN1Y2MgKFN1Y2MgYSkpOwoJaW5zdGFu
Y2UgKEV2ZW4gYSkgPT4gRXZlbiAoUHJlZCAoUHJlZCBhKSk7CgoJLS0gSW50ZWdlciBhZGRpdGlv
bi4gQm90aCBvcGVyYW5kcyBhcmUgZWl0aGVyIHBvc2l0aXZlLCBuZWdhdGl2ZQoJLS0gb3IgemVy
bywgc28gd2UgY29uc2lkZXIgMyozPTkgY2FzZXMuCgljbGFzcyBBZGQgYSBiIGMgfCBhIGIgLT4g
YzsKCglpbnN0YW5jZSBBZGQgWmVybyBaZXJvIFplcm87CgoJaW5zdGFuY2UgQWRkIFplcm8gKFN1
Y2MgYikgKFN1Y2MgYik7CglpbnN0YW5jZSBBZGQgWmVybyAoUHJlZCBiKSAoUHJlZCBiKTsKCglp
bnN0YW5jZSBBZGQgKFN1Y2MgYikgWmVybyAoU3VjYyBiKTsKCWluc3RhbmNlIEFkZCAoUHJlZCBi
KSBaZXJvIChQcmVkIGIpOwoKCWluc3RhbmNlIEFkZCBhIGIgYyA9PiBBZGQgKFN1Y2MgYSkgKFN1
Y2MgYikgKFN1Y2MgKFN1Y2MgYykpOwoJaW5zdGFuY2UgQWRkIGEgYiBjID0+IEFkZCAoUHJlZCBh
KSAoUHJlZCBiKSAoUHJlZCAoUHJlZCBjKSk7CgoJaW5zdGFuY2UgQWRkIGEgYiBjID0+IEFkZCAo
U3VjYyBhKSAoUHJlZCBiKSBjOwoJaW5zdGFuY2UgQWRkIGEgYiBjID0+IEFkZCAoUHJlZCBhKSAo
U3VjYyBiKSBjOwoKCS0tIFN1YnRyYWN0aW9uIGlzIHZlcnkgc2ltaWxhciB0byBhZGRpdGlvbi4K
CWNsYXNzIFN1YiBhIGIgYyB8IGEgYiAtPiBjOwoKCWluc3RhbmNlIFN1YiBaZXJvIFplcm8gWmVy
bzsKCglpbnN0YW5jZSBTdWIgWmVybyAoU3VjYyBiKSAoUHJlZCBiKTsKCWluc3RhbmNlIFN1YiBa
ZXJvIChQcmVkIGIpIChTdWNjIGIpOwoKCWluc3RhbmNlIFN1YiAoU3VjYyBiKSBaZXJvIChTdWNj
IGIpOwoJaW5zdGFuY2UgU3ViIChQcmVkIGIpIFplcm8gKFByZWQgYik7CgoJaW5zdGFuY2UgU3Vi
IGEgYiBjID0+IFN1YiAoU3VjYyBhKSAoU3VjYyBiKSBjOwoJaW5zdGFuY2UgU3ViIGEgYiBjID0+
IFN1YiAoUHJlZCBhKSAoUHJlZCBiKSBjOwoKCWluc3RhbmNlIFN1YiBhIGIgYyA9PiBTdWIgKFN1
Y2MgYSkgKFByZWQgYikgKFN1Y2MgKFN1Y2MgYykpOwoJaW5zdGFuY2UgU3ViIGEgYiBjID0+IFN1
YiAoUHJlZCBhKSAoU3VjYyBiKSAoUHJlZCAoUHJlZCBjKSk7Cgl9Cg==
--Emailer_-1224432122--
From reid@cs.utah.edu Wed Apr 11 04:19:22 2001
From: reid@cs.utah.edu (Alastair Reid)
Date: Tue, 10 Apr 2001 21:19:22 -0600
Subject: Dimensional analysis with fundeps (some physics comments)
In-Reply-To: <200104110116.SAA01777@mail4.halcyon.com>
Message-ID:
> I'm cross-posting this to the Libraries list...
I'm not sure that's an appropriate thing to do.
As I understand it, the libraries list is concerned with libraries which
are currently in the standard, or that are getting stable enough to either add
to the standard or for some non-singular set of compilers to officially
support.
OTOH, the dimensional analysis stuff is not a library, not a proposed library
and, since it seems to be less than a week old, not approaching stability.
--
Alastair Reid