On Sun, 16 Jun 2013 16:15:25 -0400 Brandon Allbery <allber...@gmail.com> wrote:
> On Sun, Jun 16, 2013 at 4:03 PM, <bri...@aracnet.com> wrote: > > > Changing the declaration to GLdouble -> GLdouble -> GLdouble -> IO() and > > using > > (0.0::GLdouble) fixes it, and I'm not clear on why it's not automagic. > > There are many times I see the > > > Haskell never "automagic"s types in that context; if it expects GLdouble, > it expects GLdouble. Pretending it's Double will not work. It "would" in > the specific case that GLdouble were actually a type synonym for Double; > however, for performance reasons it is not. Haskell Double is not directly > usable from the C-based API used by OpenGL, so GLdouble is a type synonym > for CDouble which is. > > compiler doing type conversion an numerican arguments although sometimes > > the occasional fracSomethingIntegralorOther is required. > > > > I presume the reason the type specification for numeric literals is because > there is no defaulting (and probably can't be without introducing other > strange type issues) for GLdouble. > What I was thinking about, using a very poor choice of words, was this : *Main> let a = 1 *Main> :t a a :: Integer *Main> let a = 1::Double *Main> a 1.0 *Main> :t a a :: Double *Main> so normally 1 would be interpreted as an int, but if I declare 'a' a Double then it gets "promoted" to a Double without me having to call a conversion routine explicitly. That seems automagic to me. (0.0::GLdouble) works to make the compiler happy. So it appears to be taking care of the conversion automagically. So maybe a better question, I hope, is: How can I simply declare 0.0 to be (0.0::GLdouble) and have the functional call work. Doesn't a conversion have to be happening, i.e. shouldn't I really have to do (realToFrac 0.0) ? Brian _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe