<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br>I would say making ghci a full-blown IDE backend akin lisps slime-swank or clojure nrepl would be the best approach.</div>

</blockquote><div>there's already hdevtools which plays that role - it provides all sorts of information to an IDE, like types, location of declarations, etc.  It's a background process and it's quite responsive (tries to be incremental). I don't know how it is implemented and whether it is a wrapper around GHCi. <br>

<br>But I agree that all IDEs should simply use GHCi as the official IDE backend. Maybe some parts from scion/hdevtools/ghc-mod/etc. could be pulled back into GHCi?<br><br></div><div>Michal<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div dir="ltr"><div><div class="h5"><br><br><br>On Monday, March 10, 2014 8:09:49 AM UTC-7, Mateusz Kowalczyk wrote:</div></div><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">

<div><div class="h5">Greetings,

<br>

<br>GSOC 2014 proposal period opens in ~4 hours and I'm hoping to

<br>participate this year as well. This time around I'd quite like to work

<br>on Yi. As we did last year, I think it's worthwhile to put up the

<br>proposals on café for people to comment on before they are submitted on

Google's site.

<br>

<br>I paste it in full below so that it is easier to respond to parts of it

<br>(although I do ask that you don't quote the whole thing if it's not

<br>necessary). In case any changes happen, the most up-to-date version

<br>should be at <a href="https://gist.github.com/Fuuzetsu/9462709" target="_blank">https://gist.github.com/<u></u>Fuuzetsu/9462709</a>

<br>

<br>Please feel free to nitpick on anything, throw in suggestions and ask

<br>for clarifications. I will give 5 days of discussion period on this

<br>after which point I'll submit it on Google's site. I appreciate all

feedback.

<br>

Thanks!

<br>

<br>

<br>Yi concurrency, usability and hackability

<br>------------------------------<u></u>------------

<br>

* What is the goal of the project you propose to do?

<br>

<br>    There are two main goals of the project: the first is to implement

<br>    concurrency in the Yi text editor. The second aim is to start

bringing Yi into the territory of usable and hackable editors.

<br>

<br>    Dmitry Ivanov who's currently in charge of Yi has agreed to mentor

<br>    this project.

<br>

* In what ways will this project benefit the wider Haskell community?

<br>

<br>    While the project itself isn't one of the core ones (such as GHC,

<br>    Haddock and Cabal), I feel that there are a couple of benefits to the

<br>    community:

<br>

<br>    1. Work on Yi (now and in the future) will undoubtedly spawn new

<br>       Haskell libraries usable in other projects. My personal

<br>       experience with Yi shows that it's actually very comfortable to

<br>       write a generic library which does what we need and then having

<br>       a separate package which uses the library to actually interact

<br>       with Yi.

<br>

<br>    2. Haskellers come closer to escaping the ELisp/vimscript hell. We

<br>       can get a nicer programming environment, made and extensible in

<br>       the language of our choice and get to use all the libraries

that we're used to while we're at it.

<br>

<br>    3. We'll have more Real World™ Haskell applications. On a more

<br>       serious note, it can serve as a good example of how to do

<br>       certain things with Haskell: off the top of my head, it

<br>       demonstrates the use of dyre and gtk2hs in a real-world

<br>       scenario rather than a 5 line example on the Haskell wiki. If

the project is successful, we can add concurrency to this.

<br>

<br>    Other than the Haskell community in general, this project should

<br>    benefit anyone with some interest in text editors. I think it's

<br>    safe to say that happens to be a large majority of Haskellers:

<br>    most of us want nicer integration with Haskell tools and

<br>    libraries[citation needed] and now it'll be possible through

direct, type-checked library access.

<br>

<br>* Can you give some more detailed design of what precisely you intend

<br>  to achieve?

<br>

<br>    The concurrency goal will involve careful study of Yi's inner

<br>    workings in order to try and accommodate concurrency in Yi's

<br>    editor state. There are various ways to do concurrency and the

<br>    first part of the project will concentrate on settling for one. An

<br>    example of two different ways is to extend the existing Yi engine

<br>    with classical tools (MVars, channels) to accommodate for

<br>    concurrency that way. An alternative way would be to modify the

<br>    engine so that concurrency support is natural. Such experiment was

