On Sat, Nov 16, 2013 at 3:42 PM, Daniel Prager <daniel.a.pra...@gmail.com>wrote:
> > Similarly to what Shriram said, I think a big problem with FrTime is > that it's monolithic. It could (in my opinion) be greatly > > improved if the core update model were decoupled from any language > extensions, global state, or threads, i.e., made into > something that > could be independently instantiated, tested, and combined with other > libraries. This would make it more > > modular, easier to understand and maintain, etc. > > As a prospective adopter of FRP, at a high level what I'd really like to > see is clearly explained examples of its practicality -- nay, superiority > -- in one or more of the sweet-spot application areas: e.g. GUIs, > simulations, games. > > Would the kind of changes that you've opined make such demonstrations more > feasible? > FrTime started with the question of what would happen if you took an existing language (Racket) and added implicit dataflow evaluation to it. The vision was to make dataflow evaluation "make sense" for as much of Racket as possible, and to avoid adding extraneous concepts. In the resulting language, a lot happens implicitly, and the programmer has relatively little control over the reactive evaluation. Writing non-trivial applications typically requires a fair amount of control, so FrTime is often not suitable. What I was trying to suggest above is approaching the problem from a different direction: i.e., start by considering higher-order reactive evaluation in its essence, then investigate how to build a language around it. For example, the Reactive Extensions (Rx) library for .NET is a good example of a language-independent distillation of higher-order reactivity. I could imagine something like it serving as the basis for a family of reactive languages. With a cleanly factored core, it should be easier to experiment with higher-level features that make a system better suited for real-world applications. An example of such a feature is the work on "reactive lenses" to support bidirectional dataflow propagation. This overcomes a major limitation of traditional dataflow for modeling graphical user interfaces. In brief, yes: I think the sort of redesign I'm imagining would result in a more powerful and flexible system. Greg Dan >
____________________ Racket Users list: http://lists.racket-lang.org/users
