packages feed

Yampa 0.9.2 → 0.9.2.1

raw patch · 20 files changed

+348/−107 lines, 20 filessetup-changed

Files

+ README-1ST.txt view
@@ -0,0 +1,23 @@+This is an "inofficial release" of the version of Yampa that uses GADT-enabled+dynamic optimization as described in the ICFP'05 paper "Dynamic Optimization+for Functional Reactive Programming using Generalized Algebraic Data Types".++The code is being made available only because a number of people have asked+for it. It is not supposed to be useful in any way as it stands. If it happens+to be useful to you, great, it's your lucky day!++The code is very messy at least at two levels:++  * Work in progress: lots of code fragments from trying out various+    approaches around; the code for the most successful approaches never got+    tidied up; the GADT optimizations have not been implemented throughout;+    lots of notes and comments around, some of which may still be relevant,+    others which are not, and others which only ever were of interest to me;+    etc.++  * The fundamental approach taken does not really scale that well+    as one gets a (small) combinatorial explosion of cases to+    consider for optimization. Thus there is way more code here than+    one would hope, some of it quite repetitive.++Use at your own risk! ;-)
− Setup.hs 
@@ -1,2 +0,0 @@-import Distribution.Simple-main = defaultMain
+ Setup.lhs view
@@ -0,0 +1,3 @@+#!/usr/bin/env runhaskell+> import Distribution.Simple+> main = defaultMain
Yampa.cabal view
@@ -1,5 +1,5 @@ name: Yampa-version: 0.9.2+version: 0.9.2.1 cabal-Version: >= 1.2 license: BSD3 license-file: LICENSE@@ -11,9 +11,10 @@ description: Domain-specific language embedded in Haskell for programming hybrid (mixed discrete-time and continuous-time) systems.              Yampa is based on the concepts of Functional Reactive Programming (FRP) and is structured using arrow combinators. build-type: Simple-extra-source-files: README Tested-With:        GHC Extra-Source-Files:+  README-1ST.txt+   tests/AFRPTests.hs,         tests/AFRPTestsCommon.hs,        tests/AFRPTestsArr.hs,   tests/AFRPTestsComp.hs,     tests/AFRPTestsFirstSecond.hs,   tests/AFRPTestsLaws.hs,   tests/AFRPTestsLoop.hs,     tests/AFRPTestsLoopLaws.hs,      tests/AFRPTestsBasicSF.hs,
src/FRP/Yampa.hs view
@@ -1,28 +1,51 @@ {-# LANGUAGE GADTs, Rank2Types #-}---- New version using GADTs---- ToDo--- Specialize def. of repeatedly. Could have an impact on invaders.--- New defs for accs using SFAcc--- Make sure opt worked: e.g. repeatedly >>> count >>> arr (fmap sqr)--- Introduce SFAccHld.--- See if possible to unify AccHld wity Acc??? They are so close.--- Introduce SScan. BUT KEEP IN MIND: Most if not all opts would--- have been possible without GADTs???--- Look into pairs. At least pairing of SScan ought to be interesting.--- Would be nice if we could get rid of first & second with impunity--- thanks to Id optimizations. That's a clear win, with or without--- an explicit pair combinator.--- delayEventCat is a bit complicated ...---- Random ideas--- What if one used rules to optimize+-----------------------------------------------------------------------------------------+-- |+-- Module      :  FRP.Yampa+-- Copyright   :  (c) Antony Courtney and Henrik Nilsson, Yale University, 2003+-- License     :  BSD-style (see the LICENSE file in the distribution)+--+-- Maintainer  :  nilsson@cs.yale.edu+-- Stability   :  provisional+-- Portability :  non-portable (GHC extensions)+--+-- New version using GADTs.+--+-- ToDo:+--+-- * Specialize def. of repeatedly. Could have an impact on invaders.+--+-- * New defs for accs using SFAcc+--+-- * Make sure opt worked: e.g.+--+--   >     repeatedly >>> count >>> arr (fmap sqr)+--+-- * Introduce SFAccHld.+--+-- * See if possible to unify AccHld wity Acc??? They are so close.+--+-- * Introduce SScan. BUT KEEP IN MIND: Most if not all opts would+--   have been possible without GADTs???+--+-- * Look into pairs. At least pairing of SScan ought to be interesting.+--+-- * Would be nice if we could get rid of first & second with impunity+--   thanks to Id optimizations. That's a clear win, with or without+--   an explicit pair combinator.+--+-- * delayEventCat is a bit complicated ...+--+--+-- Random ideas:+--+-- * What if one used rules to optimize --   - (arr :: SF a ()) to (constant ()) --   - (arr :: SF a a) to identity --   But inspection of invader source code seem to indicate that --   these are not very common cases at all.--- It would be nice if it was possible to come up with opt. rules+--+-- * It would be nice if it was possible to come up with opt. rules --   that are invariant of how signal function expressions are --   parenthesized. Right now, we have e.g. --       arr f >>> (constant c >>> sf)@@ -33,39 +56,44 @@ --   What if we didn't use SF' but --      SFComp :: <tfun> -> SF' a b -> SF' b c -> SF' a c --   ???---   The transition function would still be optimized in (pretty much)+--+-- * The transition function would still be optimized in (pretty much) --   the current way, but it would still be possible to look "inside" --   composed signal functions for lost optimization opts. --   Seems to me this could be done without too much extra effort/no dupl. --   work. --   E.g. new cpAux, the general case:+--+-- @ --      cpAux sf1 sf2 = SFComp tf sf1 sf2 --          where --              tf dt a = (cpAux sf1' sf2', c) --                  where --                      (sf1', b) = (sfTF' sf1) dt a --                      (sf2', c) = (sfTF' sf2) dt b+-- @ -----  The ONLY change was changing the constructor from SF' to SFComp and---  adding sf1 and sf2 to the constructor app.!+-- * The ONLY change was changing the constructor from SF' to SFComp and+--   adding sf1 and sf2 to the constructor app.! -----  An optimized case:+-- * An optimized case: --     cpAuxC1 b sf1 sf2               = SFComp tf sf1 sf2---  So cpAuxC1 gets an extra arg, and we change the constructor.---  But how to exploit without writing 1000s of rules???---  Maybe define predicates on SFComp to see if the first or second---  sf are "interesting", and if so, make "reassociate" and make a---  recursive call? E.g. we're in the arr case, and the first sf is another---  arr, so we'd like to combine the two.+--   So cpAuxC1 gets an extra arg, and we change the constructor.+--   But how to exploit without writing 1000s of rules???+--   Maybe define predicates on SFComp to see if the first or second+--   sf are "interesting", and if so, make "reassociate" and make a+--   recursive call? E.g. we're in the arr case, and the first sf is another+--   arr, so we'd like to combine the two. -----  It would also be intersting, then, to know when to STOP playing this---  game, due to the overhead involved.+-- * It would also be intersting, then, to know when to STOP playing this+--   game, due to the overhead involved. -----  Why don't we have a "SWITCH" constructor that indicates that the---  structure will change, and thus that it is worthwile to keep---  looking for opt. opportunities, whereas a plain "SF'" would---  indicate that things NEVER are going to change, and thus we can just---  as well give up?+-- * Why don't we have a "SWITCH" constructor that indicates that the+--   structure will change, and thus that it is worthwile to keep+--   looking for opt. opportunities, whereas a plain "SF'" would+--   indicate that things NEVER are going to change, and thus we can just+--   as well give up?+-----------------------------------------------------------------------------------------  module FRP.Yampa ( -- Re-exported module, classes, and types@@ -257,7 +285,6 @@ 	      		--    -> (Bool -> b -> IO Bool)               		--    -> SF a b 	      		--    -> IO ()-{-     ReactHandle,     reactInit,          --    IO a -- init                         --    -> (ReactHandle a b -> Bool -> b -> IO Bool) -- actuate@@ -267,7 +294,6 @@     react,              --    ReactHandle a b                         --    -> (DTime,Maybe a)                         --    -> IO Bool--}  -- Embedding (tentative: will be revisited)     DTime,		-- [s] Sampling interval, always > 0.@@ -288,7 +314,7 @@ import FRP.Yampa.Event import FRP.Yampa.VectorSpace --- import IORef+import Data.IORef  infixr 0 -->, >--, -=>, >=- @@ -3110,7 +3136,6 @@                     (sf', b') = (sfTF' sf) dt a' 		loop sf' a' b' -{-  -- An API for animating a signal function when some other library -- needs to own the top-level control flow:@@ -3154,7 +3179,6 @@      writeIORef rh (rs {rsSF = sf',rsA = a',rsB = b'})      done <- actuate rh True b'      return done     --}   ------------------------------------------------------------------------------
src/FRP/Yampa/AffineSpace.hs view
@@ -1,4 +1,17 @@ {-# LANGUAGE MultiParamTypeClasses, FunctionalDependencies, FlexibleInstances #-}+-----------------------------------------------------------------------------------------+-- |+-- Module      :  FRP.Yampa.AffineSpace+-- Copyright   :  (c) Antony Courtney and Henrik Nilsson, Yale University, 2003+-- License     :  BSD-style (see the LICENSE file in the distribution)+--+-- Maintainer  :  nilsson@cs.yale.edu+-- Stability   :  provisional+-- Portability :  non-portable (GHC extensions)+--+-- Affine space type relation.+--+-----------------------------------------------------------------------------------------  module FRP.Yampa.AffineSpace where
src/FRP/Yampa/Diagnostics.hs view
@@ -1,3 +1,16 @@+-----------------------------------------------------------------------------------------+-- |+-- Module      :  FRP.Yampa.Diagnostics+-- Copyright   :  (c) Antony Courtney and Henrik Nilsson, Yale University, 2003+-- License     :  BSD-style (see the LICENSE file in the distribution)+--+-- Maintainer  :  nilsson@cs.yale.edu+-- Stability   :  provisional+-- Portability :  portable+--+-- Standardized error-reporting for Yampa+-----------------------------------------------------------------------------------------+ module FRP.Yampa.Diagnostics where  usrErr :: String -> String -> String -> a
src/FRP/Yampa/Event.hs view
@@ -1,62 +1,75 @@+-----------------------------------------------------------------------------------------+-- |+-- Module      :  FRP.Yampa.Event+-- Copyright   :  (c) Antony Courtney and Henrik Nilsson, Yale University, 2003+-- License     :  BSD-style (see the LICENSE file in the distribution)+--+-- Maintainer  :  nilsson@cs.yale.edu+-- Stability   :  provisional+-- Portability :  portable+--+-- Definition of Yampa Event type.+-- -- Note on naming conventions used in this module. -- -- Names here might have to be rethought. It's really a bit messy.--- In general, the aim has been short and convenient names (like "tag",--- "attach", "lMerge") and thus we have tried to stay away from suffixing/--- prefixing conventions. E.g. "Event" as a common suffix would be very+-- In general, the aim has been short and convenient names (like 'tag',+-- 'attach', 'lMerge') and thus we have tried to stay away from suffixing/+-- prefixing conventions. E.g. 'Event' as a common suffix would be very -- verbose. -- -- However, part of the names come from a desire to stay close to similar--- functions for the Maybe type. e.g. "event", "fromEvent", "isEvent".--- In many cases, this use of "Event" can could understood to refer to the--- constructor "Event", not to the type name "Event". Thus this use of+-- functions for the Maybe type. e.g. 'event', 'fromEvent', 'isEvent'.+-- In many cases, this use of 'Event' can could understood to refer to the+-- constructor 'Event', not to the type name 'Event'. Thus this use of -- event should not be seen as a suffixing-with-type-name convention. But--- that is obviously not easy to see, and, more over, interpreting "Event"+-- that is obviously not easy to see, and, more over, interpreting 'Event' -- as the name of the type might make equally good or better sense. E.g.--- "fromEvent" can also be seen as a function taking an event signal,+-- 'fromEvent' can also be seen as a function taking an event signal, -- which is a partial function on time, to a normal signal. The latter is -- then undefined when the source event function is undefined. -- -- In other cases, it has been necessary to somehow stay out of the way of -- names used by the prelude or other commonly imported modules/modules--- which could be expected to be used heavily in AFRP code. In those cases--- a suffix "E" have been added. Examples are "filterE" (exists in Prelude)--- and "joinE" (exists in Monad). Maybe the suffix isn't necessary in the+-- which could be expected to be used heavily in Yampa code. In those cases+-- a suffix 'E' have been added. Examples are 'filterE' (exists in Prelude)+-- and 'joinE' (exists in Monad). Maybe the suffix isn't necessary in the -- last case. ----- Some functions (actually only one currently, mapFilterE") have got an "E"+-- Some functions (actually only one currently, 'mapFilterE') have got an 'E' -- suffix just because they're closely related (by name or semantics) to one--- which already has an "E" suffix. Another candidate would be "splitE" to--- complement "joinE". But events carrying pairs could obviously have other--- sources than a "joinE", so currently it is called "split".+-- which already has an 'E' suffix. Another candidate would be 'splitE' to+-- complement 'joinE'. But events carrying pairs could obviously have other+-- sources than a 'joinE', so currently it is called 'split'. ----- 2003-05-19: Actually, have now changed to "splitE" to avoid a clash--- with the method "split" in the class RandomGen.+-- 2003-05-19: Actually, have now changed to 'splitE' to avoid a clash+-- with the method 'split' in the class RandomGen. ----- 2003-05-19: What about "gate"? Stands out compared to e.g. "filterE".+-- 2003-05-19: What about 'gate'? Stands out compared to e.g. 'filterE'. ----- Currently the "E" suffix is considered an exception. Maybe we should use--- completely different names to avoid the "E" suffix. If the functions--- are not used that often, "Event" might be approriate. Alternatively the--- suffix "E" should be adopted globaly (except if the name already contains--- "event" in some form?).+-- Currently the 'E' suffix is considered an exception. Maybe we should use+-- completely different names to avoid the 'E' suffix. If the functions+-- are not used that often, 'Event' might be approriate. Alternatively the+-- suffix 'E' should be adopted globaly (except if the name already contains+-- 'event' in some form?). ----- Arguably, having both a type "Event" and a constructor "Event" is confusing--- since there are more than one constructor. But the name "Event" for the+-- Arguably, having both a type 'Event' and a constructor 'Event' is confusing+-- since there are more than one constructor. But the name 'Event' for the -- constructor is quite apt. It's really the type name that is wrong. But -- no one has found a better name, and changing it would be a really major--- undertaking. Yes, the constructor "Event" is not exported, but we still+-- undertaking. Yes, the constructor 'Event' is not exported, but we still -- need to talk conceptually about them. On the other hand, if we consider -- Event-signals as partial functions on time, maybe it isn't so confusing:--- they just don't have a value between events, so "NoEvent" does not really+-- they just don't have a value between events, so 'NoEvent' does not really -- exist conceptually. -- -- ToDo: -- - Either: reveal NoEvent and Event---   or:     introcuce "event = Event", call what's now "event" "fromEvent",---           and call what's now called "fromEvent" something else, like---           "unsafeFromEvent"??? Better, dump it! After all, using current---	     names, "fromEvent = event undefined"!+--   or:     introcuce 'event = Event', call what's now 'event' 'fromEvent',+--           and call what's now called 'fromEvent' something else, like+--           'unsafeFromEvent'??? Better, dump it! After all, using current+--	     names, 'fromEvent = event undefined'!+-----------------------------------------------------------------------------------------  module FRP.Yampa.Event where
src/FRP/Yampa/Forceable.hs view
@@ -1,3 +1,16 @@+-----------------------------------------------------------------------------------------+-- |+-- Module      :  FRP.Yampa.Forceable+-- Copyright   :  (c) Zhanyong Wan, Yale University, 2003+-- License     :  BSD-style (see the LICENSE file in the distribution)+--+-- Maintainer  :  nilsson@cs.yale.edu+-- Stability   :  provisional+-- Portability :  portable+--+-- Hyperstrict evaluation.+-----------------------------------------------------------------------------------------+ module FRP.Yampa.Forceable where
src/FRP/Yampa/Geometry.hs view
@@ -1,3 +1,16 @@+-----------------------------------------------------------------------------------------+-- |+-- Module      :  FRP.Yampa.Geometry+-- Copyright   :  (c) Antony Courtney and Henrik Nilsson, Yale University, 2003+-- License     :  BSD-style (see the LICENSE file in the distribution)+--+-- Maintainer  :  nilsson@cs.yale.edu+-- Stability   :  provisional+-- Portability :  non-portable (GHC extensions)+--+-- Basic geometrical abstractions.+-----------------------------------------------------------------------------------------+ module FRP.Yampa.Geometry (     module FRP.Yampa.VectorSpace,     module FRP.Yampa.AffineSpace,
src/FRP/Yampa/Internals.hs view
@@ -1,22 +1,22 @@-{--******************************************************************************-*                                  A F R P                                   *-*                                                                            *-*       Module:         AFRPInternals                                        *-*       Purpose:        An interface giving access to some of the internal   *-*			details of the AFRP implementation.		     *-*	Authors:	Antony Courtney and Henrik Nilsson		     *-*                                                                            *-*             Copyright (c) Yale University, 2003                            *-*                                                                            *-******************************************************************************--}-+-----------------------------------------------------------------------------------------+-- |+-- Module      :  FRP.Yampa.Internals+-- Copyright   :  (c) Antony Courtney and Henrik Nilsson, Yale University, 2003+-- License     :  BSD-style (see the LICENSE file in the distribution)+--+-- Maintainer  :  nilsson@cs.yale.edu+-- Stability   :  provisional+-- Portability :  portable+--+-- An interface giving access to some of the internal+-- details of the Yampa implementation.+-- -- This interface is indended to be used when the need arises to break--- abstraction barriers, e.g. for interfacing AFRP to the real world, for+-- abstraction barriers, e.g. for interfacing Yampa to the real world, for -- debugging purposes, or the like. Be aware that the internal details -- may change. Relying on this interface means that your code is not -- insulated against such changes.+-----------------------------------------------------------------------------------------  module FRP.Yampa.Internals (     Event(..)		-- The event type, its constructors, and instances.
src/FRP/Yampa/MergeableRecord.hs view
@@ -1,4 +1,17 @@+-----------------------------------------------------------------------------------------+-- |+-- Module      :  FRP.Yampa.Miscellany+-- Copyright   :  (c) Antony Courtney and Henrik Nilsson, Yale University, 2003+-- License     :  BSD-style (see the LICENSE file in the distribution)+--+-- Maintainer  :  nilsson@cs.yale.edu+-- Stability   :  provisional+-- Portability :  portable+--+-- Framework for record merging.+-- -- Idea:+-- -- MergeableRecord is intended to be a super class for classes providing -- update operations on records. The ADT induced by such a set of operations -- can be considered a "mergeable record", which can be merged into larger@@ -6,29 +19,37 @@ -- a mergeable record into a record. -- -- Typical use:+-- -- Given -----   data Foo = Foo {l1 :: T1, l2 :: T2}+-- >  data Foo = Foo {l1 :: T1, l2 :: T2} -- -- one define a mergeable record type (MR Foo) by the following instance: --+-- @ --   instance MergeableRecord Foo where --       mrDefault = Foo {l1 = v1_dflt, l2 = v2_dflt}+-- @ -- -- Typically, one would also provide definitions for setting the fields, -- possibly (but not necessarily) overloaded: --+-- @ --   instance HasL1 Foo where --       setL1 v = mrMake (\foo -> foo {l1 = v})+-- @ -- -- Now Foo records can be created as follows: --+-- @ --   let foo1 = setL1 v1 --   ... --   let foo2 = setL2 v2 ~+~ foo1 --   ... --   let foo<N> = setL1 vN ~+~ foo<N-1> --   let fooFinal = mrFinalize foo<N>+-- @+-----------------------------------------------------------------------------------------  module FRP.Yampa.MergeableRecord (     MergeableRecord(..),
src/FRP/Yampa/Miscellany.hs view
@@ -1,6 +1,22 @@+-----------------------------------------------------------------------------------------+-- |+-- Module      :  FRP.Yampa.Miscellany+-- Copyright   :  (c) Antony Courtney and Henrik Nilsson, Yale University, 2003+-- License     :  BSD-style (see the LICENSE file in the distribution)+--+-- Maintainer  :  nilsson@cs.yale.edu+-- Stability   :  provisional+-- Portability :  portable+--+-- Collection of entities that really should be part+-- of the Haskell 98 prelude or simply have no better+-- home.+-- -- !!! Reverse function composition should go.--- !!! Better to use <<< and >>> for, respectively,+-- !!! Better to use '<<<' and '>>>' for, respectively, -- !!! function composition and reverse function composition.+--+-----------------------------------------------------------------------------------------  module FRP.Yampa.Miscellany ( -- Reverse function composition
src/FRP/Yampa/Point2.hs view
@@ -1,6 +1,19 @@ {-# LANGUAGE MultiParamTypeClasses, FlexibleInstances #-}-+-----------------------------------------------------------------------------------------+-- |+-- Module      :  FRP.Yampa.Point2+-- Copyright   :  (c) Antony Courtney and Henrik Nilsson, Yale University, 2003+-- License     :  BSD-style (see the LICENSE file in the distribution)+--+-- Maintainer  :  nilsson@cs.yale.edu+-- Stability   :  provisional+-- Portability :  non-portable (GHC extensions)+--+-- 2D point abstraction (R^2).+-- -- ToDo: Deriving Show, or provide dedicated show instance?+--+-----------------------------------------------------------------------------------------  module FRP.Yampa.Point2 (     -- module AFRPVectorSpace,
src/FRP/Yampa/Point3.hs view
@@ -1,4 +1,17 @@ {-# LANGUAGE MultiParamTypeClasses, FlexibleInstances #-}+-----------------------------------------------------------------------------------------+-- |+-- Module      :  FRP.Yampa.Point3+-- Copyright   :  (c) Antony Courtney and Henrik Nilsson, Yale University, 2003+-- License     :  BSD-style (see the LICENSE file in the distribution)+--+-- Maintainer  :  nilsson@cs.yale.edu+-- Stability   :  provisional+-- Portability :  non-portable (GHC extensions)+--+-- 3D point abstraction (R^3).+--+-----------------------------------------------------------------------------------------  module FRP.Yampa.Point3 (     -- module AFRPVectorSpace,
src/FRP/Yampa/Task.hs view
@@ -1,5 +1,17 @@ {-# LANGUAGE Rank2Types #-}-+-----------------------------------------------------------------------------------------+-- |+-- Module      :  FRP.Yampa.Task+-- Copyright   :  (c) Antony Courtney and Henrik Nilsson, Yale University, 2003+-- License     :  BSD-style (see the LICENSE file in the distribution)+--+-- Maintainer  :  nilsson@cs.yale.edu+-- Stability   :  provisional+-- Portability :  non-portable (GHC extensions)+--+-- Task abstraction on top of signal transformers.+--+-----------------------------------------------------------------------------------------  module FRP.Yampa.Task (     Task,
src/FRP/Yampa/Utilities.hs view
@@ -1,22 +1,38 @@+-----------------------------------------------------------------------------------------+-- |+-- Module      :  FRP.Yampa.Utilities+-- Copyright   :  (c) Antony Courtney and Henrik Nilsson, Yale University, 2003+-- License     :  BSD-style (see the LICENSE file in the distribution)+--+-- Maintainer  :  nilsson@cs.yale.edu+-- Stability   :  provisional+-- Portability :  portable+--+-- Derived utility definitions.+-- -- ToDo:--- Possibly add+--+-- * Possibly add --       impulse :: VectorSpace a k => a -> Event a --   But to do that, we need access to Event, which we currently do not have.---   The general arrow utilities should be moved to a module---   AFRPArrowUtilities.---   I'm not sure structuring the AFRP "core" according to what is+--+-- * The general arrow utilities should be moved to a module+--   FRP.Yampa.Utilities.+--+-- * I'm not sure structuring the Yampa \"core\" according to what is --   core functionality and what's not is all that useful. There are --   many cases where we want to implement combinators that fairly --   easily could be implemented in terms of others as primitives simply --   because we expect that that implementation is going to be much more --   efficient, and that the combinators are used sufficiently often to---   warrant doing this. E.g. "switch" should be a primitive, even though---   it could be derived from "pSwitch".---  Reconsider "recur". If an event source has an immediate occurrence,+--   warrant doing this. E.g. 'switch' should be a primitive, even though+--   it could be derived from 'pSwitch'.+--+-- * Reconsider 'recur'. If an event source has an immediate occurrence, --   we'll get into a loop. For example: recur now. Maybe suppress --   initial occurrences? Initial occurrences are rather pointless in this --   case anyway.-+-----------------------------------------------------------------------------------------  module FRP.Yampa.Utilities ( -- Now defined in Control.Arrow
src/FRP/Yampa/Vector2.hs view
@@ -1,7 +1,18 @@ {-# LANGUAGE MultiParamTypeClasses, FlexibleInstances #-}--+-----------------------------------------------------------------------------------------+-- |+-- Module      :  FRP.Yampa.Vector2+-- Copyright   :  (c) Antony Courtney and Henrik Nilsson, Yale University, 2003+-- License     :  BSD-style (see the LICENSE file in the distribution)+--+-- Maintainer  :  nilsson@cs.yale.edu+-- Stability   :  provisional+-- Portability :  non-portable (GHC extensions)+--+-- 2D vector abstraction (R^2).+-- -- ToDo: Deriving Show, or provide dedicated show instance?+-----------------------------------------------------------------------------------------  module FRP.Yampa.Vector2 (     -- module AFRPVectorSpace,
src/FRP/Yampa/Vector3.hs view
@@ -1,6 +1,18 @@ {-# LANGUAGE FlexibleInstances, MultiParamTypeClasses #-}-+-----------------------------------------------------------------------------------------+-- |+-- Module      :  FRP.Yampa.Vector3+-- Copyright   :  (c) Antony Courtney and Henrik Nilsson, Yale University, 2003+-- License     :  BSD-style (see the LICENSE file in the distribution)+--+-- Maintainer  :  nilsson@cs.yale.edu+-- Stability   :  provisional+-- Portability :  non-portable (GHC extensions)+--+-- 3D vector abstraction (R^3).+-- -- ToDo: Deriving Show, or provide dedicated show instance?+-----------------------------------------------------------------------------------------  module FRP.Yampa.Vector3 (     -- module AFRPVectorSpace,
src/FRP/Yampa/VectorSpace.hs view
@@ -1,4 +1,17 @@ {-# LANGUAGE MultiParamTypeClasses, FunctionalDependencies, FlexibleInstances #-}+-----------------------------------------------------------------------------------------+-- |+-- Module      :  FRP.Yampa.VectorSpace+-- Copyright   :  (c) Antony Courtney and Henrik Nilsson, Yale University, 2003+-- License     :  BSD-style (see the LICENSE file in the distribution)+--+-- Maintainer  :  nilsson@cs.yale.edu+-- Stability   :  provisional+-- Portability :  non-portable (GHC extensions)+--+-- Vector space type relation and basic instances.+--+-----------------------------------------------------------------------------------------  module FRP.Yampa.VectorSpace where