[Haskell-cafe] Design of a Physics Interface

[Dan Weston]

There seems to be three salient benefits of using arrows, as I read the 
Abstract and Introduction of Benjamin Lerner, "Arrow Laws and Efficiency 
in Yampa", 2003, 
http://zoo.cs.yale.edu/classes/cs490/03-04a/benjamin.lerner/

1) The discipline of using arrows assists in avoiding space-leaks
    "The reasons underlying this...primarily stemmed from the
     availability of signals as first-class values."
    [the "ugly pain" you experience up front saves you
     chronic pain later. Self-discipline is the key to a happy life.]

2) Arrow syntax    analogous to circuit diagrams =>
    Arrow semantics analogous to signal processing
    [a mental/software model that resembles a physical model
     helps intuitive reasoning by analogy]

3) Satisfying arrow laws guarantees soundness of signal function type
    [you can have faith in the results of your simulation if the basic
     plumbing has been stress-tested in advance.]

* The stuff in brackets is my own interpretation

The overall impression I get is that using arrows makes simulations more 
scalable as overall simulation complexity increases. It will be good to 
get another use-case for this domain of application.

Luke Palmer wrote:
> I'm currently working on idioms for game programming using FRP.  After
> going through several representations of physics as arrows[1] I
> decided that physics objects must not be implemented as arrows,
> because introducing new arrows in the middle of a computation[2] leads
> to ugly pain.
> 
> So far the best approach I have is to represent the physics world as a
> single object World, with a function
> 
>> integrate :: TimeStep -> World -> World
> 
> But I can't figure out a good way to represent bodies in this world.
> I considered:
> 
>> newBody :: (Position,Velocity) -> World -> (Body,World)
> 
> Where Body is an ADT with an internal representation of an Integer or
> something.  The problem with this is that (1) there is no way to
> guarantee that a Body actually exists in a World (which is a minor but
> still annoying issue), and (2) that there's a possibility that you
> could make a Body in one world and use it in another and there would
> be no way to detect the error.
> 
> (2) could be solved using an internal representation of Data.Unique,
> but (1) still remains a problem.  And as long as the function
> 
>> deleteBody :: Body -> World -> World
> 
> exists, it will always remain a problem.  Are there any clever idioms
> I can use for this interface or implementation?  Is there a way to
> store the data for bodies along with the Body object instead of with
> the world in a way that the relationships between them respect
> different generations of the World (through integrate)?  Any other
> ideas?
> 
> Thanks,
> Luke
> 
> [1]  Once as SF () (Position,Velocity), and again as SF PhysIn PhysOut
> where PhysIn = (Impulse,Momentum) and PhysOut = (Position,Velocity).
> 
> [2] Using the arrow joinSF :: SF (Event (SF [a] a)) [a], and other
> similar style functions taking streams of SF events...
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
> 
>