<br>    started [here](<a href="https://github.com/ethercrow/y" target="_blank">https://github.com/<u></u>ethercrow/y</a>) using the sodium

<br>    FRP package which would give us concurrency ‘for free’. The

<br>    experiment is not complete and this is the kind of thing that will

first be explored.

<br>

<br>    Of course once we settle for a method, time will be spent

<br>    implementing it. In the end, this should allow us to do things

<br>    such as fire Yi events periodically or do network transfers

<br>    without having to halt the whole editor. Editors such as emacs

<br>    which are single-threaded effectively hop back-and-forth between

<br>    tasks on a single thread. We aim to provide the ability to simply

<br>    have tasks on different threads which allows us to take advantage

of system resources much better.

<br>

<br>    The second part of the project is to make Yi more usable and

<br>    hackable. Usability here involves fixing bugs apparent to the user

<br>    and hackability involves bugs apparent to developers. Further,

<br>    as part of usability, I plan to implement as many editor modes as

I find time for.

<br>

<br>    Specifically, here are some open bugs that I hope to either fix or

<br>    to make a considerate progress on: #445, #397, #517, #519, #515,

<br>    #516, #513 (concurrency), #512, #507, #504, #502, #501, #499,

<br>    #497, #493, #487, #478, #477, #468, #465, #399, #396, #391, #390,

<br>    #382, #322, #295, #172, #160, #106, #145, #112, #82, #509.

<br>

<br>    All the bug numbers can be viewed on

<br>    [GitHub](<a href="https://github.com/yi-editor/yi/issues/" target="_blank">https://github.com/<u></u>yi-editor/yi/issues/</a>). Please note

<br>    that some of these are documentation bugs: Yi suffers from poor

<br>    documentation and I believe that's what the main problems in

<br>    gaining developers and users has been. When time or area I'm

working on allows, missing documentation will be written.

<br>

<br>    If I find any issue that have been fixed or are no longer

<br>    applicable, the reports will simply be closed. The issues are very

<br>    varied: unicode problems, keymap problems, highlighter problems,

<br>    reloading problems, testing problems, mode problems… There is

<br>    certainly enough work to entertain anyone for a longer amount of

time while making Yi visibly better.

<br>

<br>    The list of issues is simply an indicator of which problems the

<br>    second goal of the project will concentrate on, rather than as a

promise of which bugs are guaranteed to be fixed by the end of it.

<br>

<br>    Alongside this goal, I'll write any modes for Yi as I find time

<br>    for them. The completion of concurrency part of the project allows

<br>    us to write many of the modes frequently requested by people

<br>    wishing to use Yi which are currently impossible/unfeasible to

<br>    write.

<br>

<br>* What deliverables do you think are reasonable targets? Can you

outline an approximate schedule of milestones?

<br>

<br>    The plan is based on the GSoC time line:

<br>    20 April - 19 May – while this is a bonding period, I'm already a

<br>    part of the Yi community and have a fair grasp of it. I'd start to

<br>    look into this project as early as this period (and in fact I plan

<br>    to make steps towards it before this date which means some of the

<br>    outlined issues might get fixed early ;) ).

<br>

<br>    19 May - 23 June – coding period; by this point I expect to have

<br>    decided on which concurrency model we'll use and have a good idea

<br>    of how it'll be implemented. By the end of this period,

<br>    concurrency should either be completed or nearly done, depending

<br>    on any unexpected problems that might come up. The deliverable

would be Yi with (at least some) concurrency support.

<br>

<br>    24 June - 11 August – second part of the coding period; work on

<br>    any of the listed (or unlisted bugs) and finish up concurrency if

<br>    it is still not done. Write extra Yi modes, libraries and

documentation as time allows.

<br>

<br>    11 August - 18 August – post-coding period; write any missing

<br>    documentation, promote any cool new stuff we wrote ;) While I can

<br>    not think of a specific deliverable, many bugs should now be

fixed, Yi should have a lot more documentation, tests and modes.

<br>

<br>    As a final note regarding the time line, it is not strictly

<br>    necessary that the project implements concurrency first: while

<br>    some bugs might need such support, many simply do not. If it's

<br>    convenient to fix something that I had originally planned to for

the second part of the project, I'll do so.

<br>

<br>* What relevant experience do you have? e.g. Have you coded anything

in Haskell? Have you contributed to any other open source software?

Been studying advanced courses in a related topic?

<br>

Second year CS student. I program on regular basis using Haskell.

<br>    I contribute to a bunch of FOSS projects as it seems necessary

(see [my GitHub](<a href="https://github.com/Fuuzetsu)" target="_blank">https://github.com/Fuuzetsu)</a>).

<br>    I have successfully completed GSOC in 2013 which involved working

<br>    on Haddock. To this day I help out with Haddock which often

involves looking at the large GHC code base.

<br>

<br>* In what ways do you envisage interacting with the wider Haskell

<br>  community during your project? e.g. How would you seek help on

<br>  something your mentor wasn't able to deal with? How will you get

others interested in what you are doing?

<br>

<br>    I have a [blog](<a href="http://fuuzetsu.co.uk/blog" target="_blank">http://fuuzetsu.co.uk/<u></u>blog</a>) which gets propagated

<br>    onto Haskell Planet. I'm active on IRC and many Haskell-related

<br>    mailing lists. IRC, mailing lists and any relevant literature is

<br>    where I'd seek help were I to get stuck on something my mentor

<br>    can't help me with. I find that news about Yi are very popular and

<br>    get propagated by the community itself very easily so I doubt

there will be any problem getting people interested.

<br>

<br>    I'm very easily reachable over e-mail and IRC and all the

development is done in public.

<br>

<br>* Why do you think you would be the best person to tackle this

<br>  project?

<br>

<br>    I've been interested in Yi for a couple of months and have already

<br>    wrote some commits, closed quite a few issues and filed even more

<br>    issues on my own. I have access to the Yi repository and

<br>    I help anyone looking to get started with Yi. I have about 2 years of

<br>    Haskell experience and had my fair share of staring at library

<br>    code.

<br>

<br>    As mentioned before, I'm active as a member of the community and

help out with one of the core Haskell projects (Haddock).

<br>

<br>

<br>-- 

<br>Mateusz K.

<br>______________________________<u></u>_________________

<br>Haskell-Cafe mailing list

<br></div></div><a>Haskel...@haskell.org</a>

<br><a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/<u></u>mailman/listinfo/haskell-cafe</a>

<br></blockquote></div><br>_______________________________________________<br>

Haskell-Cafe mailing list<br>

<a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>

<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>

<br></blockquote></div><br><br clear="all"><br>-- <br>Michal Antkiewicz, M.Sc., Ph.D<br>Research Engineer<br>Network for the Engineering of Complex Software-Intensive Systems (NECSIS)<br><br>University of Waterloo<br><a href="http://gsd.uwaterloo.ca/mantkiew" target="_blank">http://gsd.uwaterloo.ca/mantkiew</a><br>

<a href="mailto:mantkiew@gsd.uwaterloo.ca" target="_blank">mantkiew@gsd.uwaterloo.ca</a>

</div></div>