--- BEGIN NOSTALGIA ---
Well, I have to add to this, that when I coded my first games in assembler
in the eighties, I did exactly the same thing: just recording the input of
the joystick was enough to get full replays and make auto playing demos.
But on the old computers, this was all so easy,
On Wed, Oct 7, 2009 at 10:05 AM, Peter Verswyvelen bugf...@gmail.com wrote:
over every bit of the system (it was even easy to count exactly how many
cycles a routine would take :-), so it was just a matter of starting the
You sound like you used to code on the Commodore 64 :)
David.
Peter Verswyvelen bugf...@gmail.com writes:
So yes, without using IO, Haskell forces you into this safe spot
One could argue that IO should be broken down into a set of sub-monads
encapsulating various subsets of the functionality - file system,
network access, randomness, and so on. This
Or you can use an effect system (however that doesn't give you the
opportunity of overriding IO functions, but I think that providing
such an opportunity with the means you suggest (splitting IO into many
sub-monads) is not going to be usable in the large scale)
By the way, I am surprised that
On Tue, 2009-10-06 at 13:22 -0700, Michael P Mossey wrote:
Duncan Coutts wrote:
So you end up with pure functions like:
shuffle :: RandomGen g = g - [x] - [x]
Thanks for the help, Duncan. I'm confused on one point. Don't you always need
the new state of the generator back? So
Yep. Commodore 64, Amiga. I really loved those machined, especially the
Amiga (mmm, maybe someone should port a Haskell compiler to the Amiga. ha,
how nerdy can one get? ;-)
On Wed, Oct 7, 2009 at 10:50 AM, David Virebayre
dav.vire+hask...@gmail.comdav.vire%2bhask...@gmail.com
wrote:
On Wed,
On Wed, Oct 7, 2009 at 11:13 AM, Ketil Malde ke...@malde.org wrote:
One could argue that IO should be broken down into a set of sub-monads
encapsulating various subsets of the functionality - file system,
network access, randomness, and so on. This could extend the safe
spot to cover much
Hello Peter,
Wednesday, October 7, 2009, 2:04:49 PM, you wrote:
afair, nhc was started there. it was a small compiler exactly because
Amiga was a rather small computer (comapred to RISC stations)
Yep. Commodore 64, Amiga. I really loved those machined, especially
the Amiga (mmm, maybe someone
afair, nhc was started there. it was a small compiler exactly because
Amiga was a rather small computer (comapred to RISC stations)
nhc12 (for Haskell 1.2) was first developed on an Acorn Archimedes
with 2Mb of RAM, under RiscOS.
Regards,
Malcolm
On Oct 7, 2009, at 3:13 AM, Ketil Malde wrote:
Peter Verswyvelen bugf...@gmail.com writes:
So yes, without using IO, Haskell forces you into this safe spot
One could argue that IO should be broken down into a set of sub-
monads
encapsulating various subsets of the functionality - file
It's a complex area not a lot of people are working in. Similar
(actually worse than) dependent typing.
Regards,
John A. De Goes
N-Brain, Inc.
The Evolution of Collaboration
http://www.n-brain.net|877-376-2724 x 101
On Oct 7, 2009, at 3:32 AM, Eugene Kirpichov wrote:
Or you can
On 7 Oct 2009, at 15:04, John A. De Goes wrote:
On Oct 7, 2009, at 3:13 AM, Ketil Malde wrote:
Peter Verswyvelen bugf...@gmail.com writes:
So yes, without using IO, Haskell forces you into this safe spot
One could argue that IO should be broken down into a set of sub-
monads
Excerpts from Ketil Malde's message of Wed Oct 07 05:13:19 -0400 2009:
One could argue that IO should be broken down into a set of sub-monads
encapsulating various subsets of the functionality - file system,
network access, randomness, and so on. This could extend the safe
spot to cover much
Duncan Coutts wrote:
So you end up with pure functions like:
shuffle :: RandomGen g = g - [x] - [x]
Thanks for the help, Duncan. I'm confused on one point. Don't you always need
the new state of the generator back? So wouldn't this need to be:
shuffle :: RandomGen g = g - [x] - (g,[x])
On Mon, Oct 05, 2009 at 07:24:00AM -0700, Michael Mossey wrote:
If I understand correctly, this works because IO is an instance of
Applicative, correct?
I wonder if any of the random monads are instances of Applicative.
If they aren't then that's a bug in the library :). Every monad
can be
Michael P Mossey wrote:
Also note that I added the Random class constraint to 'shuffle'. I
haven't tested this but it might be necessary. Or not?
Okay I figured this part out too. The members of the list you are shuffling have
no class constraint on them because the 'shuffle' function is not
Eugene Kirpichov wrote:
[x,y,t,b,l,r] - mapM (getStdRandom . randomR) [(-10,10), (-70,70), ...]
return (BoxBounds ...)
Thanks.
I'm curious about the idea of pattern matching in do-statements that can
fail. This particular pattern cannot fail. I read that the fail function
was introduced
If I understand correctly, this works because IO is an instance of
Applicative, correct?
I wonder if any of the random monads are instances of Applicative.
Felipe Lessa wrote:
On Sun, Oct 04, 2009 at 01:55:11PM +0400, Eugene Kirpichov wrote:
[x,y,t,b,l,r] - mapM (getStdRandom . randomR)
2009/10/5 Michael Mossey m...@alumni.caltech.edu:
Eugene Kirpichov wrote:
[x,y,t,b,l,r] - mapM (getStdRandom . randomR) [(-10,10), (-70,70), ...]
return (BoxBounds ...)
Thanks.
I'm curious about the idea of pattern matching in do-statements that can
fail. This particular pattern cannot
Am Montag 05 Oktober 2009 16:22:15 schrieb Michael Mossey:
Eugene Kirpichov wrote:
[x,y,t,b,l,r] - mapM (getStdRandom . randomR) [(-10,10), (-70,70), ...]
return (BoxBounds ...)
Thanks.
I'm curious about the idea of pattern matching in do-statements that can
fail. This particular pattern
I'm looking for a hint to write the following code with less redundancy. I
have a constructor called BoxBounds, and I want to make one with random
values.
randomBox :: IO BoxBounds
randomBox = do
x - getStdRandom (randomR (-10,10))
y - getStdRandom (randomR (-70,70))
t - getStdRandom
[x,y,t,b,l,r] - mapM (getStdRandom . randomR) [(-10,10), (-70,70), ...]
return (BoxBounds ...)
2009/10/4 Michael Mossey m...@alumni.caltech.edu:
I'm looking for a hint to write the following code with less redundancy. I
have a constructor called BoxBounds, and I want to make one with random
On Sun, Oct 04, 2009 at 01:55:11PM +0400, Eugene Kirpichov wrote:
[x,y,t,b,l,r] - mapM (getStdRandom . randomR) [(-10,10), (-70,70), ...]
return (BoxBounds ...)
import Control.Applicative
let f = getStdRandom . randomR
g1 = \x - f (-x,x)
g2 = f (5,10)
in BoxBounds $ g1 10 * g1 70 * g2
On Sun, 2009-10-04 at 02:52 -0700, Michael Mossey wrote:
I'm looking for a hint to write the following code with less redundancy. I
have a constructor called BoxBounds, and I want to make one with random
values.
randomBox :: IO BoxBounds
randomBox = do
x - getStdRandom (randomR (-10,10))
Duncan Coutts wrote:
On Sun, 2009-10-04 at 02:52 -0700, Michael Mossey wrote:
I'm looking for a hint to write the following code with less redundancy. I
have a constructor called BoxBounds, and I want to make one with random
values.
randomBox :: IO BoxBounds
randomBox = do
x - getStdRandom
On Sun, 2009-10-04 at 05:11 -0700, Michael Mossey wrote:
Duncan Coutts wrote:
Others have already answered but I'd like to suggest that you avoid
using IO here. There's no need for this to be impure.
Can you point me to a tutorial that covers the basics of randomness in
Hasell? I find it
And, to go further, once you embrace determinism in your randomness, you
can do all sorts of really cool things.
From the perspective of a games programmer:
You can run the same simulation code on two different network nodes, and
reliably get the same result, allowing you to just transfer user
27 matches
Mail list logo
