Because it messes up atom support for elmx, I often defined this:

gt : a -> b -> bool
gt a b = a > b

And used it like:

if a `gt` b then

You could use that for your tagged type and it'd perhaps have reasonable 
readability..

On Saturday, September 24, 2016 at 3:24:21 PM UTC-7, Brian Marick wrote:
>
> I’m trying to dutifully use tagged types instead of, say, `Float`:
>
>
> type DropsPerSecond
>   = DropsPerSecond Float
>
>
> It turns out I want to know which of two `DropsPerSecond` is larger. Which 
> suggests this:
>
> (>) : DropsPerSecond -> DropsPerSecond -> Bool
> (>) (DropsPerSecond left) (DropsPerSecond right) =
>   left > right
>
> However, that produces this error message:
>
> The left argument of (>) is causing a type mismatch. 18| left > right ^^^^ 
> (>) 
> is expecting the left argument to be a: DropsPerSecond But the left 
> argument is: Float 
>
>
> This doesn’t happen if I use `(<><>)` instead of `(>)`. Nor does it happen 
> if I use `gt`. 
>
> Help me understand?
>
> —————
>
> Somewhat related is this question: is this the right way to tag types? 
>
> —————
>
> Also: I’m finding these types fairly awkward to work with, in that I have 
> functions that want to operate on the base type and also the wrapping type 
> (typically to pass work to other functions). It seems to me that means I 
> have to do things like this semi-contrived example: 
>
> animationSteps dropsPerSecond =
>   let
>     (DropsPerSecond raw) = dropsPerSecond
>   in 
>     if raw > 8.0 then
>       steadyStream
>     else
>       fallingDrop dropsPerSecond
>
> Given decent tests (which I’m good at), I’m dubious that all this work to 
> avoid the relatively small chance of confusing a-float-that-means-duration 
> with a-float-that-means-rate is cost-effective. However, I am intent on 
> going all-in on “the Elm/Haskell way”, so I’m curious whether I’m 
> approaching this all wrong. Also happy to hear experienced people tell me 
> that the extra work does indeed pay off.
>
>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to