[Haskell-cafe] Design of a Physics Interface
westondan at imageworks.com
Fri Nov 30 14:26:28 EST 2007
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,
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 I
> decided that physics objects must not be implemented as arrows,
> because introducing new arrows in the middle of a computation 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
>  Once as SF () (Position,Velocity), and again as SF PhysIn PhysOut
> where PhysIn = (Impulse,Momentum) and PhysOut = (Position,Velocity).
>  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
More information about the Haskell-Cafe