sodiumfrp / purescript-sodium Goto Github PK

See http://sodium.nz/t/purescript-implementation/313/13?u=dakom

Should we organize the modules differently? Maybe re-export everything in a top-level SodiumFRP ?

Personally I don't mind the current setup, but it does lead to multiple imports that could be avoided...

Tbh I'm not entirely sure how Github permissions work... I thought everyone in the SodiumFRP organization was automatically added?

But anyway - now that I realized it, @clinuxrulz, welcome :)

Should follow just like the Cell tests, but we need to define an Eq that works through Aff, since the only way of getting a value out of Stream is via listen

Stream

• holdLazy
• collectLazy
• accumLazy

(Cell, Constructor, etc.?)

See http://sodium.nz/t/passing-stream-to-cell-constructor/342

I'm wondering if it would feel a little better to have the sodium objects come first, and have data / callbacks last.

See for example hold, accum, and snapshot.

Note that the current approach of placing the sodium objects last, more closely follows the Haskell implementation.... and either approach can be made to work by using flip or whatever... but if we follow the idea of "most to least general" I'm not sure if the current approach is the best fit...

thoughts?

Currently, functions like snapshot allow passing in any type of Cell (i.e. CellLoop, CellSink, ...)

However, they must all be the same type right now. Need to change the signatures so that each kind gets its own type variable (e.g. SodiumCell celA, SodiumCell celB)

This isn't a showstopper since one can always use toCell to convert it

I'd recommend removing the Monad instance for Cell and just go up to Applicative instead.

If a newbie come along and used the monadic interface heavily (E.g. do-notation), then he/she could run into performance problems as almost all their sodium objects would be connected with switchC, and each time the cell changes within a switchC there is a rank re-sort happening.

SodiumFRP/sodium-typescript#87

Depends on purescript-contrib/purescript-quickcheck-laws#43

execute :: Stream (Effect a) -> Stream a

This one is important for a FRP library in a pure functional programming language. You will not see this one in other languages like Typescript or Java, because we can just do side effects in map. It can be implemented via Typescript's Stream map under the hood.

It is one of the functions listed in the denotational semantics, promise I did not just make it up. 😉

Started but needs continuation and more thought... might be that the entire API needs to be run via Effects since really there is mutation happening on the JS side, even if just local state within the classes

Most functions don't really care whether they are getting a Stream, StreamSink, or StreamLoop (for example)... so it should accept any of them

Probably it can be made as simply as accepting SodiumStream/SodiumCell instead of specific Stream/Cell

Some functions do care about this distinction, of course - for example Functor and Send implementations

• updates
• value
• defer
• split

Primitive Functions

• map
• filter
• mapTo
• orElse
• merge
• gate
• snapshot (0-6)
• hold
• collect
• accum
• once
• send (StreamSink only)
• loop (StreamLoop only)

Constructors

• Stream
• StreamSink
• StreamLoop

Typeclases

• Listenable
• Sendable

Categories

• Functor
• Semigroup
• Monoid

Transactions should be their own wrapper, around Effect.

Tentative: newtype InTransaction t = InT (Effect t)

Functions

• map
• sample
• lift (0-6)
• switchC
• switchS
• send (CellSink only)
• loop (CellLoop only)

Constructors

• Cell
• CellSink
• CellLoop

Typeclases

• Listenable
• Sendable

Categories

• Functor
• Apply
• Applicative
• Monad