I did totally miss this post, like any other post on this mailing list over the last year probably.
Totally agree with your remarks on Task, once I look into IO/Async I'll make you review the stuff if you don't mind (ideally a google hangout would be even better), but for now I'm experimenting with lenses. About liftCvf and Maybe, here is a PR that implement the change you suggest: https://github.com/scalaz/scalaz/pull/1232 ... I'm all for it. On Sunday, 5 June 2016 15:38:28 UTC+2, Brian McKenna wrote: > > I was in the middle of Tasmania last week, sorry for not being able to > make the meeting! > > I've had bugs in every project that I've worked on which used Task, > due to the API. Some problems I remember: > > 1. Confusion around differences in Task.delay, Task.apply, Task.now > 2. Implicit ExecutorService > 3. Implicit Strategy > 4. Side-effect (during initialisation of the Strategy companion object) > > > https://github.com/scalaz/scalaz/blob/scalaz-seven/concurrent/src/main/scala/scalaz/concurrent/Strategy.scala#L25 > > > 5. Non-parametric type: > > > https://github.com/scalaz/scalaz/blob/scalaz-seven/concurrent/src/main/scala/scalaz/concurrent/Strategy.scala#L15 > > > Now, we could just fix each of the above problems, and whatever others > people have, but I question why Task should be used at all. The teams > I work with try to use Task as a replacement for scalaz.effect.IO > because it has a couple of primitive concurrency combinators. > > I wonder if it'd be more useful to add concurrency combinators to > scalaz.effect.IO instead. I've had a go at a start: > > > https://github.com/scalaz/scalaz/compare/series/7.3.x...puffnfresh:feature/concurrent-io > > > I think this is a reasonable direction. I would like either scalaz 7.4 > or scalaz 8.0 to provide all the combinators for replacing > scalaz.concurrent.Task with scalaz.effect.IO but I have questions: > > * Do people use Task for other reasons? > * What API would people need to be able to replace Task with IO? > * Does IO give less performance for these things than Task? > > Outside of IO, I think the rest of Tony's Gist looks great. I would > like to advocate "liftCvf" existing, as described in Stephen Compall's > "When can Liskov be lifted?" post: > > http://typelevel.org/blog/2014/03/09/liskov_lifting.html > > With that combinator, we should be able to write an invariant Maybe > data type, which shares a singleton Empty object: > > private case object Empty extends Maybe[Nothing] > > object Maybe { > def empty[A]: Maybe[A] = > Liskov.liftCvf(isa[A, Nothing])(Empty) > > implicit def MaybeFunctor: Functor[Maybe] = > ??? > } > > Maybe.empty should be a full Prism, but hopefully you get the idea. > Using this single Liskov combinator should be theoretically sound, > although the implementation would be a cast. I think it is necessary > if we want to "do better than scala-library.jar" in terms of > performance and memory consumption. > > On 30 May 2016 at 08:15, Tony Morris <[email protected] <javascript:>> > wrote: > > I took some notes yesterday. I hope it's OK putting them here. > > > > https://gist.github.com/tonymorris/0ebc6eff79b99469a58c9cab92a6637e > > > > On Thu, May 26, 2016 at 2:27 PM, Vincent Marquez <[email protected] > <javascript:>> > > wrote: > >> > >> Hi everyone, > >> > >> I talked to John, we can use a room Saturday evening ~ 6:00 pm Mountain > >> Time (thanks Stephen). I'll do my best to make sure we can google > >> hangouts/skype (or other suggestions?) others who are interested in > >> participating in the discussion. > >> > >> --Vincent > >> > >> On Sun, May 22, 2016 at 8:50 AM, Stephen Compall <[email protected] > <javascript:>> > >> wrote: > >>> > >>> On May 17, 2016 3:25:18 PM EDT, Vincent Marquez > >>> <[email protected] <javascript:>> wrote: > >>> >He has also mentioned this could be either a private event, or > >>> >something > >>> >open to the public that he'd announce (if we wish) on the website. > >>> > >>> I'm happy to have an announcement, as long as it is called > "contributors' > >>> meeting" or what have you. > >>> > >>> >Since there seems enough interest, the main thing to decide is when: > >>> > > >>> >Wednesday May 25th during the day central time. > >>> >Sunday May 29th in the AM central time. > >>> >Saturday May 28th at ~7 PM central time (?). > >>> > >>> I can only make Saturday of these times, so I vote for that. > >>> > >>> NB: Boulder is in mountain time, which is one hour behind central. > >>> > >>> > >>> -- > >>> Stephen Compall > >>> If anyone in the MSA is online, you should watch this flythrough. > >> > >> > >> -- > >> You received this message because you are subscribed to the Google > Groups > >> "scalaz" group. > >> To unsubscribe from this group and stop receiving emails from it, send > an > >> email to [email protected] <javascript:>. > >> To post to this group, send email to [email protected] > <javascript:>. > >> Visit this group at https://groups.google.com/group/scalaz. > >> For more options, visit https://groups.google.com/d/optout. > > > > > > -- > > You received this message because you are subscribed to the Google > Groups > > "scalaz" group. > > To unsubscribe from this group and stop receiving emails from it, send > an > > email to [email protected] <javascript:>. > > To post to this group, send email to [email protected] > <javascript:>. > > Visit this group at https://groups.google.com/group/scalaz. > > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "scalaz" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/scalaz. For more options, visit https://groups.google.com/d/optout.
