apply syntax

[Alec Zorab]

I feel like this has been brought up before, but I can't find a reference to it on the lists, if it has.

The deprecation comment for <**> et al says "Use `^(f1,f2..fN)((a,b,c) => ..)` instead", butg we don't actually have overloads for ^ for values of N, we instead have ^, ^^ etc.

Should there in fact be an overloaded method ^ for values of N up to some reasonable limit? I've tried it locally and everything seems to work fine at this end, but maybe there's something I'm missing (or not using/testing)?

Regards,

Alec

[Tom Switzer]

There did exist the overloads at some point, so I guess someone removed them. I'm guessing the correct fix is to probably change the deprecation messages.

--
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 http://groups.google.com/group/scalaz.
For more options, visit https://groups.google.com/groups/opt_out.

[Alec Zorab]

Looks like we lost it in https://github.com/scalaz/scalaz/commit/b0128eccbd90d2ecdf68dda2ef59a66a6ab2457e, which is commented "rename to avoid overloading". Other than Tony's personal distaste for overloading, is there any particular reason for this?

[Paul Chiusano]

Yes I wondered about this also and was kind of annoyed this was changed without any discussion (I was original committer of the syntax), but I found out about it too late. The overloading is not a problem since the functions are of different arities, and it looks much nicer.

The current syntax is pretty horrible. If we just wanted to avoid overloading I'd have gone back to map2, map3, etc.

[Chris Marshall]

The whole change is pretty annoying, given that (due to limits of type inference) there are trivial examples which could previously be written which now require (explicit) type parameters. Which, when you are using > 2 arguments just leaves an unreadable mess.

Again, this just seems a little bit like change for the sake of it. Harrumph etc

Chris

[Chris Marshall]

To clarify. here is what I mean.

    scala> import scalaz._; import Scalaz._

    import scalaz._

    import Scalaz._

    scala> val f: Int => String = _.toString

    f: Int => String = <function1>

    scala> val g: Int => Char = _.toChar

    g: Int => Char = <function1>

    scala> (f <**> g)(_ -> _)

    <console>:16: warning: method <**> in trait ApplyOps is deprecated: Use `^(f1,f2..fN)((a,b,c) => ..)` instead

                  (f <**> g)(_ -> _)

                     ^

    res0: Int => (String, Char) = <function1>

OK, I guess I'll use ^ then!

    scala> ^(f, g)(_ -> _)

    error: type mismatch;

     found   : Int => String

     required: ?F

    Note that implicit conversions are not applicable because they are ambiguous:

     both method ToLiftV in trait ToFunctorOps of type [F[_], A, B](v: A => B)scalaz.Scalaz.LiftV[F,A,B]

     and method ToFunction1OpsFromBoolean in trait ToFunction1Ops of type [A, B](f: A => B)scalaz.syntax.std.Function1Ops[A,B]

     are possible conversion functions from Int => String to ?F

Fucksocks. So: type parameters it is

   scala> ^[({type l[a] = Int => a})#l, String, Char, (String, Char)](f, g)(_ -> _)

   res3: Int => (String, Char) = <function1>

Double fucksocks

Chris

[Kenji Yoshida]

You can use ApplicativeBuilder

scala> val f: Int => String = _.toString
f: Int => String = <function1>

scala> val g: Int => Char = _.toChar
g: Int => Char = <function1>

scala> (f |@| g)(_ -> _)

res0: Int => (String, Char) = <function1>

2014/1/7 Chris Marshall <oxbow...@gmail.com>:

[Chris Marshall]

Unfortunately, applicative builder, when used with more than a few parameters, causes IDEA problems parsing files (i.e. I think it's implicit search algorithm blows up), so I now tend to avoid it.

Chris

[Lars Hupel]

> Yes I wondered about this also and was kind of annoyed this was changed
> without any discussion (I was original committer of the syntax), but I
> found out about it too late. The overloading is not a problem since the
> functions are of different arities, and it looks much nicer.

I'm entirely unenthusiastic about the `^` syntax. Its fundamental
disadvantage is that it doesn't use `Unapply`, though.

Anyway, providing syntax for arbitrary arity should be a solved problem
by now, since there is an integration layer between shapeless (HList)
and scalaz (Applicative) now [0]. It's still experimental, but I
encourage people to try it out and see whether it fits their needs.

[0]
<https://github.com/typelevel/shapeless-contrib/tree/v0.1.2#scalaz--shapeless--profit>

[Kenji Yoshida]

> I'm guessing the correct fix is to probably change the deprecation messages.

I have just fixed
https://github.com/scalaz/scalaz/commit/4d9a5515b5

[Kenji Yoshida]

I'm entirely unenthusiastic about the `^` syntax. Its fundamental
disadvantage is that it doesn't use `Unapply`, though.

Anyway, providing syntax for arbitrary arity should be a solved problem

I just came up with a new Apply syntax.

https://github.com/xuwei-k/scalaz/compare/scalaz:7d4f5bd...xuwei-k:050250b