ivanperez-keera / yampa Goto Github PK

Many functions lack documentation.

One such function is count, which produces a signal carrying an Event with the number of times the input signal was holding an Event.

It would be great if that could be documented ;)

Document the module: FRP.Yampa.Hybrid.

Document the module FRP.Yampa.Core.

Document FRP.Yampa.Conditional.

reactimate seems to have some redundancy in its type requirements, more specifically, the two Bool inputs required for the input and output actions.

Is there a good reason to not introduce some wrapped functions which simplify this? For instance, I wrote a small module, which I've uploaded in this gist (please forgive my naming), which I find I use rather than reactimate directly.

(With regards to issue #15, sReactimate generalises to all monads with no changes, and yampaMain should be is fairly straightforward to adjust for MonadIO actions.)

As a reference see:

https://docs.travis-ci.com/user/languages/haskell/
and
https://github.com/ivanperez-keera/dunai/blob/develop/.travis.yml

That is, use the standard building image for Haskell ("ghc" variable, remove install section, etc.).

Document the module FRP.Yampa.Point2.

Document the module FRP.Yampa.Task.

Please, comment below and list Yampa projects, and also whether they are maintained (you can tag the maintainer by using their github handle, for example, mine is @ivanperez-keera).

Idea: create a Yampa program that generates an HTML file that changes (for instance, a text box that always shows the current mouse coordinate).

Prior knowledge of blaze-html or some other library to generate HTML would be useful.

Document the module FRP.Yampa.Point3.

Document the module FRP.Yampa.Vector2.

Document the module FRP.Yampa.MergeableRecord.

Document the module FRP.Yampa.AffineSpace.

Somewhere during the module restructuring, I left the function count out. This should probably be exported by FRP.Yampa (it actually broke some projects, apparently).

It's currently with the Integration stuff.

Document the module FRP.Yampa.Integration.

Document module FRP.Yampa.Core fully with haddock.

It would be nice to add an SDL2 demo so that people know where to start :)

Yampa defines a Forceable type class that implements one-level-deep NF evaluation. Default implementations are given for tuples and lists.

Instances are also given for Event and other types but, afaict, the main class function force is not used anywhere.

Maybe it should be removed? There's other, more interesting forms of forcing (namely, deepseq).

The module FRP.Yampa re-exports individual functions and types. Maybe it should just re-export all modules.

It would be important to check that the API does not change. I don't know if there is an automatic or systematic way of doing this. Maybe browse with ghci, sort the output, and diff?

A lot of Yampa remains undocumented.

The functions parC and parZ should be pretty easy to document.

https://hackage.haskell.org/package/Yampa-0.10.6.2/docs/FRP-Yampa-Switches.html

Please see http://hydra.cryp.to/build/795273/nixlog/1/raw for a complete build log.

I'm having issues using pSwitchB. I've made a simple program below that demonstrates the issue. When the switch occurs (input value is 3), this goes into an infinite loop, presumably because each time the switch occurs, a new one is immediately triggered. I though using dpSwitchB would solve this problem, but it only delays the issue till the next sample. Am I using (d)pSwitchB incorrectly?

module Main where

import FRP.Yampa

eventAt3 :: SF Integer (Event ())
eventAt3 = arr $ \t -> if t == 3
                        then Event ()
                        else NoEvent

swit :: [SF Integer (Event ())] -> SF Integer [Event ()]
swit actors = pSwitchB
        actors
        (arr (\(_, es) -> () <$ catEvents es))
        (\colSfs _ -> swit colSfs)

main :: IO ()
main = print $ embed (swit [eventAt3]) (0, [(1,Just 1),(1,Just 1),(1,Just 2),(1,Just 3),(1,Just 4)])

Document the module FRP.Yampa.EventS.

A link to the following project should be added as the last item in the list in the section Other examples.

https://github.com/keera-studios/Haskelloids

See http://lambdor.net/?p=397. This is necessary when the output function needs to be run in a GPipe (OpenGL) context, for example.

Document the module FRP.Yampa.Vector3.

Document the module FRP.Yampa.Diagnostics.

This project has never been adapted to be used with stack.

It has over 2K lines. It should be split in conceptual units.

A while back, @lambdor kindly put on his website a list of Yampa diagrams, with sources: http://lambdor.net/?author=1

Over time and after writing several articles, these kinds of diagrams have become pretty useful. However, in order to use them, we need to also be able to credit them properly.

I think it would be great to have a list/table with the images, a link to the svg, and a caption/bibtex entry that credits @lambdor properly.

Henrik Nilsson and Antony Courtney also have some diagrams in dia (what I have been using, mostly), which could also be added.

Document the module FRP.Yampa.Scan.

Document the module: FRP.Yampa.Miscellany.

I find that DatatypeContexts appear several times in this project.
(i.e. Point2/3, Vector2/3 and MergeableRecord)

