Abstract records or record interfaces? - haskell

Question

I'm using Haskell to make a game, (this is an assignment, so don't judge me) but I'm facing a problem regarding data types.
So what I want is a data type Entity which has a location, velocity, angle and a rotation speed. A record works very well for this idea:
data Entity = Entity {
location :: Vector,
velocity :: Vector,
angle :: Float,
rotation :: Float
}
Now I want instances of Entity, namely Player Rock Pickup and Bullet. But Players Rocks and Bullets must have an extra field, namely health :: Int, and Pickup must have another extra field, namely pickupType :: PickupType.
But I have certain methods which I want to work on any Entity type. For example:
move :: Entity -> Entity
move e#(Entity {location, velocity, angle, rotation}) = e {location = location + velocity, angle = angle + rotation}
I have no idea how to do this or if this is even possible. I wouldn't understand why if it isn't possible, since this is definitely possible in other languages.
Some attempts and why they aren't quite what I desire:
Attempt 1:
type Player = Player {
e :: Entity,
health :: Int
}
This works, but it is really ugly. This, for example, is how you would move a Player:
movePlayer :: Player -> Player
movePlayer p#(e) = p {e = move e}
Which is just really ugly.
Positives:
Easy to create the abstract class.
Easy to create instances.
Easy abstract methods.
Negatives:
Hard to get or set Entity-implemented fields of an instance.
Attempt 2:
class Entity e where
getLocation :: e -> Vector
getVelocity :: e -> Vector
...
setLocation :: Vector -> e -> e
setVelocity :: Vector -> e -> e
...
data Player = Player {
playerLocation :: Vector,
playerVelocity :: Vector,
...
playerHealth :: Int
}
instance Entity Player where
getLocation = location
getVelocity = velocity
...
setLocation l e = e {location = l}
setVelocity v e = e {playerVelocity = v}
...
move :: (Entity e) => e -> e
move e = (setLocation (getLocation e + getVelocity e) . setAngle (getAngle e + getRotation e)) e
Well it works, but I hope we can all agree that their definitions are now really ugly. The abstract methods which work on any Entity also becomes way ugly. The only good thing is that methods like movePlayer become really easy.
movePlayer :: Player -> Player
movePlayer = move
I don't even need to define movePlayer anymore, since I can just use move.
Positives:
Easy to get or set Entity-implemented fields of an instance.
Negatives:
Hard to create the abstract class.
Even harder to create instances.
Hard abstract methods.
Attempt 3:
Give Entity all fields that any instance needs.
data Entity = Entity {
location :: Vector,
velocity :: Vector,
angle :: Float,
rotation :: Float,
health :: Int,
pickupType :: PickupType
}
This way I don't even need to define instances and I can just use Entity. The only problem is that you have a lot of excess data. This is currently what I use and IMO the best solution for my problem, but I still don't like it.
Positives:
Easy to create the abstract class, even though it isn't really abstract anymore.
No need to define instances.
Easy abstract methods.
Easy to get or set Entity-implemented fields of an instance.
Negatives:
A lot of unused data.
You have to define a lot of nonsense fields every time you create an Entity.
So please help me, I can't find any better methods than these three :(

Answer 1

I would go with your first attempt, for a very simple reason:
It accurately captures the intention of a Player - it's an Entity with additional information.
data Player = Player {
e :: Entity
health :: Int
}
While all functions dealing with may be cumbersome to write at first, you will probably never have to see them again, meaning you provided an abstract enough interface in your code not to access the state of a Player directly.
movePlayer :: Player -> Player
movePlayer p#(e) = p {e = move e}
This function is written once and then ideally you never have to deal with internals again.
Additionally, now you can use type classes as they are intended: you can abstract movePlayer in a separate type class such as Movable:
class Movable m where
move :: m -> m
-- Obviously, you can move entities
instance Movable Entity where
move e = -- stuff
But now it's really easy to move Players too:
instance Movable Player where
move (Player entity health) = Player (move entity) health
-- works, since `Entity` is movable
This aside, your type class approach has a major flaw: What about functions a Player has but an Entity doesn't? In this case you would have Player inherit Entity, like this:
class Entity e => Player e where
-- stuff ...
But since Haskell's type classes are open, anything can become a Player, which is not how it's supposed to work (unless, of course, that is your intention).

Answer 2

I would say that your first attempt is the way to go, for the same reasons as given in #ThreeFx's answer. I'm going to suggest a slightly different alternative though.
Given these types:
data Player = Player {
playerEntity :: Entity,
health :: Int
}
data Pickup = Pickup {
pickupEntity :: Entity,
pickupType :: PickupType
}
Instead of having a separate type class for each action that can be done on an Entity, we can provide generic higher-order functions to make it easier to perform Entity actions on Players and Pickups:
overPlayerEntity :: (Entity -> Entity) -> Player -> Player
overPlayerEntity fn (Player pe h) = Player (fn pe) h
overPickupEntity :: (Entity -> Entity) -> Pickup -> Pickup
overPickupEntity fn (Pickup pe t) = Pickup (fn pe) t
Now, we can have
movePlayer = overPlayerEntity move
movePickup = overPickupEntity move
We can also wrap this up into a type class to make it easier to write generic code as well:
class HasEntity a where
overEntity :: (Entity -> Entity) -> a -> a
instance HasEntity Player where overEntity = overPlayerEntity
instance HasEntity Pickup where overEntity = overPickupEntity
This allows things like:
move' :: HasEntity a => a -> a
move' = overEntity move
which works with both Players and Pickups. This eliminates the need for a specialized version of functions like move and at the same time we only need to write the Entity access boilerplate once.
Incidentally, this over...Entity way of doing things is approaching the "lens" technique mentioned at the end of #duplode's and #Paul Johnson's answers. These are essentially two (very) specialized lenses. If we add in the HasEntity type class it gives us what might be called a "classy lens" (this is sort of the terminology used in the lens library). You don't really need to worry about what the general lens concept means or entails, but this could give you an entry point to learn about lenses in the future.

Answer 3

You could just use a sum (aka "union") type.
data Entity =
Player {
location :: Vector,
-- etc.
health :: Int }
| Pickup {
location :: Vector,
-- etc.
pickupType :: PickupType}
You can factor this out by just having the sum type hold the data that varies.
This has the advantage that you can have a [Entity], which is something you can't do when all the different variations of Entity are different types (unlike OO languages).
Depending on your game model you might also want to separate the location and velocity data from the rest of the player information. Could that data be better held in some kind of spatial data structure like a quadtree? That way you can keep the constant data separate from the stuff that changes with every frame.
One thing you ought to look at are lenses, which exist to solve the problem you describe with lots of getters and setters.

Answer 4

This is more of a long comment than an answer, as the core of what I was going to write is covered well enough by ThreeFx's answer.
Firstly, avoid using OOP jargon, as it will lead to confusion. In your attempt #1, Entity is a data type, not a class, and it is not abstract either. The relationship between Player and Entity in attempt #1 is merely one of composition: a Player has an Entity, and it is not in any way an instance of Entity.
Secondly, record update syntax is quite ugly in Haskell. That doesn't make it complicated, just a little cumbersome. So when you say e.g. "Hard to get or set Entity-implemented fields of an instance", it is not actually hard, just not too pretty. That is not a serious enough concern to determine the design of your data types.
Thirdly, lenses are a way of (among many other things) avoiding the ugliness of the record update syntax. You probably won't want to dive into that right now (wait at least until you have finished your assignment), but I can't resist leaving a link to a highly relevant tutorial for you to read at some point in the future: Program imperatively using Haskell lenses.