"State and Future of Scalaz" meeting in Boulder next month

[Vincent Marquez]

Hello all,

Given that at least a handful of the committers and contributors are going to be in Boulder at the end of May, some of us were discussing (on the IRC channel) a slightly more formal meeting to talk about current development of Scalaz, plans for Scalaz 8, exchanging ideas and getting fired up about the future of doing pure functional programming in Scala. 

I've talked to John De Goes, he has very graciously volunteered to let us use one of the (unused) rooms at the University of Colorado during Lambda Conf.  

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'll also do my best to have some sort of teleconference of the event, at the very least Skype/Hangouts for those who are interested and remote. 

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 (?).


Alois Cochard is (I believe?) scheduled to be presenting on his encoding of type classes, it may make sense to meet *after* we see it, so he doesn't have to give his presentation twice. :)

So my vote would be Saturday or Sunday.  If any are interested, let me know along with time preferences( even if remote!) in the next day or so and I'll continue to coordinate with John.  

--Vincent

[Tony Morris]

Excellent idea Vincent. I am in UTC+10 time zone. I believe central time means UTC-6. Please correct otherwise.

Do you have an intention to dial in remotes? If so:

I am unavailable during these times:

2016-05-28T03:00:00Z to 2016-05-28T08:30:00Z
2016-05-28T11:00:00Z to 2016-05-28T14:00:00Z

Otherwise I am free.

Thanks for organising it, and also to John for helping out.

--
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 scalaz+un...@googlegroups.com.
To post to this group, send email to sca...@googlegroups.com.
Visit this group at https://groups.google.com/group/scalaz.
For more options, visit https://groups.google.com/d/optout.

[Stephen Compall]

On May 17, 2016 3:25:18 PM EDT, Vincent Marquez <vincent...@gmail.com> 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.

[Vincent Marquez]

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

[Tony Morris]

I took some notes yesterday. I hope it's OK putting them here.

https://gist.github.com/tonymorris/0ebc6eff79b99469a58c9cab92a6637e

[Brian McKenna]

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.

[Sean Chalmers]

Hey Brian,

Just some quick answers to your questions... 

* Do people use Task for other reasons?

My primary reason for using Task is that the applications I work on are already

using Task as the primary concurrency technique and my scala-fu is not sufficient

to see any immediate problems with that. It seems to provide a nicer/less complicated

 interface than Future.

We have not encountered any bugs caused by Task, that I know of. It's

been quite useful and reliable for us. Although our usage could be regarded as

trivial, so we might not be a good example.

The error handling capabilities of Task is one thing that I like about it, when

compared to Future. The ability to construct simple composable blocks of possibly

failing concurrent actions using things like 'fromDisjunction' is nice.

* What API would people need to be able to replace Task with IO?

The error handling and simplicity are the nice things about Task, given I'm quite

a noob when it comes to the inner workings of Scala. I've not had a reason to

look at Task too closely as it has "Just Worked" for us.

* Does IO give less performance for these things than Task?

The programs we've been using scala for are not performance focused, so we can't

give any useful feedback on this point.

We can certainly appreciate the desire not have this fishy 'global implicit' ExecutionContext

hanging around. Especially when it just spins up an entire thread-pool with no real input. But

as it has not given us any grief, this hasn't been much of a concern.

Is there one, or set of, concurrency packages that would be recommended for Scala/z ?

Cheers,

Sean

[Aloïs Cochard]

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.