New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change order of type parameters to monad transformers? #1305

Open
TomasMikula opened this Issue Dec 13, 2016 · 6 comments

Comments

Projects
4 participants
@TomasMikula
Member

TomasMikula commented Dec 13, 2016

I suppose there was a reason why type parameters of some monad transformers in scalaz are in different order than in Haskell. For example

StateT[F[_], S, A]

instead of

StateT[S, F[_], A]

The latter seems to be a more common order of partial application.

Whatever the reason was, is it still valid?

Now that there's partial unification of type arguments, should we change the type parameter order to the one that's more common?

At least the following types could benefit from different parameter order:

  • StateT
  • WriterT
  • ReaderT
  • ReaderWriterStateT
  • EitherT
  • ContT
@xuwei-k

This comment has been minimized.

Member

xuwei-k commented Dec 13, 2016

@retronym wrote 5 years ago 4be1768#diff-f8a29528927f2b43e168ec1b8fede81fR239

Declare type parameters requiring type constructors first in type parameter declarations. This is and arbitrary choice,
but the consistency is worth it.

class Foo[F[_], A, B] // good
class Foo[A, F[_], B] // bad

https://github.com/scalaz/scalaz/blob/v7.3.0-M7/CONTRIBUTING.md#type-parameters

@TomasMikula

This comment has been minimized.

Member

TomasMikula commented Dec 13, 2016

I see. Back then (before -Ypartial-unification), I guess optimizing for the most common use case would have made no difference. Might be time to reconsider?

@xuwei-k

This comment has been minimized.

Member

xuwei-k commented Apr 25, 2017

Might be time to reconsider?

👍

@S11001001

This comment has been minimized.

Member

S11001001 commented Apr 27, 2017

We can't really reconsider until we no longer support versions of Scala that don't have -Ypartial-unification or an equivalent substitute (like the plugin) available. For the 7.3.x series, we still support Scala 2.10.

I've tagged this for 8 because there are good design cleanup reasons to require -Ypartial-unification be turned on for all users in that release.

@S11001001 S11001001 added the scalaz8 label Apr 27, 2017

@jbgi

This comment has been minimized.

Member

jbgi commented Apr 27, 2017

For the 7.3.x series, we still support Scala 2.10.

not anymore: #1367.

@TomasMikula

This comment has been minimized.

Member

TomasMikula commented May 31, 2018

See #1800 and #1838.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment