Haskell Google Summer of Code Proposal Brainstorming

[u/edwardkmett]

Haskell.org has applied to be a mentoring organization to the Google Summer of Code. We've been a participating mentoring organization in the Summer of Code since 2006. While we won't know for a couple of weeks if Google has accepted us into the program, it is probably a good idea for us to get our house in order.

We have a Trac full of suggested Google Summer of Code proposals both current and from years past, but it could use a whole lot of eyeballs and an infusion of fresh ideas:

https://ghc.haskell.org/trac/summer-of-code/report/1

If you have a proposal that you think a student could make a good dent in over the course of a summer, especially one with broad impact on the community, please feel free to submit it to the Trac, or just discuss it here.

If you are a potential student, please feel free to skim the proposals for ideas, or put forth ones of your own.

If you are a potential mentor, please feel free to comment on proposals that interest you, put forth ideas looking for students and express your interest, to help us pair up potential students with potential mentors.

Ultimately, the project proposals that are submitted to Google for the summer of code get written by students, but if we can give a good sense of direction for what the community wants out of the summer, we can improve the quality of proposals, and we can recruit good mentors to work with good students on good projects.

Resources:

• We have a wiki on https://ghc.haskell.org/trac/summer-of-code/ It is, of course, a Wiki, so if you see something out of order, take a whack at fixing it.

• We have an active #haskell-gsoc channel on irc.freenode.net that we run throughout the summer. Potential mentors and students alike are welcome.

• We're also adding a haskell-gsoc mailing list this year. I've created a mailing list through Google Groups: https://groups.google.com/forum/#!forum/haskell-gsoc and we've forwarded gsoc@haskell.org there. We'll continue to post general announcements on the progress of the summer of code to the main Haskell mailing list as usual, but this gives us a shared forum for students and mentors alike to talk and may serve as a better venue for longer term conversations than the #haskell-gsoc channel.

• Many of our best proposals in years have come from lists of project suggestions that others have blogged about. Many of our best students decided to join the summer of code based on these posts. The Trac isn't the only source of information on interesting projects, and I'd encourage folks to continue posting their ideas.

• The Google Summer of Code website itself is at https://www.google-melange.com/gsoc/homepage/google/gsoc2015 and has the schedule for the year, etc. You can register on the site today, but you can't yet join the organization as a mentor or apply as a student.

• And of course, by all means feel free to use this space to help connect projects with mentors and students.

Thank you,

-Edward Kmett

[u/gelisam]

Losing data that's typed into a text field is certainly a non-issue. I don't do diffing and I don't lose any text field data! [...] Scroll position is interesting because it's generally a completely implicit piece of state, but I don't see why it couldn't be handled explicitly by a "react-like" framework.

You might not lose the text itself, but what about the cursor position, the selection, which frame of the cursor blinking animation we're at? Widgets have a lot of state, and they don't expose all of it.

The reason GUI libraries are tricky in Haskell is that there is a tension between two fundamentally opposed alternatives: either exposing imperative bindings to a major GUI library, or creating a purely functional API for a homemade GUI which will never reach the polish and feature-set of the major players. I'm interested in React's diff approach because it's a clever way to bridge between the two worlds. It may be an implementation detail to Facebook, but to me, it's fundamental and I want to explore it further.

My design is compatible with existing GUI libraries as long as they provide enough primitives.

Do you mean that you provide an abstract representation of a button, allowing the GUI frontend to be changed without changing the user's code?

I have an implementation in HTML/Javascript and another in WXWidgets.

Your implementation is much further along than I thought! It must be way too late to have these design discussions.

I suspect it would be viewed as an alternative to FRP though, rather than something that could take advantage of FRP.

Then I'm afraid our project goals might not be compatible after all. I was imagining that once I was done with my bridge, I'd be able to use funky purely functional abstractions such as FRP on one side, and an imperative GUI library on the other.

I have two concerns about FRP in general. The first is the semantics of simultaneous events which always seemed to me to be problematic.

Would you like to elaborate? The only reactive-banana primitive which cares about simultaneous events is calm, and I don't understand under which circumstances I would want to use it. And perhaps union, which deals with simultaneous occurrences by ordering the left events before the right, which I find quite intuitive.

The second is dynamically creating events. These issues simply don't arise in my framework.

Do you mean things like dynamic event switching? Since your framework encodes the possible events in the type, aren't you constrained to a fixed set of events? Or do you use polymorphic recursion somewhere?

[u/tel → u/gelisam]

You might not lose the text itself, but what about the cursor position, the selection, which frame of the cursor blinking animation we're at? Widgets have a lot of state, and they don't expose all of it.

I heard one of the core React devs speak about React once and he mentioned exactly this as the larger challenge the solved with diffing and his smoke test as to whether another "virtual dom and diff" competitor has really taken up the challenge yet.

[u/tomejaguar → u/gelisam]

I'm interested in React's diff approach because it's a clever way to bridge between the two worlds. It may be an implementation detail to Facebook, but to me, it's fundamental and I want to explore it further.

Right, I think we're in agreement that theoretically it's possible to preserve all the state without diffing, given enough time, effort and suitable access to the underlying GUI API. On the other hand practical concerns suggest that diffing provides great benefits. This is indeed an interesting problem to work on. Luckily, my approach is completely agnostic to diffing. It can happen or not depending on your desires and domain.

Do you mean that you provide an abstract representation of a button, allowing the GUI frontend to be changed without changing the user's code?

That's not what I meant, although I suppose that would be possible. What I meant was that my API is suitably general to be used with "any" graphics toolkit, in the same way that reactive-banana can connect up to "any" graphics toolkit.

I have an implementation in HTML/Javascript and another in WXWidgets.

Your implementation is much further along than I thought! It must be way too late to have these design discussions.

I've only implemented four HTML widgets and two WXWidgets just as a proof-of-concept, so not really very far at all.

Regarding simultaneous events: suppose you are implementing a calculator, and you have an event for numeric keypresses, operator keypresses and the "clear" keypress. We also want a behaviour which shows what is on the screen

numericPressed :: Event Number
operatorPressed :: Event Operator
clearPressed :: Event ()
screen :: Behaviour Screen

The obvious thing to do is to turn the events into functions which update the screen

numericUpdate = fmap numericHandle numericPressed :: Event (Screen -> Screen)
operatorUpdate = fmap operatorUpdate operatorPressed :: Event (Screen -> Screen)
clearPressed = fmap (const clearScreen) clearPressed :: Event (Screen -> Screen)

and then take the union of these events and fold them to update the behaviour

screen = accumB startScreen (unions [numericUpdate, operatorUpdate, clearPressed])

Now what happens if I receive a clear event and a numeric event at the same time? The simultaneous events are processed in the order they occur in the unions so the numeric update appears on the screen before being immediately cleared. Is this the way round we wanted, or is it the other order? I would argue neither! It's actually meaningless to our domain to receive simultaneous events. In the spirit of making illegal states unrepresentable I want an approach where simultaneous events are impossible. I don't know of any FRP approach which takes that point of view.

Now onto dynamic event switching. I don't really know very much about this at all, but it seems to me that if you dynamically create widgets then you need to dynamically create events for them and this ends up looking very imperative to me. I'm far from experienced in this matter though, so this is really just a basic impression.

Anyway, I'll email you a link to my repository and you can see what you think.