[Haskell-cafe] Number of widgets extant and displayed varying over time? (FRP, reactive-banana)
jeffbrown.the at gmail.com
Wed Jan 14 07:33:01 UTC 2015
Reactive Banana's front page on Hackage  indicates that
Reactive.Banana.Switch offers "no garbage collection for events that are
created dynamically". Does that mean one has to collect the garbage
oneself, or does it mean that garbage cannot be collected at all?
My eventual goal is to write a mindmap editor, ala Freeplane. There might
never be more than fifty or so frames of text on display at any one time,
but in a single session I can easily imagine drawing hundreds of thousands
of them. (For that estimate I am assuming a single line of text in the
model would require a new frame each time it is redisplayed; if instead a
frame could persist invisibly and be redrawn later, most sessions would, I
imagine, involve fewer than five thousand frames -- but even then it's not
obvious to me that I could forego garbage collection.)
On Tue, Jan 13, 2015 at 11:04 PM, Heinrich Apfelmus <
apfelmus at quantentunnel.de> wrote:
> Jeffrey Brown wrote:
>> Dear list,
>> I want to write an application in which the set of widgets in existence,
>> and the subset of them that is displayed, depends on user input. I am
>> reactive-banana. So far the simplest spec I have imagined for it is this:
>> Initially there is just a text entry box and an empty (hence
>> collection of labels.
>> The user can do two things: enter the word "add", or enter an integer.
>> Entering the word "add" causes a label to be added to the collection,
>> but not displayed. The labels require no text content.
>> Entering an integer N causes the first N labels to be displayed
>> onscreen. The text entry box remains visible.
>> I am totally baffled. In particular, the Behavior paradigm, though it is
>> elegant and beautiful whenever I study it, I have no idea how to apply.
> This looks like you need "dynamic event switching", i.e. the module
> `Reactive.Banana.Switch`. It's very cool, but may be more difficult to
> understand than the standard combinators, mainly because of the additional
> type parameters.
> To see how it works, have a look at the `BarTab.hs` example. It implements
> a program that is very similar to what you describe here.
> Best regards,
> Heinrich Apfelmus
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-Cafe