auto 0.2.0.2 → 0.2.0.3
raw patch · 6 files changed
+39/−12 lines, 6 filesPVP: minor bump suggested
API additions: PVP suggests at least a minor version bump
API changes (from Hackage documentation)
+ Control.Auto: (-?>) :: Monad m => Interval m a b -> Interval m a b -> Interval m a b
+ Control.Auto: fromInterval :: a -> Auto m (Maybe a) a
Files
- CHANGELOG.md +9/−0
- README.md +19/−10
- auto.cabal +4/−1
- src/Control/Auto.hs +2/−0
- src/Control/Auto/Collection.hs +1/−1
- src/Control/Auto/Effects.hs +4/−0
CHANGELOG.md view
@@ -1,3 +1,12 @@+0.2.0.3+-------+<https://github.com/mstksg/auto/releases/tag/v0.2.0.3>++* Bug for `dynZipF` fixed, where newly added `Auto`s would overwrite ones+ alreay stored.+* `fromInterval` added to `Control.Auto`'s exports.++ 0.2.0.2 ------- <https://github.com/mstksg/auto/releases/tag/v0.2.0.2>
README.md view
@@ -275,16 +275,6 @@ [frp]: http://en.wikipedia.org/wiki/Functional_reactive_programming [netwire]: https://hackage.haskell.org/package/netwire -Open questions-----------------* In principle very little of your program should be over `IO` as a- monad...but sometimes, it becomes quite convenient for abstraction- purposes. Handling IO errors in a robust way isn't quite my strong point,- and so while almost all `Auto` idioms avoid `IO` and runtime, for some- applications it might be unavoidable. Providing industry-grade tools for- making `IO` robust would be a good next priority.- A chatbot --------- @@ -405,3 +395,22 @@ chatBotSerialized :: ChatBot IO chatBotSerialized = serializing' "data.dat" chatBot ~~~++Open questions+--------------++* In principle very little of your program should be over `IO` as a+ monad...but sometimes, it becomes quite convenient for abstraction+ purposes. Handling IO errors in a robust way isn't quite my strong point,+ and so while almost all `Auto` idioms avoid `IO` and runtime, for some+ applications it might be unavoidable. Providing industry-grade tools for+ making `IO` robust would be a good next priority.++* "Safecopy problem"; serialization schemes are implicitly derived, but if+ your program changes, it is unlikely that the new serialization scheme+ will be able to resume something from the old one. Right now the solution+ is to only serialize small aspects of your program that you *can* manage+ and manipulate directly when changing your program. A better solution+ might exist.++* Tests; tests aren't really done yet, sorry! Working on those :)
auto.cabal view
@@ -1,5 +1,5 @@ name: auto-version: 0.2.0.2+version: 0.2.0.3 synopsis: Denotative, locally stateful programming DSL & platform description: (Up to date documentation is maintained at <https://mstksg.github.com/auto>)@@ -33,6 +33,9 @@ <https://github.com/mstksg/auto-examples auto-examples> repository on github for plenty of real-world and toy examples to learn from!+ .+ Support available on freenode's #haskell, and also on+ the github's issue tracker. . Import "Control.Auto" to begin!
src/Control/Auto.hs view
@@ -98,6 +98,7 @@ , count -- ** Switches , (-->)+ , (-?>) -- ** Blips , emitJusts , emitOn@@ -113,6 +114,7 @@ , during , off , toOn+ , fromInterval -- * Running , interactAuto , interactRS
src/Control/Auto/Collection.hs view
@@ -453,7 +453,7 @@ -> (IntMap a, Blip [k]) -> m (IntMap b, Auto m (IntMap a, Blip [k]) (IntMap b)) _dynMapF f x0 go i ks as (xs, news) = do- let newks = zip [1..] (blip [] id news)+ let newks = zip [i..] (blip [] id news) newas = (map . second) f newks newks' = ks `IM.union` IM.fromList newks newas' = as `IM.union` IM.fromList newas
src/Control/Auto/Effects.hs view
@@ -263,6 +263,10 @@ -- stream is the result of running the stream through @f@, first with an -- initial state of @s0@, and afterwards with each next updated state. --+-- This can be extended to sealing 'RandT' from the /MonadRandom/ package+-- as well, as long as you 'hoistA' first with @'StateT' . 'runRandT'@.+--+-- sealState :: (Monad m, Serialize s) => Auto (StateT s m) a b -> s