wires's Introduction

Wires

This is a functional reactive programming library for interactive applications with the following features:

heavy focus on real-time applications like games and simulations,
very small core abstraction,
efficient in both time and space.

Until a proper tutorial has been written, please check out the examples directory. If you have questions, join #haskell-game on irc.freenode.net. If you would like to report a bug or request a feature, please file an issue.

Module overview

The library is split into two roles: applications and controllers. An application developer models interactions and implements reactive systems, i.e. the application logic. A controller developer implements the glue between the application and the real world, i.e. how events and time-varying values map to actual things on the screen or in the network. The module structure reflects that distinction:

Control.Wire: Application language (basically core + utils)
Control.Wire.Controller: Controller language
Control.Wire.Core: Core application language
Control.Wire.Internal: You should never need this module
Control.Wire.Utils: Extra application utilities

Modules not listed here are highly experimental and should not be used.

If you are asking yourself whether you are an application or a controller developer: at this early stage of development you are probably both, which means that you will write the application as well as connect its inputs and outputs to the real world.

wires's People

Contributors

Stargazers

Watchers

wires's Issues

Space leak when using hold function

When I input mempty as a signal into hold function, space leak occurs.
You can check the problem with the following code.

{-# LANGUAGE Arrows #-}
module Main where

import Control.Arrow
import Control.Wire
import Control.Wire.Controller

main = control $ proc _ -> do
  _ <- hold () -< mempty
  returnA -< never

Undocumented instance semantics

While the non-typeclass-implied methods are somewhat explained, the semantics of typeclass-implied methods are far less obvious (event to someone familiar with the type classes themselves!) and require reading and understanding source code, as well as a certain freedom of philosophizing..

Gracefully handling exceptions in arbitrary subnetworks

Say, we have a certain network subpart that can potentially throw pure exceptions, and we would like to handle them gracefully -- within the FRP framework itself (perhaps by transforming to Events?).

What approach is advocated by Wires, in such situations?

Recommend Projects

esoeylemez / wires Goto Github PK

wires's Introduction

Wires

Module overview

wires's People

Contributors

Stargazers

Watchers

Forkers

wires's Issues

Space leak when using hold function

Undocumented instance semantics

Gracefully handling exceptions in arbitrary subnetworks

Recommend Projects

React

Vue.js

Typescript

TensorFlow

Django

Laravel

D3

Recommend Topics

javascript

web

server

Machine learning

Visualization

Game

Recommend Org

Facebook

Microsoft

Google

Alibaba

D3

Tencent