<div dir="ltr">On Sat, Nov 16, 2013 at 3:42 PM, Daniel Prager <span dir="ltr"><<a href="mailto:daniel.a.prager@gmail.com" target="_blank">daniel.a.prager@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">



<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div style="font-family:arial,sans-serif;font-size:13px">

<div><div>> Similarly to what Shriram said, I think a big problem with FrTime is that it's monolithic. It could (in my opinion) be greatly <br>

</div></div></div><div><div style="font-size:13px;font-family:arial,sans-serif">> 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 </div>





<div style="font-size:13px;font-family:arial,sans-serif">> modular, easier to understand and maintain, etc.<br></div><div style="font-size:13px;font-family:arial,sans-serif"><br></div>

</div><div style="font-size:13px;font-family:arial,sans-serif">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.</div>





<div style="font-size:13px;font-family:arial,sans-serif"><br></div><div style="font-size:13px;font-family:arial,sans-serif">Would the kind of changes that you've opined make such demonstrations more feasible?</div></div>



</blockquote><div><br></div><div>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.</div>

<div><br></div><div>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.</div>

<div><br></div><div>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.</div>

<div><br></div><div>In brief, yes: I think the sort of redesign I'm imagining would result in a more powerful and flexible system.</div><div><br></div><div>Greg</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">



<div dir="ltr"><div style="font-size:13px;font-family:arial,sans-serif">Dan</div><div class="gmail_extra"><div dir="ltr"></div>
</div></div>
</blockquote></div><br></div></div>