search

mstksg / auto

Haskell DSL and platform providing denotational, compositional api for discrete-step, locally stateful, interactive programs, games & automations. http://hackage.haskell.org/package/auto
MIT License
180 stars 11 forks source link

Preparing v0.3, first breaking update; planned changes #7

Closed mstksg closed 9 years ago

mstksg commented 9 years ago

I'll plan on releasing v0.3 either monday or tuesday; it'll be the first update that breaks backwards compatibility, but I'd rather have these changes come sooner rather than later, while we're still in pre-kinda-release pre-v1.0.

Planned changes for sure, living on 18ab39c, HEAD:

  1. Strict State/Writer for functions in Control.Auto.Effects
  2. New stateA, writerA, readerA

Thanks to @k0001 for proposing and pushing these contributions ( #5 ).

Changes to be tested out still

  1. Regarding #2, changing the name of accum to accuml throughout the library and changing the type signature to accuml :: (a -> b -> b) -> b -> Auto m a b. Currently living on branch at 5c47ca4 . will be testing this out with existing projects to see if the new code is natural enough to warrant this rather large change. Tested and rejected; see #2
  2. New serialization scheme for StdGen; this will break stuff, but might as well do it earlier. rejected

Any comments on these or possible other suggestions before the first breaking updates welcome :)

mstksg commented 9 years ago

Oh... I should probably use this opportunity to update the serialization scheme for StdGen used in Control.Auto.Process.Random too. This will also break existing serialized code, but it might be worth it.

mstksg commented 9 years ago

Looking deeper at the implementation of StdGen, it looks like it hides enough of the constructor to make it really impossible to reliably serialize well in a way that won't break in the future. Right now the only guarantee is that read . show == id...this is the current serialization scheme (serialize the string, read the string). I could guess the format (right now, it's two Int32s tupled together), and serialize it directly (parse the string and serialize the Int32s), and deserialize by reconstructing (showing the two Int32s) through read...it's more costly time-wise but probably sliiiightly cheaper space-wise. But...the "format" of the string might change. The only guarantee of the library is that read.show == id.

So I'm going to stick with the scheme.

Uploading new version when I wake up tomorrow.

mstksg commented 9 years ago

Considering whether or not these now-few breaking changes then are worth a 0.3 update...maybe 0.2.1 is all that is needed?

k0001 commented 9 years ago

Technically, following the Haskell PVP, you should increase to 0.3. I think it's OK to do this; version numbers are cheap and you can increase them whenever is needed. Just keep in mind that, as 'auto' has been on Hackage for only a couple of days and probably has not seen many "real world usage", the APIs are probably still subject to change as people start using it and suggesting changes, and many of those will probably be breaking changes so you will face similar decisions for a while until the API stabilizes while being used by a larger number of people with different needs.

Nevertheless, I should say that you've made a great job with the API, and maybe there won't be that much to change :) Il 01/apr/2015 08:27 "Justin Le" notifications@github.com ha scritto:

Considering whether or not these now-few breaking changes then are worth a 0.3 update...maybe 0.2.1 is all that is needed?

— Reply to this email directly or view it on GitHub https://github.com/mstksg/auto/issues/7#issuecomment-88446115.

mstksg commented 9 years ago

Good call :)

http://hackage.haskell.org/package/auto-0.3.0.0