diff --git a/README-1ST.txt b/README-1ST.txt new file mode 100644 --- /dev/null +++ b/README-1ST.txt @@ -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! ;-) diff --git a/Setup.hs b/Setup.hs deleted file mode 100644 --- a/Setup.hs +++ /dev/null @@ -1,2 +0,0 @@ -import Distribution.Simple -main = defaultMain diff --git a/Setup.lhs b/Setup.lhs new file mode 100644 --- /dev/null +++ b/Setup.lhs @@ -0,0 +1,3 @@ +#!/usr/bin/env runhaskell +> import Distribution.Simple +> main = defaultMain diff --git a/Yampa.cabal b/Yampa.cabal --- a/Yampa.cabal +++ b/Yampa.cabal @@ -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, diff --git a/src/FRP/Yampa.hs b/src/FRP/Yampa.hs --- a/src/FRP/Yampa.hs +++ b/src/FRP/Yampa.hs @@ -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 :: -> 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 --} ------------------------------------------------------------------------------ diff --git a/src/FRP/Yampa/AffineSpace.hs b/src/FRP/Yampa/AffineSpace.hs --- a/src/FRP/Yampa/AffineSpace.hs +++ b/src/FRP/Yampa/AffineSpace.hs @@ -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 diff --git a/src/FRP/Yampa/Diagnostics.hs b/src/FRP/Yampa/Diagnostics.hs --- a/src/FRP/Yampa/Diagnostics.hs +++ b/src/FRP/Yampa/Diagnostics.hs @@ -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 diff --git a/src/FRP/Yampa/Event.hs b/src/FRP/Yampa/Event.hs --- a/src/FRP/Yampa/Event.hs +++ b/src/FRP/Yampa/Event.hs @@ -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 diff --git a/src/FRP/Yampa/Forceable.hs b/src/FRP/Yampa/Forceable.hs --- a/src/FRP/Yampa/Forceable.hs +++ b/src/FRP/Yampa/Forceable.hs @@ -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 diff --git a/src/FRP/Yampa/Geometry.hs b/src/FRP/Yampa/Geometry.hs --- a/src/FRP/Yampa/Geometry.hs +++ b/src/FRP/Yampa/Geometry.hs @@ -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, diff --git a/src/FRP/Yampa/Internals.hs b/src/FRP/Yampa/Internals.hs --- a/src/FRP/Yampa/Internals.hs +++ b/src/FRP/Yampa/Internals.hs @@ -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. diff --git a/src/FRP/Yampa/MergeableRecord.hs b/src/FRP/Yampa/MergeableRecord.hs --- a/src/FRP/Yampa/MergeableRecord.hs +++ b/src/FRP/Yampa/MergeableRecord.hs @@ -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 = setL1 vN ~+~ foo -- let fooFinal = mrFinalize foo +-- @ +----------------------------------------------------------------------------------------- module FRP.Yampa.MergeableRecord ( MergeableRecord(..), diff --git a/src/FRP/Yampa/Miscellany.hs b/src/FRP/Yampa/Miscellany.hs --- a/src/FRP/Yampa/Miscellany.hs +++ b/src/FRP/Yampa/Miscellany.hs @@ -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 diff --git a/src/FRP/Yampa/Point2.hs b/src/FRP/Yampa/Point2.hs --- a/src/FRP/Yampa/Point2.hs +++ b/src/FRP/Yampa/Point2.hs @@ -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, diff --git a/src/FRP/Yampa/Point3.hs b/src/FRP/Yampa/Point3.hs --- a/src/FRP/Yampa/Point3.hs +++ b/src/FRP/Yampa/Point3.hs @@ -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, diff --git a/src/FRP/Yampa/Task.hs b/src/FRP/Yampa/Task.hs --- a/src/FRP/Yampa/Task.hs +++ b/src/FRP/Yampa/Task.hs @@ -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, diff --git a/src/FRP/Yampa/Utilities.hs b/src/FRP/Yampa/Utilities.hs --- a/src/FRP/Yampa/Utilities.hs +++ b/src/FRP/Yampa/Utilities.hs @@ -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 diff --git a/src/FRP/Yampa/Vector2.hs b/src/FRP/Yampa/Vector2.hs --- a/src/FRP/Yampa/Vector2.hs +++ b/src/FRP/Yampa/Vector2.hs @@ -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, diff --git a/src/FRP/Yampa/Vector3.hs b/src/FRP/Yampa/Vector3.hs --- a/src/FRP/Yampa/Vector3.hs +++ b/src/FRP/Yampa/Vector3.hs @@ -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, diff --git a/src/FRP/Yampa/VectorSpace.hs b/src/FRP/Yampa/VectorSpace.hs --- a/src/FRP/Yampa/VectorSpace.hs +++ b/src/FRP/Yampa/VectorSpace.hs @@ -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