According to this proposal: https://ghc.haskell.org/trac/haskell-prime/wiki/NoDatatypeContexts
DatatypeContexts is deprecated.
It was widely considered a misfeature, and has been removed from the Haskell language.
Although cabal-install makes Yampa buildable even in the latest GHC(by turning the flag on automatically).

Instead, we should use ExistentialQuantification(or GADTs) to add constraints on constructors.
For typeclass deriving, we could enable the StandaloneDeriving for convenience.

Well, actually I'm not sure if DatatypeContexts was necessary in this case.
I'll apologize if I misunderstood the usage here.

Document the module FRP.Yampa.InternalCore.

Document the module FRP.Yampa.Random.

(via Neil Sculthorpe):

Yampa won't install because of the lack of an Applicative instance for Task. (A consequence of the Applicative/Monad proposal.) This is using the latest Hackage version.

[16 of 16] Compiling FRP.Yampa.Task ( src/FRP/Yampa/Task.hs,
dist/build/FRP/Yampa/Task.o )

src/FRP/Yampa/Task.hs:95:10:
No instance for (Applicative (Task a b))
arising from the superclasses of an instance declaration
In the instance declaration for ‘Monad (Task a b)’
Failed to install Yampa-0.9.6

MergeableRecord is not used by any other module. It's an implementation of update operations on records by using type classes. Given the existing work on extensible records & lenses, plus the fact that it's not used, I think it would be best to remove it.

Note: It's exported, so it makes Yampa not backwards compatible.

I am wondering if it is a better choice for using linear rather than the current vector-about modules.

As can be seen, in the yampa, there are a variety of modules dealing with vectors or vector space. It is obvious that the modules (AffineSpace, VectorSpace, Vector2, Geometry) are not neccesary, for main yampa functions do not closely rely on it.

I have found that the only usage of this and that vector modules is in the Intergration module. If choosing linear as the replacement, the only thing to do is changing the constraints (VectorSpace a s) to the (Additive f, Num a).

Acturely, the similar discussion (http://mailman.cs.yale.edu/pipermail/yampa-users/2012-May/) happened 3 years ago. The main concern for the introduce of a third party vector library is the increase of dependency. Not only in yampa, but in other project the same argument (haskell-game/sdl2#3) existed.

dup = (\a->(a,a)), a trival def imported from Miscellany, is only used once in line 456 in the file InternalCore.hs.
I'm wondering if it's possible to remove the import in line 193 and substitude dup with (\a -> (a, a)) in line 456 which is the only place using dup.

It is found that in the Time module the extensions ({-# LANGUAGE GADTs, Rank2Types, CPP #-}) are not neccesary. And the same thing happened in the Integration module.

I am not certain the pros or cons of adding ample extensions. Maybe being concise is better?

There's a lot of info about Yampa around (papers, haskell's wiki, blogs) but this is not centralised. Since the code is not documented (not using haddock), it's quite daunting to understand the semantics of each function and how to use them.

Document the module FRP.Yampa.VectorSpace.

The function maybeToEvent which is described and implemented in the Event Module https://hackage.haskell.org/package/Yampa-0.10.6.2/docs/FRP-Yampa-Event.html is not exported in the library. Solution: add to export of Yampa.hs.

It would be great to have some trivial examples of good Yampa that can help people get started.

There's a project called Yampa 2048 that uses gloss. Factorizing the code logic out might give a reasonable hello gloss.

Documentation should be added to the main page. There's tons of it, plus games. This project doesn't even have a README.

Document the module FRP.Yampa.Switches.

This one might be hard.

It would be great to have some trivial examples of good Yampa that can help people get started.

The ideal diagrams project would be either a Yampa program that outputs an animation (maybe in SVG?), or one that draws the animation using cairo/gtk.

This is with GHC 8.2.1, if that's significant:

$ cabal get Yampa-0.10.6.1
Unpacking to Yampa-0.10.6.1/
$ cd Yampa-0.10.6.1/
$ cabal configure -fexamples
Resolving dependencies...
Configuring Yampa-0.10.6.1...
$ cabal build
Preprocessing library for Yampa-0.10.6.1..
Building library for Yampa-0.10.6.1..
<build output elided>
Preprocessing executable 'yampa-examples-sdl-bouncingbox' for Yampa-0.10.6.1..
Building executable 'yampa-examples-sdl-bouncingbox' for Yampa-0.10.6.1..
[1 of 1] Compiling Main             ( examples/yampa-game/MainBouncingBox.hs, dist/build/yampa-examples-sdl-bouncingbox/yampa-examples-sdl-bouncingbox-tmp/Main.o )

examples/yampa-game/MainBouncingBox.hs:8:1: error:
    Could not find module ‘YampaSDL’
    Use -v to see a list of the files searched for.
  |
8 | import YampaSDL
  | ^^^^^^^^^^^^^^^

The flags in the cabal file accept a description field that explains what they do.

These could be added and would be shown on the package's hackage page.