Pointed/Copointed
340 views
Skip to first unread message
Tony Morris
Dec 27, 2012, 7:35:38 PM12/27/12
to sca...@googlegroups.com
Hello,
There are two type-classes in scalaz; Pointed and Copointed.
It is my opinion that the existence of these two traits is a bug.
Without getting too heavy into the theory, the primary consequence is a
failure of application of abstraction. If you use these in your code
explicitly, then I argue that you have a bug with this consequence.
I have long disliked Pointed/Copointed, since not too long after their
introduction, but recently, I have battled through implementing their
removal. The summary is that the point operation has now moved to
Applicative.
I am now keen to go ahead and fix all my dependent code. However, I bet
some of you do not feel as strongly as I do about this bug and so would
not be as keen.
Therefore, I put this subject out for discussion. If you only need
convincing that this is indeed an abstraction bug, then I will write the
essay. If you are just lazy and don't feel like updating your code
because you are on a cruise ship drinking pi�a coladas, then fine. I am
just putting it out there. Discuss!
--
Tony Morris
http://tmorris.net/
There are two type-classes in scalaz; Pointed and Copointed.
It is my opinion that the existence of these two traits is a bug.
Without getting too heavy into the theory, the primary consequence is a
failure of application of abstraction. If you use these in your code
explicitly, then I argue that you have a bug with this consequence.
I have long disliked Pointed/Copointed, since not too long after their
introduction, but recently, I have battled through implementing their
removal. The summary is that the point operation has now moved to
Applicative.
I am now keen to go ahead and fix all my dependent code. However, I bet
some of you do not feel as strongly as I do about this bug and so would
not be as keen.
Therefore, I put this subject out for discussion. If you only need
convincing that this is indeed an abstraction bug, then I will write the
essay. If you are just lazy and don't feel like updating your code
because you are on a cruise ship drinking pi�a coladas, then fine. I am
just putting it out there. Discuss!
--
Tony Morris
http://tmorris.net/
Alexander Altman
Dec 27, 2012, 8:13:06 PM12/27/12
to sca...@googlegroups.com
I strongly object to the removal of these two type-classes! Pointed, in particular, is crucial for, e.g., the van Laarhoven representation of partial lens families, partial getters, and partial actions. The diamond between Id, Option, NonEmptyList, and List is reflected in the parallel diamond between Functor, Pointed, Apply, and Applicative, respectively. Removing Pointed is exactly like removig Option, except worse, because the type-class hierarchy is actually implemented subtype-wise. Ideally, we'd have a Zero type-class like in Scalaz 6 as well, and for exactly the same reasons.
> because you are on a cruise ship drinking piña coladas, then fine. I am
> --
> 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.
>
> --
> 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
Dec 27, 2012, 8:21:28 PM12/27/12
to sca...@googlegroups.com
If I can demonstrate to you that you do not want Pointed, *especially*
for representing lens families, would you change your mind?
I have regretted the introduction of these two filthy type-classes since
forever. I am now paying the price!
On 28/12/12 11:13, Alexander Altman wrote:
> I strongly object to the removal of these two type-classes! Pointed, in particular, is crucial for, e.g., the van Laarhoven representation of partial lens families, partial getters, and partial actions. The diamond between Id, Option, NonEmptyList, and List is reflected in the parallel diamond between Functor, Pointed, Apply, and Applicative, respectively. Removing Pointed is exactly like removig Option, except worse, because the type-class hierarchy is actually implemented subtype-wise. Ideally, we'd have a Zero type-class like in Scalaz 6 as well, and for exactly the same reasons.
>
> On Dec 27, 2012, at 7:35 PM, Tony Morris <tonym...@gmail.com> wrote:
>
>> Hello,
>> There are two type-classes in scalaz; Pointed and Copointed.
>>
>> It is my opinion that the existence of these two traits is a bug.
>> Without getting too heavy into the theory, the primary consequence is a
>> failure of application of abstraction. If you use these in your code
>> explicitly, then I argue that you have a bug with this consequence.
>>
>> I have long disliked Pointed/Copointed, since not too long after their
>> introduction, but recently, I have battled through implementing their
>> removal. The summary is that the point operation has now moved to
>> Applicative.
>>
>> I am now keen to go ahead and fix all my dependent code. However, I bet
>> some of you do not feel as strongly as I do about this bug and so would
>> not be as keen.
>>
>> Therefore, I put this subject out for discussion. If you only need
>> convincing that this is indeed an abstraction bug, then I will write the
>> essay. If you are just lazy and don't feel like updating your code
>> because you are on a cruise ship drinking pi�a coladas, then fine. I am
for representing lens families, would you change your mind?
I have regretted the introduction of these two filthy type-classes since
forever. I am now paying the price!
On 28/12/12 11:13, Alexander Altman wrote:
> I strongly object to the removal of these two type-classes! Pointed, in particular, is crucial for, e.g., the van Laarhoven representation of partial lens families, partial getters, and partial actions. The diamond between Id, Option, NonEmptyList, and List is reflected in the parallel diamond between Functor, Pointed, Apply, and Applicative, respectively. Removing Pointed is exactly like removig Option, except worse, because the type-class hierarchy is actually implemented subtype-wise. Ideally, we'd have a Zero type-class like in Scalaz 6 as well, and for exactly the same reasons.
>
> On Dec 27, 2012, at 7:35 PM, Tony Morris <tonym...@gmail.com> wrote:
>
>> Hello,
>> There are two type-classes in scalaz; Pointed and Copointed.
>>
>> It is my opinion that the existence of these two traits is a bug.
>> Without getting too heavy into the theory, the primary consequence is a
>> failure of application of abstraction. If you use these in your code
>> explicitly, then I argue that you have a bug with this consequence.
>>
>> I have long disliked Pointed/Copointed, since not too long after their
>> introduction, but recently, I have battled through implementing their
>> removal. The summary is that the point operation has now moved to
>> Applicative.
>>
>> I am now keen to go ahead and fix all my dependent code. However, I bet
>> some of you do not feel as strongly as I do about this bug and so would
>> not be as keen.
>>
>> Therefore, I put this subject out for discussion. If you only need
>> convincing that this is indeed an abstraction bug, then I will write the
>> essay. If you are just lazy and don't feel like updating your code
Alexander Altman
Dec 27, 2012, 8:25:33 PM12/27/12
to sca...@googlegroups.com
If you can demonstrate to me that Pointed can be completely replaced in every possible use without breaking the proof properties of he code in question, then I would be okay with removing them, perhaps.
On Dec 27, 2012, at 8:21 PM, Tony Morris <tonym...@gmail.com> wrote:
> If I can demonstrate to you that you do not want Pointed, *especially*
> for representing lens families, would you change your mind?
>
> I have regretted the introduction of these two filthy type-classes since
> forever. I am now paying the price!
>
> On 28/12/12 11:13, Alexander Altman wrote:
>> I strongly object to the removal of these two type-classes! Pointed, in particular, is crucial for, e.g., the van Laarhoven representation of partial lens families, partial getters, and partial actions. The diamond between Id, Option, NonEmptyList, and List is reflected in the parallel diamond between Functor, Pointed, Apply, and Applicative, respectively. Removing Pointed is exactly like removig Option, except worse, because the type-class hierarchy is actually implemented subtype-wise. Ideally, we'd have a Zero type-class like in Scalaz 6 as well, and for exactly the same reasons.
>>
>> On Dec 27, 2012, at 7:35 PM, Tony Morris <tonym...@gmail.com> wrote:
>>
>>> Hello,
>>> There are two type-classes in scalaz; Pointed and Copointed.
>>>
>>> It is my opinion that the existence of these two traits is a bug.
>>> Without getting too heavy into the theory, the primary consequence is a
>>> failure of application of abstraction. If you use these in your code
>>> explicitly, then I argue that you have a bug with this consequence.
>>>
>>> I have long disliked Pointed/Copointed, since not too long after their
>>> introduction, but recently, I have battled through implementing their
>>> removal. The summary is that the point operation has now moved to
>>> Applicative.
>>>
>>> I am now keen to go ahead and fix all my dependent code. However, I bet
>>> some of you do not feel as strongly as I do about this bug and so would
>>> not be as keen.
>>>
>>> Therefore, I put this subject out for discussion. If you only need
>>> convincing that this is indeed an abstraction bug, then I will write the
>>> essay. If you are just lazy and don't feel like updating your code
>>> because you are on a cruise ship drinking piña coladas, then fine. I am
On Dec 27, 2012, at 8:21 PM, Tony Morris <tonym...@gmail.com> wrote:
> If I can demonstrate to you that you do not want Pointed, *especially*
> for representing lens families, would you change your mind?
>
> I have regretted the introduction of these two filthy type-classes since
> forever. I am now paying the price!
>
> On 28/12/12 11:13, Alexander Altman wrote:
>> I strongly object to the removal of these two type-classes! Pointed, in particular, is crucial for, e.g., the van Laarhoven representation of partial lens families, partial getters, and partial actions. The diamond between Id, Option, NonEmptyList, and List is reflected in the parallel diamond between Functor, Pointed, Apply, and Applicative, respectively. Removing Pointed is exactly like removig Option, except worse, because the type-class hierarchy is actually implemented subtype-wise. Ideally, we'd have a Zero type-class like in Scalaz 6 as well, and for exactly the same reasons.
>>
>> On Dec 27, 2012, at 7:35 PM, Tony Morris <tonym...@gmail.com> wrote:
>>
>>> Hello,
>>> There are two type-classes in scalaz; Pointed and Copointed.
>>>
>>> It is my opinion that the existence of these two traits is a bug.
>>> Without getting too heavy into the theory, the primary consequence is a
>>> failure of application of abstraction. If you use these in your code
>>> explicitly, then I argue that you have a bug with this consequence.
>>>
>>> I have long disliked Pointed/Copointed, since not too long after their
>>> introduction, but recently, I have battled through implementing their
>>> removal. The summary is that the point operation has now moved to
>>> Applicative.
>>>
>>> I am now keen to go ahead and fix all my dependent code. However, I bet
>>> some of you do not feel as strongly as I do about this bug and so would
>>> not be as keen.
>>>
>>> Therefore, I put this subject out for discussion. If you only need
>>> convincing that this is indeed an abstraction bug, then I will write the
>>> essay. If you are just lazy and don't feel like updating your code
Tony Morris
Dec 27, 2012, 8:32:17 PM12/27/12
to sca...@googlegroups.com
Let us be clear to start then. Pointed provides zero proof properties
and only serves to potentially invite broken code.
It is lawless on its own, except to the extent of a law provided by
parametricity. It therefore provides no value. Providing no value is one
thing, but inviting counter-productive code is another. It is a net
total loss of the less than zero.
If you accept that it provides zero value, or less than zero value, then
I have nothing to say except my own opinion that it provides
*significantly* less than zero value in practice with no redeeming
properties.
I am not clear on what your position might be on this.
As a side-note, here is a similar discussion that just occurred in IRC:
<dibblego> they are a failed abstraction
<dibblego> they should not exist
<dibblego> they provide no additional value
<dibblego> they are lawless, except for those laws that are proved by
parametricity anyway
<dibblego> their existence pretends to be valuable, which means a net
value of less than zero
<dibblego> this is a bug
<jedws> the concept is handy for describing different kinds of monads
<dibblego> woah there
<dibblego> there are two issues:
<dibblego> 1) they provide no value
<dibblego> 2) removing them is a breaking change
<dibblego> I am concerned only with 2)
<dibblego> 1) is well proven
<jedws> I don't automatically accept (1) � I trust that you know what
you are saying, but I can only believe it on trust
<dibblego> OK, well I guess I will have to write the essay
<dibblego> edwardk will certainly have something to say too
<dibblego> I thought it may have been discussed on haskell mailing lists
already, but looking now, I cannot find it
<jedws> k, I look forward to hearing it
<jedws> s/hearing/reading/
<dibblego> I can only find this:
<dibblego> http://www.haskell.org/haskellwiki/Typeclassopedia
<dibblego> (Note that previous versions of the Typeclassopedia explained
pure in terms of a type class Pointed, which can still be found in the
pointed package. However, the current consensus is that Pointed is not
very useful after all. For a more detailed explanation, see Why not
Pointed?)
<dibblego> http://www.haskell.org/haskellwiki/Why_not_Pointed%3F
<dibblego> The Pointed type class lives in the pointed library, moved
from the category-extras library.
<dibblego> Edward Kmett, the author of category-extras, pointed, and
many related packages, has since moved his focus to semigroupoids and
semigroups. He finds them more interesting and useful, and considers
Pointed to be historical now (he still provides the pointed package only
because �people were whinging�).
<edwardk> actually i don't use semigroupoids for much any more ;)
<dibblego> I don't think that's the reason anyway
<edwardk> its a useful layer though
<edwardk> jedws: the issue with pointed is that it provides you with no
real way to compose anything you get out of it, at all.
<dibblego> "semigroupoids exist" is not the strongest argument to be
made for: "pointed should not exist"
<edwardk> the only law you get is a free theorem
<edwardk> this means that a pointed functor might as well just be a
pointed type
<edwardk> but more damningly they invite you to use them in ways not
supported by their lack of laws
<edwardk> e.g. Set can be pointed. so you can make a singleton set a ->
Set a
<edwardk> ok, that seems fair, but when you have a bunch of them, what
can you do?
<edwardk> the fact that Set is a monoid and you can mappend them works
<edwardk> you can mappend the singleton sets
<edwardk> but this relies on completely ad hoc reasoning about this tyoe
<edwardk> if you have something else such that you have Pointed t and
Monoid (t a) you have to redo that reasoning
<edwardk> there is no law relating Pointed t and Monoid (t a) and no
meaningful way to stitch together its targets
<edwardk> virtually every use of pointed I've seen since I originally
foisted the idea off on the haskell community several years back has
been of this ad hoc nature.
<edwardk> I have come to regret that I ever pushed it
<dibblego> me too, since a few days after I did
<jedws> I'm afraid I'm still missing something�
<jedws> what do you mean by the ad-hoc reasoning of Set mappend?
<edwardk> i mean that the 'point' for your Set could very well just drop
the value 'a' on the floor
<jedws> right�
<edwardk> why is it singleton and not mempty?
<edwardk> that isn't in the laws anywhere
<edwardk> you have to _know_ about Set to reason about the correctness
of foldMap singleton
<edwardk> er foldMap point
<jedws> k, isn't that generally the case for Set (and Map) though?
* gianp has quit (Quit: This computer has gone to sleep)
<edwardk> my point is the parametricity on that signature isn't leading
you to any fundamental operation. you need to reason about every use of
'point' based on the concrete types it gets instantiated to. there are
lots of thoughts you can have about Apply or Applicative or Monad or
Bind that have nothing to do with the concrete instantiation
>>>> because you are on a cruise ship drinking pi�a coladas, then fine. I am
and only serves to potentially invite broken code.
It is lawless on its own, except to the extent of a law provided by
parametricity. It therefore provides no value. Providing no value is one
thing, but inviting counter-productive code is another. It is a net
total loss of the less than zero.
If you accept that it provides zero value, or less than zero value, then
I have nothing to say except my own opinion that it provides
*significantly* less than zero value in practice with no redeeming
properties.
I am not clear on what your position might be on this.
As a side-note, here is a similar discussion that just occurred in IRC:
<dibblego> they are a failed abstraction
<dibblego> they should not exist
<dibblego> they provide no additional value
<dibblego> they are lawless, except for those laws that are proved by
parametricity anyway
<dibblego> their existence pretends to be valuable, which means a net
value of less than zero
<dibblego> this is a bug
<jedws> the concept is handy for describing different kinds of monads
<dibblego> woah there
<dibblego> there are two issues:
<dibblego> 1) they provide no value
<dibblego> 2) removing them is a breaking change
<dibblego> I am concerned only with 2)
<dibblego> 1) is well proven
<jedws> I don't automatically accept (1) � I trust that you know what
you are saying, but I can only believe it on trust
<dibblego> OK, well I guess I will have to write the essay
<dibblego> edwardk will certainly have something to say too
<dibblego> I thought it may have been discussed on haskell mailing lists
already, but looking now, I cannot find it
<jedws> k, I look forward to hearing it
<jedws> s/hearing/reading/
<dibblego> I can only find this:
<dibblego> http://www.haskell.org/haskellwiki/Typeclassopedia
<dibblego> (Note that previous versions of the Typeclassopedia explained
pure in terms of a type class Pointed, which can still be found in the
pointed package. However, the current consensus is that Pointed is not
very useful after all. For a more detailed explanation, see Why not
Pointed?)
<dibblego> http://www.haskell.org/haskellwiki/Why_not_Pointed%3F
<dibblego> The Pointed type class lives in the pointed library, moved
from the category-extras library.
<dibblego> Edward Kmett, the author of category-extras, pointed, and
many related packages, has since moved his focus to semigroupoids and
semigroups. He finds them more interesting and useful, and considers
Pointed to be historical now (he still provides the pointed package only
because �people were whinging�).
<edwardk> actually i don't use semigroupoids for much any more ;)
<dibblego> I don't think that's the reason anyway
<edwardk> its a useful layer though
<edwardk> jedws: the issue with pointed is that it provides you with no
real way to compose anything you get out of it, at all.
<dibblego> "semigroupoids exist" is not the strongest argument to be
made for: "pointed should not exist"
<edwardk> the only law you get is a free theorem
<edwardk> this means that a pointed functor might as well just be a
pointed type
<edwardk> but more damningly they invite you to use them in ways not
supported by their lack of laws
<edwardk> e.g. Set can be pointed. so you can make a singleton set a ->
Set a
<edwardk> ok, that seems fair, but when you have a bunch of them, what
can you do?
<edwardk> the fact that Set is a monoid and you can mappend them works
<edwardk> you can mappend the singleton sets
<edwardk> but this relies on completely ad hoc reasoning about this tyoe
<edwardk> if you have something else such that you have Pointed t and
Monoid (t a) you have to redo that reasoning
<edwardk> there is no law relating Pointed t and Monoid (t a) and no
meaningful way to stitch together its targets
<edwardk> virtually every use of pointed I've seen since I originally
foisted the idea off on the haskell community several years back has
been of this ad hoc nature.
<edwardk> I have come to regret that I ever pushed it
<dibblego> me too, since a few days after I did
<jedws> I'm afraid I'm still missing something�
<jedws> what do you mean by the ad-hoc reasoning of Set mappend?
<edwardk> i mean that the 'point' for your Set could very well just drop
the value 'a' on the floor
<jedws> right�
<edwardk> why is it singleton and not mempty?
<edwardk> that isn't in the laws anywhere
<edwardk> you have to _know_ about Set to reason about the correctness
of foldMap singleton
<edwardk> er foldMap point
<jedws> k, isn't that generally the case for Set (and Map) though?
* gianp has quit (Quit: This computer has gone to sleep)
<edwardk> my point is the parametricity on that signature isn't leading
you to any fundamental operation. you need to reason about every use of
'point' based on the concrete types it gets instantiated to. there are
lots of thoughts you can have about Apply or Applicative or Monad or
Bind that have nothing to do with the concrete instantiation
Alexander Altman
Dec 27, 2012, 8:40:46 PM12/27/12
to sca...@googlegroups.com
Alright. What about abstracting over the ability to create singletons? After reading the IRC log you provided, I'd be okay with making Pointed a synonym of [f[_]](Pure[f] with Functor[f]), but that would leave Pure as a type-class, and I don't see why we should get rid of that.
> <jedws> I don't automatically accept (1) – I trust that you know what
> <jedws> I'm afraid I'm still missing something…
>>>>> because you are on a cruise ship drinking piña coladas, then fine. I am
> you are saying, but I can only believe it on trust
> <dibblego> OK, well I guess I will have to write the essay
> <dibblego> edwardk will certainly have something to say too
> <dibblego> I thought it may have been discussed on haskell mailing lists
> already, but looking now, I cannot find it
> <jedws> k, I look forward to hearing it
> <jedws> s/hearing/reading/
> <dibblego> I can only find this:
> <dibblego> http://www.haskell.org/haskellwiki/Typeclassopedia
> <dibblego> (Note that previous versions of the Typeclassopedia explained
> pure in terms of a type class Pointed, which can still be found in the
> pointed package. However, the current consensus is that Pointed is not
> very useful after all. For a more detailed explanation, see Why not
> Pointed?)
> <dibblego> http://www.haskell.org/haskellwiki/Why_not_Pointed%3F
> <dibblego> The Pointed type class lives in the pointed library, moved
> from the category-extras library.
> <dibblego> Edward Kmett, the author of category-extras, pointed, and
> many related packages, has since moved his focus to semigroupoids and
> semigroups. He finds them more interesting and useful, and considers
> Pointed to be historical now (he still provides the pointed package only
> because “people were whinging”).
> <dibblego> OK, well I guess I will have to write the essay
> <dibblego> edwardk will certainly have something to say too
> <dibblego> I thought it may have been discussed on haskell mailing lists
> already, but looking now, I cannot find it
> <jedws> k, I look forward to hearing it
> <jedws> s/hearing/reading/
> <dibblego> I can only find this:
> <dibblego> http://www.haskell.org/haskellwiki/Typeclassopedia
> <dibblego> (Note that previous versions of the Typeclassopedia explained
> pure in terms of a type class Pointed, which can still be found in the
> pointed package. However, the current consensus is that Pointed is not
> very useful after all. For a more detailed explanation, see Why not
> Pointed?)
> <dibblego> http://www.haskell.org/haskellwiki/Why_not_Pointed%3F
> <dibblego> The Pointed type class lives in the pointed library, moved
> from the category-extras library.
> <dibblego> Edward Kmett, the author of category-extras, pointed, and
> many related packages, has since moved his focus to semigroupoids and
> semigroups. He finds them more interesting and useful, and considers
> Pointed to be historical now (he still provides the pointed package only
> <jedws> what do you mean by the ad-hoc reasoning of Set mappend?
> <edwardk> i mean that the 'point' for your Set could very well just drop
> the value 'a' on the floor
> <jedws> right…
> <edwardk> i mean that the 'point' for your Set could very well just drop
> the value 'a' on the floor
Tony Morris
Dec 27, 2012, 8:42:12 PM12/27/12
to sca...@googlegroups.com
On 28/12/12 11:40, Alexander Altman wrote:
> I'd be okay with making Pointed a synonym of [f[_]](Pure[f] with Functor[f])
What value would this provide? What are its laws?
> I'd be okay with making Pointed a synonym of [f[_]](Pure[f] with Functor[f])
Alexander Altman
Dec 27, 2012, 9:24:13 PM12/27/12
to <scalaz@googlegroups.com>
It would, as I said, provide the ability to abstract over singleton structure creation. As far as laws go, it would have exactly as many as Foldable. :)
Tony Morris
Dec 27, 2012, 9:26:10 PM12/27/12
to sca...@googlegroups.com
On 28/12/12 12:24, Alexander Altman wrote:
> the ability to abstract over singleton structure creation
I think this statement assumes some law. Or, what do you mean by singleton?
> the ability to abstract over singleton structure creation
Runar Bjarnason
Dec 27, 2012, 9:52:00 PM12/27/12
to sca...@googlegroups.com
Foldable[F] says "F[A] is isomorphic to a free monoid generated by A". That implies a lot.
I agree with Tony. Off with their heads!
Alexander Altman
Dec 27, 2012, 9:57:41 PM12/27/12
to sca...@googlegroups.com
It doesn't mean *isomorphic*, it means *can be (possibly lossily) converted*, which is a lot less powerful. Otherwise, e.g. rose trees would not be Foldable, but they are.
To view this discussion on the web visit https://groups.google.com/d/msg/scalaz/-/MAfohY3_iO0J.
Tony Morris
Dec 27, 2012, 10:08:09 PM12/27/12
to sca...@googlegroups.com
Foldable is dubious anyway.
My argument is, in summary, as follows:
1)
Pointed/Copointed/ArrId provide absolutely no benefit.
1.1)
They do not abstract on singleton values, for whatever definition of singleton I can surmise, since, for example:
1.1.1)
// is not a singleton
case class InfiniteStream[A](h: () => A, t: InfiniteStream[A])
def point[A](a: => A): InfiniteStream[A] = InfiniteStream(() => a, point(a))
1.1.2)
// is not a singleton
def point[A](a: => A): T => A = _ => a
2) Had they been benign, sitting there providing no value, I would not be compelled to go much further. However, not only do they provide no benefit, but they proactively invite broken code. This leads to a total net value of negative. This means they are a (very serious) bug with adverse consequences proportional to the size of that invitation. I argue that invitation has even been accepted on this very thread (I suspect following a reason to what is meant by "singleton" reveals the extent of the hoodwinking).
This situation is like chiropractic, in that it sits there being not-a-medicine providing absolutely no value for the patient, except when the patient is injured by the very practice itself -- then they have to reach for real medicine.
I do not know for which of the above there is contention, but I still contend that their existence is a (significant) bug and has been ever since they were written (I only noticed a few days later and after some discussion). I am hoping I can apply the patch, apologise to you all for the misleading code and move on. If there is a sound reason not to, please say so now.
My argument is, in summary, as follows:
1)
Pointed/Copointed/ArrId provide absolutely no benefit.
1.1)
They do not abstract on singleton values, for whatever definition of singleton I can surmise, since, for example:
1.1.1)
// is not a singleton
case class InfiniteStream[A](h: () => A, t: InfiniteStream[A])
def point[A](a: => A): InfiniteStream[A] = InfiniteStream(() => a, point(a))
1.1.2)
// is not a singleton
def point[A](a: => A): T => A = _ => a
2) Had they been benign, sitting there providing no value, I would not be compelled to go much further. However, not only do they provide no benefit, but they proactively invite broken code. This leads to a total net value of negative. This means they are a (very serious) bug with adverse consequences proportional to the size of that invitation. I argue that invitation has even been accepted on this very thread (I suspect following a reason to what is meant by "singleton" reveals the extent of the hoodwinking).
This situation is like chiropractic, in that it sits there being not-a-medicine providing absolutely no value for the patient, except when the patient is injured by the very practice itself -- then they have to reach for real medicine.
I do not know for which of the above there is contention, but I still contend that their existence is a (significant) bug and has been ever since they were written (I only noticed a few days later and after some discussion). I am hoping I can apply the patch, apologise to you all for the misleading code and move on. If there is a sound reason not to, please say so now.
-- Tony Morris http://tmorris.net/
Alexander Altman
Dec 27, 2012, 10:16:44 PM12/27/12
to <scalaz@googlegroups.com>
I would actually call both of your "non-singleton" examples singletons, since they really are a *single value in a context independent of that value* (the context only possibly affects the value's internal representation). However, I have nothing else
to bring forth besides what I already have, and I have no personal experience one way or he other regarding the supposed negative impact on code, so this will probably be my last message.
Tony Morris
Dec 28, 2012, 12:45:32 AM12/28/12
to sca...@googlegroups.com
Reply all
Reply to author
Forward
0 new messages