2014-10-15 17:14:52 +0000 <joneshf-laptop> Bodil, sorry, i never really responded to what i meant
2014-10-15 17:17:13 +0000 <joneshf-laptop> Bodil, sure, it could be converted to ps, but what i meant was using some of the ideas in ps to implement it.
2014-10-15 17:17:27 +0000 <joneshf-laptop> like it seems like `Signal` is comonadic
2014-10-15 17:17:36 +0000 <joneshf-laptop> and if not comonadic it seems at least extendable
2014-10-15 17:17:48 +0000 <joneshf-laptop> in particular it looks like costore
2014-10-15 17:17:52 +0000 <joneshf-laptop> erm
2014-10-15 17:17:53 +0000 <joneshf-laptop> stor
2014-10-15 17:17:54 +0000 <joneshf-laptop> bleh
2014-10-15 17:17:56 +0000 <joneshf-laptop> `Store`
2014-10-15 17:19:06 +0000 <Bodil> joneshf-laptop: I'd definitely be open to exploring that. On the other hand, I need the core lib to be very compact, I've been very wary of adding dependencies to it.
2014-10-15 17:19:09 +0000 <joneshf-laptop> or i guess `StoreT` with a `Comonad` for dealing with the subscriptions and stuff
2014-10-15 17:19:26 +0000 <Bodil> But anything not in the actual Signal.purs file is fair game for adding stuff. :)
2014-10-15 17:19:58 +0000 <paf31> i'd be interested in trying to convert some of the js code to purescript
2014-10-15 17:20:08 +0000 <joneshf-laptop> Bodil, fair enough
2014-10-15 17:20:09 +0000 <paf31> and possibly trying to reduce the use of "constant"
2014-10-15 17:20:16 +0000 <paf31> the key is keeping the performance, i guess
2014-10-15 17:20:17 +0000 <Bodil> I'd be interested in seeing the results. :)
2014-10-15 17:20:34 +0000 <paf31> something like ContT is probably too heavy
2014-10-15 17:21:28 +0000 <joneshf-laptop> Bodil, in that light, since `Store` is the data type version of the idea of lenses, you could go with lenses since they're just type synonyms and not have any extra dependencies
2014-10-15 17:21:35 +0000 <Bodil> Both performance and code size are priorities for me. But neither would necessarily be a problem with a PS version.
2014-10-15 17:21:43 +0000 <paf31> i was thinking that one way might be to implement a Subject class in JS, write an FFI for it using Eff, and then to express the other stuff using that
2014-10-15 17:21:43 +0000 <joneshf-laptop> though if performance is also an issue you probably wnat to wait until we get inlining pragmas
2014-10-15 17:21:59 +0000anonv10(~anonv10@23.30.35.81)
2014-10-15 17:22:06 +0000 <joneshf-laptop> paf31, fresheyeball has some ooffi stuff
2014-10-15 17:22:10 +0000 <paf31> doesn't lens pull in the entire package universe? :P
2014-10-15 17:22:11 +0000 <joneshf-laptop> might be helpfulthere
2014-10-15 17:22:18 +0000 <paf31> joneshf-laptop: yeah definitely
2014-10-15 17:22:30 +0000 <joneshf-laptop> paf31, sure, lens does, but the type synonyms it defines can be used by anyone
2014-10-15 17:22:36 +0000 <paf31> ah
2014-10-15 17:22:42 +0000 <Bodil> Also, kmettification is always a good thing. :)
2014-10-15 17:22:42 +0000 <joneshf-laptop> without the lens dep
2014-10-15 17:22:51 +0000 <Bodil> Would really like to explore lenses in this context, actually.
2014-10-15 17:23:20 +0000 <paf31> kmettification must be left adjoint to something
2014-10-15 17:23:27 +0000 <joneshf-laptop> paf31, also i'm going to split the lens package up one of these days
2014-10-15 17:38:51 +0000 <joneshf-laptop> paf31, actually that's a good point