WIP remove MonadIO requirement#80
Conversation
|
@jonascarpay This is just a start! But maybe you can have a look at the changes to Core.hs and Stores.hs to see if I'm on the right track. |
apecs/src/Apecs/Core.hs
Outdated
| -- | Writes a component to the store. Returns @Just@ a new store if the store | ||
| -- has changed. If the store is mutable and only undergoes internal mutation, | ||
| -- then you can safely return @Nothing@ | ||
| explSet :: s -> Int -> Elem s -> m (Maybe s) |
There was a problem hiding this comment.
I just realized the Maybe is a premature optimization, here and in explDestroy. I may just drop it and and return m s. That should simplify some other changes.
|
The crux of the issue for me is this:
If this is true, this would be a clear win. I'm not sure whether or not it is true though; for IntMaps the overhead is small, but for a mutable cache it might be a lot bigger. I don't know if GHC manages to optimize a State that doesn't change to the same performance as a Reader. How far from actually compiling is this (also why is there no CI :S)? I'd love to see some performance numbers. Somwhat related; one thing I'm experimenting with is rewriting e.g. class Get m c where
get :: Entity -> m cwhich would allow the same thing since |
|
I've almost got this building now. I just need to get TH to create the world init function to be in |
|
I think I've introduced some bugs :-( e.g. |
I'm seeing similar results here #72 (comment). The way the benchmark numbers work out can be kind of weird. As long as the total time is still lower, I think it's fine. What kind of |
2 participants
This is intended to allow both pure and impure stores (and hence underlying monad) to be used under the hood. I think most stores can be made pure with little performance hit as updating the world record will be fast compared to updating the store itself (e.g. updating an IntMap). This should allow the whole world to be expressed as an immutable data type.