Re: hackage vector-space-opengl

21 May 2012


      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