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 t
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 te
Hello,
I see now what you meant, thanks for the explanation.
I find the argument a bit disturbing, as it seems to imply that
it is OK for the compiler to produce code without any context switches
at all
(after all none of the context swicthes are guaranteed to happen :-).
I guess this is not true
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 se
On Fri, 12 Nov 2004, John Goerzen wrote:
> On 2004-11-12, Henning Thielemann <[EMAIL PROTECTED]> wrote:
> >
> > test3 :: Int -> (Int -> String) -> String
> >
> > ?
>
> Yes.
>
> > Then the implementation could be written as
> >
> > test3 x f = (show x ++) . f
>
> Tried that, but:
Sorry, it mus
On 2004-11-12, Henning Thielemann <[EMAIL PROTECTED]> wrote:
>
> On Fri, 12 Nov 2004, John Goerzen wrote:
>
>> I like the partial application feature (and used it in test1). So, I
>> thought I could use that to my advantage in test3 and test4:
>>
>> test3 :: Int -> Int -> String
>> test3 x f = (s
On Fri, 12 Nov 2004, John Goerzen wrote:
> I like the partial application feature (and used it in test1). So, I
> thought I could use that to my advantage in test3 and test4:
>
> test3 :: Int -> Int -> String
> test3 x f = (show x) ++ f
You mean
test3 :: Int -> (Int -> String) -> String
?
T
I'm trying to do something -- I think it's called uncurrying. I've
boiled up a little test case to show what I mean:
test1 :: Int -> String
test1 = show
test2 :: Int -> Int -> String
test2 x y = (show x) ++ (show y)
OK, that works OK. Now let's say I want to provide a function that
generates t
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?
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 :
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. 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
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 evi
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 <-,
> 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
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 see
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
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
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 si
19 matches
Mail list logo
