Correct me if I’m wrong but isn’t this precisely where GADTs would excel? On Sun, 29 Jul 2018 at 09:04, Dennis Raddle wrote:

Thanks Vanessa. The issue is that not everything will have a position or velocity. And some things will have more than those. There's a large overlapping set of possibilities that I can't quite predict until after I've finished several versions.

However, I think I have a solution. This is actually in Purescript, which has has extensible record types. Each object will be represented by its own unique record, but there are mechanisms to write polymorphic code that operates on just portions of the records. I think that will get me through the first few versions of this program.

Purescript also has dynamic types, but I suspect those will be hard to debug. When I'm developing code, I like to get helpful error messages. Please, no untraceable crashes from many levels deep in the stack. I don't know if that's what happens when a dynamic type fails to be the expected type, but I do know that these kinds of crashes are even harder to debug in Purescript than Haskell, as they happen in the compiled Javascript (which I don't understand much).

D

Mike

On Sat, Jul 28, 2018 at 9:14 PM, Vanessa McHale wrote:

...

If everything you use will have a color, position, and velocity I'd just use a product type, i.e.

data itemState = ItemState Color Point Vector

or even

data ItemState = ItemState (Maybe Color) (Maybe Point) (Maybe Vector)

Alternately, if you do want to go the dynamic route, `Data.Dynamic` in `base` actually has some facilities for dynamic programming

On 07/28/2018 05:04 PM, Dennis Raddle wrote:

I'm actually working in Purescript, but the issue is pretty much the same as one would encounter in Haskell.

My application (animation of math-related ideas) is changing constantly. It's research, and I don't know where I'll be with it next week, or even tomorrow.

For instance, the kinds of "objects" I'm animating (numbers, equations) and the way they move and interact with each other is a research project, and I'm constantly ripping out parts of my application and scavenging them for variations on a theme.

My objects need state. At this point I'm thinking of just putting the state into a map with strings as keys and some kind of sum type to represent each data item I might need.

So if I want to represent that an object has a particular color and position and velocity,

itemState = M.fromList [("color" , DataColor blue ) ,("position", DataPoint 500.0 100.0) ,("velocity", DataVector 50.0 45.0 ) ]

Which starts to look more like a dynamically-typed scripting language. But it's not hard to work with. I can uses lenses/prisms to inspect and update state, and it's okay if my program crashes on encountering malformed state.

What this lets me do is create new objects that mix and match parts of old objects, and copy and paste a lot of the code.

Is there a better way to do this? Is there a compromise I can make that will allow the compiler to help me out more with finding errors at compile time?

D

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to:http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.