Option (First a) how does it work?

[MarkZander]

In semigroup documentation:

-- | Use @'Option' ('First' a)@ to get the behavior of 'Data.Monoid.First' from @Data.Monoid@.

In my code:

stats1 :: TempTime -> Option (First LocalTime) stats1 tt@(Arg temp time) = Option (First time)

Error message:

Couldn't match expected type ‘Maybe (First LocalTime)’
            with actual type ‘First LocalTime’
In the first argument of ‘Option’, namely ‘(First time)’
In the expression: Option (First time)

Is there a more thorough example of how to use this feature?

Thanks, Mark

[ekmett]

stats1 tt@(Arg temp time) = Option (Just (First time))

The Option data constructor is just a wrapper around Maybe, so you still need Just.

[MarkZander]

Thanks, it works now. I was just missing the Just data constructor. Somehow I wasn’t putting it together, even with the compiler error messages.

Option of course just hides Maybe to the instances.

I see the direction you have taken this now. You are taking semigroups and wrapping them in Option in order to extend them into Monoids. So First is a semigoup and Option First is a monoid.

Thanks for you explanations. It just took a while to get through.

One further question, could Min and Option be used for a minimum Integer?

Mark

On Jul 28, 2015, at 3:42 PM, Edward Kmett notifications@github.com wrote:

(Option (Just (First time)))

The Option data constructor is just a wrapper around Maybe.

— Reply to this email directly or view it on GitHub https://github.com/ekmett/semigroups/issues/50#issuecomment-125762458.

On Jul 28, 2015, at 3:49 PM, Edward Kmett notifications@github.com wrote:

You can perform minimum and maximum using foldr1 or foldl1 without incurring Bounded constraints.

foo = foldr1 (<>) Using the semigroupoids package you can use Data.Semigroup.Foldable to

getMin . foldMap1 Min to fold over a container with at least one element and extract an answer.

On the other hand, we can use Option (Min a) to add a 'missing element' notion.

fmap getMin . getOption . foldMap (Option . Just . Min)` :: (Foldable f, Ord a) => f a -> Maybe a The point here is that Min and Max are about supplying the Semigroup for minimum and maximum value. It is perfectly reasonable to extend this to a Monoid by trying to add a unit on top. This is what Option does here.

But because Option exists we don't need to bake it in and make everyone pay for it, even when they don't need it -- e.g. when they happen to be Bounded.

— Reply to this email directly or view it on GitHub https://github.com/ekmett/semigroups/issues/46#issuecomment-125763713.

[ekmett]

Option (Max Integer) gives you Option Nothing acting as a -Infinity, as it has to be a unit for Option (Max Integer).

Similarly, Option (Min Integer) gives you Option Nothing acting as Infinity.

[MarkZander]

Thanks, I realized that after looking at the code after your previous emails. Previous to that I wondered which method would be used, using maybe or using bounds. I can now see that both options are available by the way you put things together.

I got confused over leaving out the maybe constructor (Just). The Min type for Integer leaves out Maybe but the constructor requires Just. Somehow I couldn’t put that together:

minInteger :: Integer -> Option (Min Intgeger) minInteger i = Option $ Just $ Min Integer

or

minInteger = Option . Just . Min

I thought the following would be useful for brevity:

oJust :: a -> Option a oJust = Option . Just

oNothing :: Option a oNothing = Option $ Nothing

I wrote 3 orphaned instances. Bounded Float, Bounded Double and a Monoid for a six tuple. Haskell libraries could really use a more complete floating point. Constants like nan, infinity and negative infinity don’t seem defined.

I should probably post my code as an example for others to shoot at.

Thanks for all of your help. The semigroup library really made for short code even if it did take me a while to figure out what was going on.

Mark

On Jul 29, 2015, at 1:04 AM, Edward Kmett notifications@github.com wrote:

Option (Max Integer) gives you Option Nothing acting as a -Infinity, as it has to be a unit for Option (Max Integer).

Similarly, Option (Min Integer) gives you Option Nothing acting as Infinity.

— Reply to this email directly or view it on GitHub https://github.com/ekmett/semigroups/issues/50#issuecomment-125864869.

[ekmett]

Ultimately the reason why we don't have a Bounded Float is that NaN messes everything up.

(0/0) <= (1/0::Float) = False

so inf = 1/0 is not maxBound for Float.

Similarly

(-1/0::Float) <= (0/0) = False

so -inf is not minBound.

This is why these instances are not and cannot be standard.

[MarkZander]

I’ll have None of that!

inf is not maxBound either.

I guess Option (Min Float) is the only option then.

Mark

On Jul 29, 2015, at 10:21 AM, Edward Kmett notifications@github.com wrote:

Ultimately the reason why we don't have a Bounded Float is that NaN messes everything up.

(0/0) <= (1/0::Float) = False so inf = 1/0 is not maxBound for Float.

Similarly

(-1/0::Float) <= (0/0) = False so -inf is not minBound.

This is why these instances are not and cannot be standard.

— Reply to this email directly or view it on GitHub https://github.com/ekmett/semigroups/issues/50#issuecomment-126006560.

[MarkZander]

Prelude> 0/0 <= 0 False Prelude> 0/0 >= 0 False

Looks like floats aren’t ordered in the presence of NaN.

Mark

On Jul 29, 2015, at 10:21 AM, Edward Kmett notifications@github.com wrote:

Ultimately the reason why we don't have a Bounded Float is that NaN messes everything up.

(0/0) <= (1/0::Float) = False so inf = 1/0 is not maxBound for Float.

Similarly

(-1/0::Float) <= (0/0) = False so -inf is not minBound.

This is why these instances are not and cannot be standard.

— Reply to this email directly or view it on GitHub https://github.com/ekmett/semigroups/issues/50#issuecomment-126006560.

[ekmett]

Correct. Haskell complies with IEEE on the behavior of NaN at the expense of being able to reason about Ord as an actual total ordering.

[MarkZander]

I’ve always wondered if someone would step up to the challenge of defining operations of floats that are efficient and yet obey the algebraic laws in some way. I’m not holding my breath.

Best as I can tell NaN is the IEEE equivalent of |

Mark

On Jul 29, 2015, at 1:44 PM, Edward Kmett notifications@github.com wrote:

Correct. Haskell complies with IEEE on the behavior of NaN at the expense of being able to reason about Ord as an actual total ordering.

— Reply to this email directly or view it on GitHub https://github.com/ekmett/semigroups/issues/50#issuecomment-126074972.