RE: [Haskell-cafe] RE: [Haskell] Making 'Super Nario Bros' in Haskell

[Eli Ford]

> > Is there a better way than IORefs
> >
> The state Monad.

Do you mean one state shared among all actors, like this?

type MGame = State GameState
newtype GameState = GameState {  }

That gets part of the way, but I'm thinking of a situation where each
instance of a particular type of actor can have its own reference to
some other actor:

newtype Watcher = Watcher {
otherActor :: IORef ActorWrapper
}

(Here, ActorWrapper is an existential type that hides a specific actor
type.)

I started writing a game using IORefs that way, allowing actors to see
and cause changes in each other, but in the back of my mind I wonder if
this is a symptom of a C++ background.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] RE: [Haskell] Making 'Su per Nario Bros.' in Haskell‏

[Eli Ford]

That’s great -- easy to follow, even though I can’t read the comments.  ^^

 

It’s not possible for actors to ‘watch’ each other in this system, correct?  
For instance, if one actor holds a reference to another, it will keep that old 
version of the actor alive, but it won’t see when the actor moves.

 

This game doesn’t seem to need actors that watch each other, but it’s very 
common in games.  I’ve been using IORefs for that purpose, but I like how pure 
the Mario game is.  Is there a better way than IORefs?

 



From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Korcan Hussein
Sent: Wednesday, October 29, 2008 4:57 PM
To: [EMAIL PROTECTED]
Subject: [Haskell] Making 'Super Nario Bros.' in Haskell‏

 

Hi I haven't seen this posted any where so I'm sorry in advance if this has 
been mentioned already but I came across this recent video on youtube: 
http://uk.youtube.com/watch?v=gVLFGQGRsDw it's a mario clone written in haskell 
with a link to source code repository 
(http://svn.coderepos.org/share/lang/haskell/nario/). I thought that it maybe 
useful to some people.

Trustworthiness:

Vendor reliability:

Privacy:

Child safety:

 



For the best free wallpapers from MSN Click here! 
 

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

RE: [Haskell-cafe] computational overhead of the "data" declarations

[Eli Ford]

> So, to answer your question, the only computational overhead with a
> data declaration is the extra memory and time to store and process the
> constructor tags.  It usually isn't noticeable, but sometimes the
> difference can be important.

Is there also potentially overhead due to laziness?  I mean, in this
case:

newtype Fast = Fast Int

If you have a Fast value, you know you've got a real Int, not a thunk,
right?  But here:

data Slow = Slow Int

Doesn't a Slow value remain unevaluated until you pattern match out the
Int?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe