New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Question: break out JS lib? #18

Closed
paf31 opened this Issue Dec 11, 2014 · 6 comments

Comments

Projects
None yet
3 participants
@paf31
Contributor

paf31 commented Dec 11, 2014

I have a proposal for this library.

I've been working on https://github.com/paf31/purescript-behaviors, mostly to learn FRP concepts, and I think it fits a different niche to this library - signals seems better suited to things like reactive UIs and games, and behaviors seems better for things like modeling continuous functions and simulations. The key difference seems to be whether signals have to be defined at time zero or not.

Anyway, my main lesson from working on behaviors was that it was a good thing to break out the JavaScript from the FFI imports into an actual library. I think it would be good to see more libraries developed in this way - a JS library inspired by functional concepts, with a thin PureScript wrapper to provide types and standard type class instances.

I also think this would be a great way to get more JS developers on board.

What do you think? Would you accept a PR along these lines?

I also think this would be good in the sense that it would force us to think about the denotation of Signal. Right now, there is quite a lot of usage of the constant function to create signals, and I find it difficult to understand the interface.

@alvinwng

This comment has been minimized.

Show comment
Hide comment
@alvinwng

alvinwng Dec 14, 2014

Wouldn't it be nice to generalize this library to allow for signals without an initial value? Then Signal can be made into a monoid with mempty to be such signal and merge as its binary operation. Perhaps its behavior would then be closer to your behaviors library? I am thinking about implementing this signal without an initial value such that the initial value is null in JS, but not sure if this would be alright in the sense of PureScript.

alvinwng commented Dec 14, 2014

Wouldn't it be nice to generalize this library to allow for signals without an initial value? Then Signal can be made into a monoid with mempty to be such signal and merge as its binary operation. Perhaps its behavior would then be closer to your behaviors library? I am thinking about implementing this signal without an initial value such that the initial value is null in JS, but not sure if this would be alright in the sense of PureScript.

@paf31

This comment has been minimized.

Show comment
Hide comment
@paf31

paf31 Dec 14, 2014

Contributor

I vote 👎 on this.

Signals being defined everywhere is a design choice (matching Elm). This is why I made the distinction between behaviors (defined everywhere) and events (discrete, initially empty) in purescript-behaviors, but it's a different set of design choices with different goals.

I think that for things like signals of DOM elements, the choices made by this library are the most appropriate.

For things like continuous functions and simulations, I think that the approach taken by purescript-behaviors is more appropriate.

Contributor

paf31 commented Dec 14, 2014

I vote 👎 on this.

Signals being defined everywhere is a design choice (matching Elm). This is why I made the distinction between behaviors (defined everywhere) and events (discrete, initially empty) in purescript-behaviors, but it's a different set of design choices with different goals.

I think that for things like signals of DOM elements, the choices made by this library are the most appropriate.

For things like continuous functions and simulations, I think that the approach taken by purescript-behaviors is more appropriate.

@alvinwng

This comment has been minimized.

Show comment
Hide comment
@alvinwng

alvinwng Dec 14, 2014

I think signals being defined all the time is, as you said, a design choice to match Elm, and that's the only reason I can see. In the usual sense of the word "signal", a signal may or may not occur at all. If it has to be there all the time, I think it's better called a status. This library is also used to model keyboard inputs and timers, as seen in Signal.DOM and Signal.Time. But the requirement that a signal has to be there all the time makes the modelling of keypress much like key status, and the modelling of timeout in JS pretty much impossible, as a signal is fired right away at the time of subscription. I would need extra code to check if it's being fired for the first time, which is cumbersome. I do not see much sense in this Elm design and think that allowing signals that may or may not occur at all would give more flexibility to this library.

alvinwng commented Dec 14, 2014

I think signals being defined all the time is, as you said, a design choice to match Elm, and that's the only reason I can see. In the usual sense of the word "signal", a signal may or may not occur at all. If it has to be there all the time, I think it's better called a status. This library is also used to model keyboard inputs and timers, as seen in Signal.DOM and Signal.Time. But the requirement that a signal has to be there all the time makes the modelling of keypress much like key status, and the modelling of timeout in JS pretty much impossible, as a signal is fired right away at the time of subscription. I would need extra code to check if it's being fired for the first time, which is cumbersome. I do not see much sense in this Elm design and think that allowing signals that may or may not occur at all would give more flexibility to this library.

@paf31

This comment has been minimized.

Show comment
Hide comment
@paf31

paf31 Dec 14, 2014

Contributor

I do agree that things like mouse and keyboard Signals are a bit odd. That was part of the inspiration for my behaviors library, but I also don't think that my solution is appropriate for modeling an updatable DOM. You don't want to have to sample a behavior every N milliseconds just to update the DOM, which is the only option right now - you want a push model in this case. But I do think there is a middle ground, by defining types for both signals and non-empty signals. Whether that is something that @bodil wants to explore with this library is not really for me to say, though.

Contributor

paf31 commented Dec 14, 2014

I do agree that things like mouse and keyboard Signals are a bit odd. That was part of the inspiration for my behaviors library, but I also don't think that my solution is appropriate for modeling an updatable DOM. You don't want to have to sample a behavior every N milliseconds just to update the DOM, which is the only option right now - you want a push model in this case. But I do think there is a middle ground, by defining types for both signals and non-empty signals. Whether that is something that @bodil wants to explore with this library is not really for me to say, though.

@bodil

This comment has been minimized.

Show comment
Hide comment
@bodil

bodil Dec 14, 2014

Owner

The only aim of this library is to implement signals in the Elm style. Anything else is out of scope and best done as a separate project. I heard Behaviours is pretty cool. :)

And as to the original point: with inline FFI, I get dead code elimination and no ambiguity about how to load the JS. One of the design goals of this implementation was to be tiny, so the DCE is something I'm very reluctant to give up.

We should also explore the implications of bundling JS files in packages before making this a thing - it makes things potentially tricky for build systems and runtimes. Not saying it's a bad idea in the long term, though, I can see how it could be useful.

Owner

bodil commented Dec 14, 2014

The only aim of this library is to implement signals in the Elm style. Anything else is out of scope and best done as a separate project. I heard Behaviours is pretty cool. :)

And as to the original point: with inline FFI, I get dead code elimination and no ambiguity about how to load the JS. One of the design goals of this implementation was to be tiny, so the DCE is something I'm very reluctant to give up.

We should also explore the implications of bundling JS files in packages before making this a thing - it makes things potentially tricky for build systems and runtimes. Not saying it's a bad idea in the long term, though, I can see how it could be useful.

@paf31

This comment has been minimized.

Show comment
Hide comment
@paf31

paf31 Dec 15, 2014

Contributor

Makes sense, thanks.

Contributor

paf31 commented Dec 15, 2014

Makes sense, thanks.

@paf31 paf31 closed this Dec 15, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment