hackage vector-space-opengl

[Nikolay Orlyuk]

Hello again,

Please see my comments below

On Sun, May 20, 2012 at 9:35 PM, Adam Foltzer <acfoltzer at gmail.com> 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 <virkony at gmail.com> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20120521/6c9f01e6/attachment.htm>