Tue, 15 Feb 2000 18:57:51 +0100, George Russell <[EMAIL PROTECTED]> pisze:
> > The requirement could be even stronger, that the integers are
> > increasing, so one can compare relative time of IO events without
> Absolutely not. If you have 5000 processors, how are they to work out
> which one did an IO event first? I don't really see the point anyway.
...relative time of IO events that occured in a single thread.
(>>=) imposes the sequencing.
Or maybe more: including also the order of events in different threads
that were sequenced by MVar operations.
It seems easy to promise anyway, at least the first. A global counter,
either protected by MVar, which gives also the second, or separate
for each thread, which does not and may be faster but I guess requires
support in the compiler itself, not only libraries.
BTW: The random generator from the IO monad seems to be not
thread-safe. Oops. I think it should be either fixed or documented.
> I definitely prefer my abstract "Unique" type. Easy to implement
> efficiently on any conceivable system.
AFAIK Tcl requires inventing window identifiers, which should be unique
if I want fresh windows. TclHaskell frees the programmer from the
requirement to do it himself, maintaining its own unique supply. It
uses its own monad, IO with state. In some cases it would be very
inconvenient to require the user of a library to use a different
monad *only* because the library needs a supply of unique strings!
> Also it means whoever writes the definition doesn't have to worry
> about whether to use "Int" or "Integer". (If someone writes a
> server in Haskell which manages to stay up for years it could very
> easily overflow Int . . .)
That's why I said Integer, not Int :-)
--
__("< Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/ GCS/M d- s+:-- a22 C+++$ UL++>++++$ P+++ L++>++++$ E-
^^ W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK 5? X- R tv-- b+>++ DI D- G+ e>++++ h! r--%>++ y-
