Talk:Grapefruit

Which are the main differences between Grapefruit and wxFruit? -- ARG 14:40, 3 May 2007 (UTC)

Hello ARG,

sorry that I didn’t answer earlier but it was problematic for me to do so.

My following statements about wxFruit are based on the paper “wxFruit: A Practical GUI Toolkit for Functional Reactive Programming” by Bart Robinson. Is there any newer information about wxFruit? Or did wxFruit die after Bart had written his paper?

Now the differences:

Implementation and efficiency

The implementation of Grapefruit differs notably from wxFruit’s implementation. Grapefruits implementation doesn’t use Yampa. It is very similar to FranTk’s “data-driven” approach instead. Internally, a GUI description is an action which builds the GUI and does any necessary event handler registration. The registered event handlers do the necessary updates and notifications of other components autonomously. Grapefruit’s approach is probably much more efficient than wxFruit’s one. I still have to have a closer look at wxFruit’s and Yampa’s source code to give a more detailed comparison.

Signals

Signals are implicit in wxFruit but explicit in Grapefruit. While explicitness of signals makes Grapefruit not as declarative as I would like, it might be necessary for efficiency. Implicit signals may lead to unnecessary updates. Consider the arrows pure id and pure $ \(a,b) -> (b,a) in wxFruit. Both have type Arrow arrow => arrow (a,a) -> arrow (a,a). If only the first component of the input changes, only consumers of one of the output components have to react. In the first case, these are the consumers of the first component, in the second case, these are the consumers of the second component. Since you cannot analyse a function in Haskell, the GUI library cannot know upon GUI construction time which components have to be updated. So it might have to unnecessarily update all components which depend on the output of the pure arrow. Checking for actual changes at runtime might help but I’m currently not sure about the consequences.

Event streams

In wxFruit, event streams are basically just signals with values of a Maybe type. However, this is too broad. Dense event streams are actually forbidden but I cannot see a way to force this restriction via Haskell’s type system. In Grapefruit, event streams are not special signals but different from signals. This seems much more reasonable to me. It is another reason for the expliciteness of signals (and event streams) since this expliciteness enables you to distinguish between signals and event streams via their types.

Graphics and animations

Graphics are currently not supported by Grapefruit but they hopefully will after some months. The same holds for animations.

Dynamic user interfaces

Support for dynamic user interfaces is under development. wxFruit has no support for them and adding this support to wxFruit is difficult.

Event cascades

If an event causes several other events, Grapefruit handles those other events one after another, whereby each handling can cause new events which are handled immediately. wxFruit probably behaves different here and its behavior might be better.

-- Wolfgang Jeltsch 17:07, 11 May 2007 (UTC)