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.