transformers
Jason Zaugg
(e.g. StateT, LensT) for the Identity type constructor.
This would mean replacing:
type State[A, S] = StateT[Id, A, S]
with:
trait State[A, S] { self =>
// copy-paste starts here...
}
Pros:
- Less demanding on Scala's type inference and implicit search
(although it's holding together pretty well as currently organized)
- Less cognitive burden for users to understand the API and implementation
- Potentially better performance
Cons:
- More code to write
- Difficult to keep the API in sync between the two versions (tools
could help here)
Thoughts?
-jason
Chris Marshall
-jason
--
You received this message because you are subscribed to the Google Groups "scalaz" group.
To post to this group, send email to sca...@googlegroups.com.
To unsubscribe from this group, send email to scalaz+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/scalaz?hl=en.
Tony Morris
inference and it is nowhere near worth it. I disagree there is less
cognitive burden for users (indeed, I would argue the contrary if
forced). If performance is an issue because we use polymorphism, I'd
rather just write a new language and runtime.
The "Cons" should take into account that "More code to write" is not
linear -- but goes on for each dependency.
--
Tony Morris
http://tmorris.net/
Jason Zaugg
> I am strongly against it. The only "Pro" that I accept is for Scala type
> inference and it is nowhere near worth it.
> I disagree there is less cognitive burden for users (indeed, I would
> argue the contrary if forced).
My concern is that readers of your lens paper, or Functional
Programming in Scala, will struggle to use the more general form of
these data structures. Perhaps this can be allayed through
documentation/tutorials, as Chris suggests.
> If performance is an issue because we use polymorphism, I'd
> rather just write a new language and runtime.
Scalaz is a library for Scala and the JVM, and I'm interested in the
making the best tradeoffs for these, not for a hypothetical platform.
That said, the performance impact for indirecting through the type
class instance for Id is likely to be acceptable in a lot of cases, so
let's focus on the other points.
> The "Cons" should take into account that "More code to write" is not
> linear -- but goes on for each dependency.
Can you elaborate? I was figuring on a factor of two increase in code size.
-jason
Tony Morris
> On Sun, Apr 22, 2012 at 10:47 AM, Tony Morris <tonym...@gmail.com> wrote:
>> I am strongly against it. The only "Pro" that I accept is for Scala type
>> inference and it is nowhere near worth it.
>> I disagree there is less cognitive burden for users (indeed, I would
>> argue the contrary if forced).
> My concern is that readers of your lens paper, or Functional
> Programming in Scala, will struggle to use the more general form of
> these data structures. Perhaps this can be allayed through
> documentation/tutorials, as Chris suggests.
I agree there might be some initial struggle for many people, but I also
agree that there would be some additional initial struggle for those in
its specialised form.
We have surely all seen by now how for some people, presenting the list
reversal of integers as [A]List[A] => List[A] is *easier* to understand
because the type signature clearly says that nothing integerish is
happening, yet for others, List[Int] => List[Int] is more concrete,
despite conveying excess information.
I think then, the question is to ask, which is less clumsy overall? I
think all those who have a non-elementary understanding of List.reverse
will agree that List[A] => List[A] is most appropriate. For those
occasions where learning progress is difficult due to the polymorphism,
let us construct teaching aides according. I don't think we should
change our *code* accordingly. After all, what would we do? def
intReverse = reverse[Int]?
In short, I don't agree there is less cognitive burden for users, but I
also don't agree there is more -- it is specific to the individual and
therefore, I am (as always) inclined to apply a different set of
criteria, all of which lead me to "leave it be."
>> If performance is an issue because we use polymorphism, I'd
>> rather just write a new language and runtime.
> Scalaz is a library for Scala and the JVM, and I'm interested in the
> making the best tradeoffs for these, not for a hypothetical platform.
> That said, the performance impact for indirecting through the type
> class instance for Id is likely to be acceptable in a lot of cases, so
> let's focus on the other points.
Sure. I don't know the performance impact either way.
>> The "Cons" should take into account that "More code to write" is not
>> linear -- but goes on for each dependency.
> Can you elaborate? I was figuring on a factor of two increase in code size.
>
> -jason
>
I may have misspoken a bit with that metric, but I guess I am not
looking forward to authoring two versions of just about every data type,
even outside of Scalaz. I mean, it's not just State, Reader and friends
-- this is an infinite list and in practice, one that we would need to
be dealt with constantly in application code.
etorreborre
// copy-paste starts here...
}
Jason Zaugg
trait State[A, S] { self =>
// copy-paste starts here...
}
You don't necessarily need to copy-paste everything, just the interface. You can delegate the implementation to StateT[Id, A, S].Eric.
Matthew Pocock
Pros:
- Potentially better performance
Cons:
- More code to write
- Difficult to keep the API in sync between the two versions (tools
could help here)
Thoughts?
-jason
--
You received this message because you are subscribed to the Google Groups "scalaz" group.
To post to this group, send email to sca...@googlegroups.com.
To unsubscribe from this group, send email to scalaz+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/scalaz?hl=en.
Tony Morris
Jason Zaugg
> Can we not make Id a value class when the time is right?
over the identity type constructor.
-jason
Runar Bjarnason
Runar
Tony Morris
I have similar reservations. However, we recently had a use case where I wanted to compose partial lenses and determine which of them failed. Essentially I wanted Writer in the result of the application to the target object, with the W value having access to the lens parameters.
While I do have issues with LensT I only spent a short amount of time coming up with an alternative solution that satisfied requirements. Suggestions welcome.
Note that yall (hackage) models lens similarly.
--
You received this message because you are subscribed to the Google Groups "scalaz" group.
To view this discussion on the web visit https://groups.google.com/d/msg/scalaz/-/FVdz4sVisJMJ.
Runar Bjarnason
LensT[W[_], A, B] ~= A => W[Costate[B, A]]
Does that meet the requirement? Note that W should be a comonad.
Runar
Tony Morris
I started off with that then found the BijectionT morphism to the Lens category a bit ugly. I'm totally on the fence and feel your pain. Further opinions welcome.
Tony Morris
I might revert back to this middle ground next week, run with it and see how we go.
Tony Morris
https://github.com/scalaz/scalaz/commit/e15f46e7d49584d8c7b96a2bf775b1387d826b10
PS: I don't see why W must be a comonad when there is already a monad (A =>) sitting on top.