[Haskell-cafe] Yi project proposal for GSOC 2014

[Mateusz Kowalczyk]

On 10/03/14 23:43, John Lato wrote:
> I think this has potential to be a good proposal, although I have a few
> concerns:
> 
> 1.  It's a bifurcated proposal, with two major components.  I think the
> proposal would be stronger if you address more either how adding
> concurrency will help with all those tickets, or other features that should
> be supported in yi but can't with the current design.  You give a few
> examples further down, but at present it reads (to me) as though you want
> to add concurrency just for the sake of it.

Actually, the tickets mentioned are not affected (much) by concurrency
being implemented or not. Here are some things that lack of concurrency
does affect at the moment:

* Can't do periodic events

* Can't wait for a process output in the background (an easy test is to
ask Yi to run a ‘sleep 2000’ system command). This is a big deal for
interacting with things like flyspell or ghc-mod.

* Can't do networking

* Can't do <insert anything that takes time or periodic updates>

When I say it can't do it, I mean ‘can't do it without stopping
everything else including the interface’. This is a big problem for an
editor because it means we can't write many, many of the editor modes
that people pretty much require nowadays: flyspell, flycheck,
compilation, <insert your favourite mode here>. What Yi can do are
‘static’ modes such as dired: they do not require background updates or
anything of the sort so they are fine in a single thread most of the
time. Any longer editor actions effectively lock up the interface for
the user. I'd wager that your own text editor performs some of these
actions that we couldn't feasibly implement in Yi right now.

> 2.  Despite the well-known fact that Concurrency is Hard, in many ways
> Haskell provides better tools to manage concurrency than many other
> languages.  There are so many options, that sometimes people have
> difficulty knowing what to pick.  This work seems to provide an obvious
> benefit to the Haskell community in that others can see what you chose,
> why, and how it worked in practice (including any pitfalls).
> 
> Out of your benefits to the Haskell community, IMHO 2) and 3) are solid but
> 1) is rather general and conceivably would apply to any proposal.  Unless
> you have specific library deliverables in mind, I'd suggest starting with
> your third point.

In hindsight I also think that 1) should be moved down and 2) and 3) up.
I think it was simply the first thing to come to my mind. I mention it
because it may seem surprising to some people that in fact, even if they
are not interested in Yi, they might still benefit from new libraries if
nothing else. I don't have any specific deliverables here so I'll
probably switch the points around as you recommend.

> These aren't really technical concerns, rather they're about the
> language/focus of your proposal.  Although I do think this is an ambitious
> project, the scope as you've defined it might be manageable within a GSOC.
>  That said, I wouldn't be surprised if adding concurrency takes more time
> than you've allocated, or is a source of new bugs that you'll have to fix,
> thereby preventing you from working on the bugs you've already identified.

I also think concurrency might take a rather long time but as I already
am involved with Yi, I do not plan to put it off to the day 1 of coding
period which should give me a good head start. While it's technically
not part of the proposal, I don't really plan on sitting doing nothing
with Yi until the project starts and then be swarmed with work.

I think that the >1 month of the coding period I allocated will be
enough at that point. It is a fair point about any new bugs which is why
I say that I do not guarantee every single bug I mentioned will be
closed but rather serve as a guideline of what I'll work on in the
second part.

> Cheers,
> John L.

-- 
Mateusz K.