At 00:10 12/11/04 +0100, karczma wrote:
But it was MUCH more important to repeat the same
sequence, e.g., after making fast some nice fractal sketch, I relaunched
the program with bigger size/precision, but exploiting the same random
sequence. I repeat, such is my philosophy.
I agree. I've used
At 16:07 11/11/04 +, Keith Wansbrough wrote:
Graham Klyne wrote:
At 12:27 11/11/04 +, Ben Rudiak-Gould wrote:
[..]
going to be safe, because it's just not the case that
x = once (newIORef ())
y = x
has the same intended meaning as
x = once (newIORef ())
y =
Adrian Victor CRISCIU wrote:
Thanks for the advice. However, though I don't know how ghc manages
the heap, I am not sure it is possible to achieve constant heap
usage, because a value of type State is a function, and = is
creating a call stack in this case. I mean, I think that, even if the
Hi,
Sorry, but I don't really get the point of the discussion so far. I think any
computation should be done in pure functional style, that gets a random
generator (seed) and passes it around. Your program starts in the IO monad
anyway, so you have the choice of using newStdGen to get a new
So you say (and I do agree). But how can I *observe* that they are the same?
Well, not with a single program run (obviously). But it is the case
that for any program P and input sequence X (i.e., keys
pressed):
running P with X
and
running {foo = getChar; P'} with X (where P' is P with all
On Thursday 11 Nov 2004 12:27 pm, Ben Rudiak-Gould wrote:
On the other hand, these are perfectly safe:
once' :: IO a - IO (IO a)
oncePerString :: String - IO a - IO a
oncePerType :: Typeable a = IO a - IO a
once' seems virtually useless unless you have top-level -, but the
Adrian Hey wrote:
The latter is probably true, in a strict technical sense. But I can't
see a way to live without them and keep modularity. In any case,
I don't think there's any reason to force programmers wear the hair
shirt in this respect (other than dogma and superstitious fear about
the
Should values really depend on the order of includes? Even if you limit
things to just
newChan in top level '-' you still don't know if A.a in B the same A.a
in C. Perhaps it
is enough to say A.a only exists once no matter how many times it is
directly or
indirectly imported?
This strikes me
This still has a problem. Lets say B implements some useful function that
relies on A. Now also C implements some different useful function and also
relies on A in its implementation. If there is only one A.a then using
both B
and C features in the same code will potentally break both B and C.
On Fri, 12 Nov 2004 14:53:33 +, Adrian Hey [EMAIL PROTECTED] wrote:
On Thursday 11 Nov 2004 12:27 pm, Ben Rudiak-Gould wrote:
On the other hand, these are perfectly safe:
once' :: IO a - IO (IO a)
oncePerString :: String - IO a - IO a
oncePerType :: Typeable a = IO
Hello,
Ben Rudiak-Gould wrote:
...
I would say that the law holds in one direction and not the other.
It's safe to replace
do x - readSTRef r
y - readSTRef r
with
do x - readSTRef r
let y = x
but not the other way around.
How can things be equal the one way and not the other?
I
Iavor S. Diatchki wrote:
Ben Rudiak-Gould wrote:
I would say that the law holds in one direction and not the other. [...]
How can things be equal the one way and not the other?
Saying that two things are equal means (in this context) that either can
be replaced by the other without changing the
At 10:35 10/11/04 -0800, Iavor S. Diatchki wrote:
Hello,
Concurrency in Haskell (technically GHC) is much like concurrency in other
languages,
in that you fork off threads and do stuff with them, etc. I think you are
perhaps thinking of another kind of concurrency, where different redexes in
a
On Friday 12 Nov 2004 3:20 pm, Keean Schupke wrote:
Adrian Hey wrote:
The latter is probably true, in a strict technical sense. But I can't
see a way to live without them and keep modularity. In any case,
I don't think there's any reason to force programmers wear the hair
shirt in this
14 matches
Mail list logo
