Hello again, Please see my comments below On Sun, May 20, 2012 at 9:35 PM, Adam Foltzer wrote:

Hi Nikolay,

I am glad you found my work helpful, and thank you for the suggestions! Please find my responses interspersed below.

That useful. But I'd prefer that for Data.Tensor either vector-space would define instances or Tensor would do that. Have you tried to push instances for Vertex* and Vector* to vector-space or Tensor?

On Sun, May 20, 2012 at 5:59 AM, Nikolay Orlyuk wrote:

While looking into OpenGL/TH.hs I found that it quite incomplete and I

...

understand why. That suggestion at stackoverflow results in a bit boilerplate code:

deriveScalar, deriveScalarAdditiveGroup, deriveScalarVectorSpace, deriveScalarAffineSpace :: [Name] -> Q [Dec] deriveScalar ts = concat <$> forM decls (\qf -> qf ts) where decls = [ deriveScalarAdditiveGroup , deriveScalarVectorSpace , deriveScalarAffineSpace , deriveScalarInnerSpace ] deriveScalarVectorSpace ts = concat <$> mapM f ts where f tn = do t <- [t| $(conT tn) |] vs <- [t| VectorSpace |] (AppT (ConT s) _) <- [t| Scalar () |] -- dummy type to extract Scalar name (VarE h) <- [e| (*^) |] -- refer to actual (*^) from VectorSpace e <- [e| (*) |] -- (*) from Num return [ InstanceD [] (AppT vs t) [ TySynInstD s [t] t, ValD (VarP h) (NormalB e) [] ]]

I've not had an opportunity to work this since I finished the graphics course that motivated its creation, but would be happy to take your modifications as a github pull request ( https://github.com/acfoltzer/vector-space-opengl). I just couldn't justify the time getting the TH to work fully when I was chasing a deadline on a semester project.

I must admit that I do also spend not so much time for that, so I believe there is much better solution. Maybe some Data.Derive or DRifT. Also there is another idea in my mind: use dummy types to mark appropriate places and than just replace them with ones that is needed (kind of template for template-haskell :) ).

...

It's kinda partially checked and partially constructed. BTW, rather than depending on OpenGL its better to use Graphics.Rendering.OpenGL.Raw I think. Also there is types GLclampd and GLclampf (I suspect that they somehow related with OpenCL).

Regarding the dependency on OpenGL vs. OpenGLRaw, some of the semantic versions of the Data.Tensor types (Normal*, Color*) are defined in the full OpenGL package, so I will keep the dependency because of that.

Yep... Normal - should be treated as a vector I guess. I'd suggest OpenGL to make a type wrapper around (similar to Data.VectorSpace.Point). About the Color - I doubt that vector-space semantic for the is useful. Moreover I think that OpenGL should provide a bit more information in their classes ColorComponent to allow users to get value range. Also that would be nice if they would provide Monoid instances for different datatypes (i.e. data AlphaBlend a = AlphaBlend { alphaBlendColorSum :: Color4 a, alphaChannel :: a } etc).

While scalar types doesn't differ whether they are absolute whether they

...

are not. Data.Tensor makes difference between Vertex and Vector. I suspect that made especially for this case: instance AffineSpace a => AffineSpace (Vertex2 a) where type Diff (Vertex2 a) = Vector2 (Diff a) I.e. Diff Vertex shouldn't be Vertex and Vertex a should not belong to AdditiveGroup

Regarding whether vertices and vectors should be treated uniformly, I particularly would appreciate corrections here. The original file was made by Emacs keyboard macro when the more sophisticated bits of Template Haskell failed to be straightforward, so I'm sure there's plenty that one could do to improve the correctness vs. nearly-blind copypasta :)

I'm quite from a different editors camp :) Vim - that's what I prefer ;)

...

If anyone knows how to walk through the whole module in monad Q that might bring more power to this library. I.e. walk through OpenGL.Raw and make declarations for all its scalar types.

This, or use of GeneralizedNewtypeDeriving + StandAloneDeriving would be great to see.

Unfortunately newtype deriving is too weak to get instances with TypeFamilies. In the patch I've sent to you there is only two samples for Vector1 and TexCoord1 in AdditiveGroup. For me that's strange because as I can see that deriving is pretty clear. Maybe someday I'll look into the code for that GeneralizedNewtypeDeriving.

...

Thank you

Thank you too!

Cheers, Adam

Cheers