[Haskell-cafe] Yi project proposal for GSOC 2014

[Carter Schonwald]

I should point out that the ways Vim and Emacs (and others like Sublime /
Textmate) do those plugins is they often run them in a subprocess.

Now i agree that having in process multi threading would be a good thing, I
merely point out that there are ways to add the plugins you outline that
need not depend on fully resolving the concurrency story.

Yes, not calling a subprocess and stuff will be much better, just pointing
out there are *ungodly* but feasible alternative hacks.

:)
-Carter


On Tue, Mar 11, 2014 at 2:42 AM, Mateusz Kowalczyk
<fuuzetsu at fuuzetsu.co.uk>wrote:

> 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.
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140311/df38a9b7/attachment.html>