[Haskell-beginners] typeclass confusion
Greg Best
gbest at mac.com
Tue Aug 24 01:37:07 EDT 2010
Thanks. I wasn't trying to do anything terribly practical-- just looking for toy problems to get my head around the type system.
The part I figured was impractical was the "Angular" class, but this is the second feedback that suggested making both Degrees and Radians type constructors rather than alternate value constructors. Is that the right approach? I know the trig functions are already available and they all just traffic in floats, but if this weren't the case, I'd imagine a structure along the lines of
data Angle a = Radians a
| Degrees a
deriving (Eq, Show)
sin :: Angle a -> a
I think the approach you were suggesting is to make Degrees and Radians as types, and put sin as a function of the class. I suppose that is better in that it makes it much easier to implement additional angular measurements (without reimplementing sin).
My reservations were with needing to define sin for each angle type (which I now think my method would force me to do anyway), which could be a potentially expensive operation. With Degree and Radian as types, I think I can get away without reimplementing by using default functions such as:
sin x = radianSin $ rad x
or some such which would only require that I define a radian conversion for each angle type.
(where Degree and Radian are stand ins for useful types and classes)
Cheers--
Greg
On Aug 23, 2010, at 10:01 PM, Isaac Dupree wrote:
> On 08/23/10 22:33, Greg wrote:
>> ...it would be nice to force
>> the type system to check whether I'm using degrees or radians:
>>
>> data Angle a = Radians a
>> | Degrees a
>> deriving (Eq, Show)
>
> You did it wrong... the difference between Radians and Degrees here is only visible at runtime, as they are both of the same type, Angle. Don't feel bad, this confused me for a while as a Haskell-beginner too. An example to "force the type system to check" would be
>
> data Radians a = Radians a deriving (Eq, Show)
> data Degrees a = Degrees a deriving (Eq, Show)
>
> Then you could make conversion functions, say,
> radToDeg :: (Floating a) => Radians a -> Degrees a
> degToRad :: (Floating a) => Degrees a -> Radians a
>
> and implement them;
>
> you *could* have a 'class Angle' or such, if you wanted... perhaps trig functions or such would be sensible to put in there. And/or you could try to make each data-type be a member of Num and related classes (being able to add angles, etc)
>
> For a real program, I think I would try to stick to just one unit (e.g. radians) for internal program use (and convert any outside data to that unit promptly), unless there was a reason that didn't work very well; but the typeclass-stuff is an excellent thing to play with!
>
> -Isaac
> _______________________________________________
> Beginners mailing list
> Beginners at haskell.org
> http://www.haskell.org/mailman/listinfo/beginners
More information about the Beginners
mailing list