Am Montag, 11. Mai 2009 12:04:07 schrieb Neil Brown:
> [...] So possible additions to your type-class list are Foldable and maybe
> Traversable (no harm, although I'd have to reach further for an example
> for this). I guess the tricky decision might be whether to provide a
> Num instance (again,
Sven,
Am Montag, 4. Mai 2009 13:33:33 schrieb David Duke:
Decoupling basic primitives for geometric modelling from OpenGL would be
useful. [...]
Even just data constructors and instances of these within Functor and
Applicative are a useful starting point. [...]
This leads me to the conc
Sven Panne wrote:
Regarding Functor/Applicative: The obvious instances for e.g. a 2-dimensional
vertex are:
data Vertex2 a = Vertex2 a a
instance Functor Vertex2 where
fmap f (Vertex2 x y) = Vertex2 (f x) (f y)
instance Applicative Vertex2 where
pure a = Vertex2 a a
On Sun, May 10, 2009 at 01:50:08PM +0200, Sven Panne wrote:
> Nevertheless, having a common set of (strict) data types for
> vector math will probably be very useful, even if it won't
> fulfill everybody's needs.
I can say that it would be useful at least for Hipmunk, specially
being able to pass
Am Montag, 4. Mai 2009 13:33:33 schrieb David Duke:
> Decoupling basic primitives for geometric modelling from OpenGL would be
> useful. [...]
> Even just data constructors and instances of these within Functor and
> Applicative are a useful starting point. [...]
I've taken a closer look at the av
Sven,
Decoupling basic primitives for geometric modelling from OpenGL would be
useful. For our work on data visualization
(www.comp.leeds.ac.uk/funvis/) we introduced our own coordinate
primitives for 2D and 3D (Coord2D and Coord3D), along with a simple
typeclass for vector-like operations
Am Sonntag, 3. Mai 2009 00:56:00 schrieb Tillmann Vogt:
> Sven Panne schrieb:
> >* a tiny "ObjectName" package, consisting only of OpenGL's ObjectName
> > class (In "Data.ObjectName"? I'm not very sure about a good place in the
> > hierarchy here.)
>
> How about Data.GraphicsObjects ? [...]
Th
Sven Panne schrieb:
* a tiny "ObjectName" package, consisting only of OpenGL's ObjectName class
(In "Data.ObjectName"? I'm not very sure about a good place in the hierarchy
here.)
How about Data.GraphicsObjects ?
* a package containing most of the data types/newtypes in OpenGL's
Ve
I think splitting this up is a good thing, and at first sight I thought it
was overkill to make 3 micro packages, but when thinking twice I believe it
is indeed the way to go:
- Having StateVar into its own module will hopefully promote its reuse by
other imperative wrapper libs which currently all
Hello Sven,
Saturday, May 2, 2009, 9:14:13 PM, you wrote:
> must, but the actual packaging is not nice. So the obvious idea is to
> introduce 3 new packages which lift out functionality from the OpenGL package:
another possible variant: OpenGL-DataTypes package that joins these 3
--
Best rega
I'd like to get some feedback from the Haskell community about some packaging
issues, so here is my problem: As a medium-term goal, I'd like to decouple the
OpenAL/ALUT packages from the OpenGL package, because there are very sensible
use cases where you might need some sound, but not OpenGL. Th
11 matches
Mail list logo
