search

reflex-frp / reflex-frp.org

reflex-frp.org website
http://reflex-frp.org/
28 stars 12 forks source link

monadic computations in Reflex #5

Open mango314 opened 7 years ago

mango314 commented 7 years ago

comparison to Elm architecture

there are a few other FRP around. in particular I had a lot of confusion moving from Elm to Reflex. One difference, possibly is that Reflex, being written in Haskell is monadic. The web page is a side effect of other computations. Although Elm compiler is written in Haskell, Elm is it's own separate language and an architectures. All the HTML , SVG, CSS and other DOM elements have been turned into functions that fit into " the Elm architecture". These are not side effects there are no monads.

Finally while all elements are instances of el or elAttr in Reflex, there's some distinction between dynamic and static elements, elements with attributes and elements without. I found it easier to just use element and lenses and define my own methods.

There's also confusion with ghcjs which is almost completely separate.

From the teaching point of view, it will be helpful to review monads and the Haskell arrows as they play out specifically in Reflex. These are just my thoughts and I'm writing about it on my own GitHub.

AphonicChaos commented 7 years ago

Hi. I'm a nobody, so it could very well be the case that I either don't know what I'm talking about, or my thoughts don't matter in the grand scheme of things. As such, take what follows with a grain of salt sifted by a developer whose genuinely interested in seeing ReflexFRP's documentation improve.

While I'm sure a comparison to Elm would be useful, I wonder how much would have to go into such a comparison to make it useful. Not only are the languages significantly different with respect to the expressiveness of the available abstractions, but they are even modeled on different forms of FRP (signals vs behaviors and events). Indeed, recent versions of Elm aren't even based on FRP anymore.

Given that Elm has never had monads, I feel like the exposition required to sufficiently introduce them might generate enough content to be considered its own documentation. Furthermore, GHCJS's FFI is much lower-level than Elm's concept of Ports (or whatever they are using now for talking to native JavaScript libraries).

To be clear, I think such a comparison would be useful, both to those seeking the greater power that Haskell provides, or those wishing to avoid the complexity introduced by a more powerful type system and (robust?) FRP implementation. I suppose what I'm most curious about is what is the minimum amount of work that needs to be done to make such a comparison useful? Can it be broken down such that a naive comparison could be written to offer users a quick glimpse, and then built upon to be used as a migration guide of sorts? Is such a comparison better done in a project meant to explicitly showcase the difference between different platforms (something like TodoMVC or FRP Zoo, but with more commentary, perhaps)?

mango314 commented 7 years ago

@aspidites Elm's compiler is written in Haskell which uses monads extensively, but we never write or deal with ourselves. Elm was FRP and with subscriptions, it now uses a slightly different organizing principle for user input.

Is the comparison to Elm necessary? No.

Reflex extensively uses monads and the programmer must be comfortable with them. A newcomer probably doesn't know what is

and the new programmer probably doesn't care. If I were just interested in reading a website, I would not use reflex with it's limited documentation and confusing types. It is one of the least user-friendly libraries I have encountered.

Haskell's type system is pretty useless right now because I can't even build Hello World. and none of the types make sense to me. I would do very well to give up and try another library.

Reflex as a platform is logically compete, but not very user friendly. My strategy will be to use wrappers around the basic element function expressing the features I commonly use.

These comparisons may have to run very deep, because Haskell is a deep language. There's monadWidget and domBuilder and Element and Dynamic and on and on... I don't think anyone knows how much of these are essential. Much of this is about my own unique way of learning things.

I first learned Elm and then reflex. So now I'm comparing the two. I am not a computer scientist. When I say FRP it doesn't really mean anything

This looks good enough. I think that guy works much harder on the documentation then we do . As for signals, I found this thread [1] :

Yes there is a intentional design choice in Elm to not include monadic bind for signals. Having it would allow people to have functions which dynamically create signals. (Of course it is always possible to write such functions, but without bind you cannot do anything with their values).

Allowing people to dynamically create signals has two problems. First, it breaks referential transparency because you could theoretically create a stateful signal which depends on all previous mouse positions. If that signal only started reading mouse positions when it was dynamically created, then you could have two identical expressions which return different results (because of being evaluated at different times).

Ryan seems to have fewer opinions about stuff like this, and I can put in my own. Choices like these will have profound influences on how I build websites, but in the end I do whatever it takes to build website...

mango314 commented 7 years ago

@aspidites there's nothing stopping you from creating your own TodoMVC-type example and supplying your own commentaries. I am sure your pull request will be accepted here!

I had to look these up. Half the internet is just clicking a button and something happens on the page.