Ubuntu
haskell-reactive-banana package

haskell-reactive-banana 0.4.2.0-1 source package in Ubuntu

Changelog

haskell-reactive-banana (0.4.2.0-1) unstable; urgency=low

  * Initial release.
 -- Ubuntu Archive Auto-Sync <email address hidden>   Sat,  12 Nov 2011 07:24:50 +0000

Upload details

Uploaded by:
Ubuntu Archive Auto-Sync
Uploaded to:
Precise
Original maintainer:
Debian Haskell Group
Architectures:
any all
Section:
haskell
Urgency:
Low Urgency

See full publishing history Publishing

Series Pocket Published Component Section

Downloads

File Size SHA-256 Checksum
haskell-reactive-banana_0.4.2.0.orig.tar.gz 16.7 KiB 70a6fe08af98fe038238baecaf94c27bab3cc79320d830ffacd6df216dfb8ebc
haskell-reactive-banana_0.4.2.0-1.debian.tar.gz 2.5 KiB bd46ea28bc31d67f289441c14a3be2e3562cf0d3fd5c2f994840e0a8df871b84
haskell-reactive-banana_0.4.2.0-1.dsc 2.6 KiB ecf29c2f77d9916d5ff27ee4478e5563be65d800a7dec23d56349fb99c65281f

View changes file

Binary packages built by this source

libghc-reactive-banana-dev: small but solid library for FRP

 This package provides a library for the Haskell programming language. See
 http://www.haskell.org/ for more information on Haskell.
 .
 The current focus of this library is to implement a subset of the semantic
 model for functional reactive programming pioneered by Conal Elliott.
 .
 Moreover, this library can hooked into any existing event-based framework.
 It is especially useful in conjunction with existing GUI frameworks like
 wxHaskell or gtk2hs.
 .
 This also means that your code can be a mix of FRP and imperative parts.
 Bored of programming imperative GUIs? Write some parts with FRP! Don't know
 how to express something with FRP? Switch back to imperative style!
 .
 In the spectrum of possible FRP implementations, this one features simple
 semantics but modest expressivity. Predicting space & time usage should be
 easy.
 .
 Stability forecast: Known inefficiencies that will be addressed. No
 semantic bugs expected. Significant API changes are likely in future
 versions.

libghc-reactive-banana-doc: small but solid library for FRP; documentation

 This package provides a library for the Haskell programming language. See
 http://www.haskell.org/ for more information on Haskell.
 .
 The current focus of this library is to implement a subset of the semantic
 model for functional reactive programming pioneered by Conal Elliott.
 .
 Moreover, this library can hooked into any existing event-based framework.
 It is especially useful in conjunction with existing GUI frameworks like
 wxHaskell or gtk2hs.
 .
 This also means that your code can be a mix of FRP and imperative parts.
 Bored of programming imperative GUIs? Write some parts with FRP! Don't know
 how to express something with FRP? Switch back to imperative style!
 .
 In the spectrum of possible FRP implementations, this one features simple
 semantics but modest expressivity. Predicting space & time usage should be
 easy.
 .
 Stability forecast: Known inefficiencies that will be addressed. No
 semantic bugs expected. Significant API changes are likely in future
 versions.

libghc-reactive-banana-prof: small but solid library for FRP; profiling libraries

 This package provides a library for the Haskell programming language. See
 http://www.haskell.org/ for more information on Haskell.
 .
 The current focus of this library is to implement a subset of the semantic
 model for functional reactive programming pioneered by Conal Elliott.
 .
 Moreover, this library can hooked into any existing event-based framework.
 It is especially useful in conjunction with existing GUI frameworks like
 wxHaskell or gtk2hs.
 .
 This also means that your code can be a mix of FRP and imperative parts.
 Bored of programming imperative GUIs? Write some parts with FRP! Don't know
 how to express something with FRP? Switch back to imperative style!
 .
 In the spectrum of possible FRP implementations, this one features simple
 semantics but modest expressivity. Predicting space & time usage should be
 easy.
 .
 Stability forecast: Known inefficiencies that will be addressed. No
 semantic bugs expected. Significant API changes are likely in future
 versions.