Hi Alexander,
Thanks for commenting on this issue.
On 21 June 2012 16:34, Alexander Solla alex.so...@gmail.com wrote:
These nits don't need to be picked. The theory of equivalence relations is
extremely well understood. This is a topic covered by the sophomore
mathematics level.
I did not
Hi Derek,
Thanks for providing the executable example that demonstrates your
point. It is an interesting one. See my response below. I think it
takes us into the discussion as to what constitutes reasonable/law
abiding instances of Eq and Ord and what client code that uses Eq and
Ord instances
Hi Dan,
On 21 June 2012 04:21, Dan Burton danburton.em...@gmail.com wrote:
Hi George,
I didn't have access to my computer over the weekend, so I apologize for not
actually running the examples I provided. I was simply projecting what I
thought could reasonably be assumed about the behavior
On Thu, Jun 21, 2012 at 7:00 AM, George Giorgidze giorgi...@gmail.comwrote:
Regarding antisymmetry, if I also define
instance Ord Foo where
(==) = (==) `on` a
then would that count as satisfying the law?
Probably, you mean here Eq instead of Ord.
If a = b and b = a then a = b
On Thu, Jun 21, 2012 at 8:30 AM, George Giorgidze giorgi...@gmail.com wrote:
Hi Derek,
Thanks for providing the executable example that demonstrates your
point. It is an interesting one. See my response below. I think it
takes us into the discussion as to what constitutes reasonable/law
Hi George,
I didn't have access to my computer over the weekend, so I apologize for
not actually running the examples I provided. I was simply projecting what
I thought could reasonably be assumed about the behavior of a Set.
Data.Set.Monad's departure from those assumptions is a double-edged
Hi Derek,
Thanks for clarifying your point.
You are right that (fromList . toList) = id is a desirable and it
holds for Data.Set.
But your suggestions that this property does not hold for
Data.Set.Monad is not correct.
Please check out the repo, I have just pushed a quickcheck definition
for
Un-top-posted. See below.
On 19 June 2012 02:21, Derek Elkins derek.a.elk...@gmail.com wrote:
On Jun 18, 2012 4:54 PM, George Giorgidze giorgi...@gmail.com wrote:
Hi Derek,
On 16 June 2012 21:53, Derek Elkins derek.a.elk...@gmail.com wrote:
The law that ends up failing is toList .
Hi Dan,
Thanks for your feedback and your question regarding the functor laws.
Please try your example in GHCi and/or evaluate it by hand. The
library does not violate the functor laws.
I committed quick check properties for functor laws, as well as, laws
for other type classes to the repo. You
Hi Derek,
On 16 June 2012 21:53, Derek Elkins derek.a.elk...@gmail.com wrote:
The law that ends up failing is toList .
fromList /= id, i.e. fmap g . toList . fromList . fmap h /= fmap g .
fmap h
This is not related to functor laws. The property that you desire is
about toList and fromList.
Convenience aside, doesn't the functor instance conceptually violate some
sort of law?
fmap (const 1) someSet
The entire shape of the set changes.
fmap (g . h) = fmap g . fmap h
This law wouldn't hold given the following contrived ord instance
data Foo = Foo { a, b :: Int }
instance Ord Foo
On Sat, Jun 16, 2012 at 3:47 AM, Dan Burton danburton.em...@gmail.com wrote:
Convenience aside, doesn't the functor instance conceptually violate some
sort of law?
fmap (const 1) someSet
The entire shape of the set changes.
fmap (g . h) = fmap g . fmap h
This law wouldn't hold given
I would like to announce the first release of the set-monad library.
On Hackage: http://hackage.haskell.org/package/set-monad
The set-monad library exports the Set abstract data type and
set-manipulating functions. These functions behave exactly as their
namesakes from the Data.Set module of the
13 matches
Mail list logo
