Screw laziness (w.r.t. Fran semantics)

Reactive is getting more mature, but still does not support “feedback” behaviors (a bug), and still does not support true first-class Behaviors (an essential limitation); meaning you cannot efficiently put a Behavior in a data structure and save it for later use. By observing the reactive mailing list, this limitation is proving unimportant; still plenty of things are possible. But I am a stubborn, hubristic person, and I simply insist on Fran semantics (Behavior & Future) with first class Behaviors.

I have tried and I have tried, and I am quite convinced that the Fran semantics are not implementable lazily and efficiently in Haskell. I think I have come up with a garbage collector extension that would allow it, but I’m not going to pursue it. Knowing that such an extension exists is important to me, however, as I see hardware such as The Reduceron playing a big role in the future. The IO monad is not going to fly in a reduceronian world.

My impatience for a functional reactive game and UI library is growing. I could have made one in Fregl, but I became convinced that Fregl was too inefficient, and that I required weak-reference-free laziness to make it efficient. In retrospect, however, Fregl was inefficient for many more reasons than simply its eagerness. I am thus throwing aside my laziness requirement, and am now setting out to make a very efficient eager FRP library with Fran semantics.

Perl hackers know the three virtues: laziness, impatience, and hubris. I find it amusing that the one I’m having to throw away in a lazy language is laziness itself.

5 thoughts on “Screw laziness (w.r.t. Fran semantics)

  1. Hi Luke,

    I don’t know what the difference is that you’re after between Fran and Reactive? Is it that you want to use behaviors and futures instead of behaviors and events? If so, you certainly can do so with Reactive, just by importing FRP.Reactive.Future.

    I’m fairly sure you know, but for others: Fran’s original “Event” type == Reactive’s “Future” (both are single-occurrence). I soon changed Fran’s to multi-occurrence, for a higher-level programming style, and kept this style in Reactive.

    I also don’t know what you mean about wanting to “efficiently put a Behavior in a data structure and save it for later use.” Do you mean that you’ll create a space-time leak, due to having to play catch-up later? Fran had this problem also, as does the Haskell list type and probably every other traversable functional data type. By the way, I am pursuing a simple alternative programming model that should eliminate that problem, which I do consider very important.

    I’m glad you’re not settling for anything less that a elegant, powerful, and efficient FRP foundation.

  2. Do you mean that you’ll create a space-time leak, due to having to play catch-up later?

    Yes. I am most interested in conceptual elegance. That is, I don’t mind doing evilness in the library if it means I can think of a Behavior as a function of time. You don’t have to “traverse” time functions. Time functions don’t leak if you reference them with certain patterns. It’s about freeing myself from the operational burden.

    And I like Future mostly because I don’t like Event. “until” is easier for me to think about than “switcher”.

    This is more of a semantic problem, but Event isn’t really a list. It’s a set of discrete occurrences, but a list is wrong. There is no list for “the event that occurs every second (with some origin)”, since that event has no least occurrence. I’ve been thinking instead that an Event is a set of occurrences such that for each time t, there is a least occurrence not before t (if there is any occurrence after t).

    But I digress. What I’m after is being able to use behaviors however I please without worrying about space leaks due to an implementation detail. This is not possible, of course, but I want to get as close as I can. Reactive is pretty — really far off from this goal.

  3. Thanks, Luke. I think I get your dissatisfaction much more clearly now. Thanks for clarifying.

    About “Time functions don’t leak if you reference them with certain patterns”, I think some do, such as (infiniteList !!). Of course, that example uses discrete “time”, but continuous time could be even worse. And the leak is in all use patterns, in addition to certain ones.

    However, this simple list example happens to create a leak, given the current state of Haskell implementations. I suspect that another implementation could avoid the leak with lists and with behaviors.

  4. I agree about Event not being a list. It could perhaps be a set or bidirectional stream. But even those representations are just representations, not the essence.

  5. Ah, that comment, “time functions don’t leak if you reference them with certain patterns”, was intended as a nonsensical juxtaposition. Functions don’t leak, implementations do.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s