[Haskell-cafe] Yi project proposal for GSOC 2014

Mon Mar 10 16:22:16 UTC 2014

>
> I would say making ghci a full-blown IDE backend akin lisps slime-swank or
> clojure nrepl would be the best approach.
>
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.

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?

Michal

>
>
>
> On Monday, March 10, 2014 8:09:49 AM UTC-7, Mateusz Kowalczyk wrote:
>
>> Greetings,
>>
>> GSOC 2014 proposal period opens in ~4 hours and I'm hoping to
>> participate this year as well. This time around I'd quite like to work
>> on Yi. As we did last year, I think it's worthwhile to put up the
>> proposals on café for people to comment on before they are submitted on
>> Google's site.
>>
>> I paste it in full below so that it is easier to respond to parts of it
>> (although I do ask that you don't quote the whole thing if it's not
>> necessary). In case any changes happen, the most up-to-date version
>> should be at https://gist.github.com/Fuuzetsu/9462709
>>
>> Please feel free to nitpick on anything, throw in suggestions and ask
>> for clarifications. I will give 5 days of discussion period on this
>> after which point I'll submit it on Google's site. I appreciate all
>> feedback.
>>
>> Thanks!
>>
>>
>> Yi concurrency, usability and hackability
>> ------------------------------------------
>>
>> * What is the goal of the project you propose to do?
>>
>>     There are two main goals of the project: the first is to implement
>>     concurrency in the Yi text editor. The second aim is to start
>>     bringing Yi into the territory of usable and hackable editors.
>>
>>     Dmitry Ivanov who's currently in charge of Yi has agreed to mentor
>>     this project.
>>
>> * In what ways will this project benefit the wider Haskell community?
>>
>>     While the project itself isn't one of the core ones (such as GHC,
>>     Haddock and Cabal), I feel that there are a couple of benefits to the
>>     community:
>>
>>     1. Work on Yi (now and in the future) will undoubtedly spawn new
>>        Haskell libraries usable in other projects. My personal
>>        experience with Yi shows that it's actually very comfortable to
>>        write a generic library which does what we need and then having
>>        a separate package which uses the library to actually interact
>>        with Yi.
>>
>>     2. Haskellers come closer to escaping the ELisp/vimscript hell. We
>>        can get a nicer programming environment, made and extensible in
>>        the language of our choice and get to use all the libraries
>>        that we're used to while we're at it.
>>
>>     3. We'll have more Real World™ Haskell applications. On a more
>>        serious note, it can serve as a good example of how to do
>>        certain things with Haskell: off the top of my head, it
>>        demonstrates the use of dyre and gtk2hs in a real-world
>>        scenario rather than a 5 line example on the Haskell wiki. If
>>        the project is successful, we can add concurrency to this.
>>
>>     Other than the Haskell community in general, this project should
>>     benefit anyone with some interest in text editors. I think it's
>>     safe to say that happens to be a large majority of Haskellers:
>>     most of us want nicer integration with Haskell tools and
>>     libraries[citation needed] and now it'll be possible through
>>     direct, type-checked library access.
>>
>> * Can you give some more detailed design of what precisely you intend
>>   to achieve?
>>
>>     The concurrency goal will involve careful study of Yi's inner
>>     workings in order to try and accommodate concurrency in Yi's
>>     editor state. There are various ways to do concurrency and the
>>     first part of the project will concentrate on settling for one. An
>>     example of two different ways is to extend the existing Yi engine
>>     with classical tools (MVars, channels) to accommodate for
>>     concurrency that way. An alternative way would be to modify the
>>     engine so that concurrency support is natural. Such experiment was
>>     started [here](https://github.com/ethercrow/y) using the sodium
>>     FRP package which would give us concurrency ‘for free’. The
>>     experiment is not complete and this is the kind of thing that will
>>     first be explored.
>>
>>     Of course once we settle for a method, time will be spent
>>     implementing it. In the end, this should allow us to do things
>>     such as fire Yi events periodically or do network transfers
>>     without having to halt the whole editor. Editors such as emacs
>>     which are single-threaded effectively hop back-and-forth between
>>     tasks on a single thread. We aim to provide the ability to simply
>>     have tasks on different threads which allows us to take advantage
>>     of system resources much better.
>>
>>     The second part of the project is to make Yi more usable and
>>     hackable. Usability here involves fixing bugs apparent to the user
>>     and hackability involves bugs apparent to developers. Further,
>>     as part of usability, I plan to implement as many editor modes as
>>     I find time for.
>>
>>     Specifically, here are some open bugs that I hope to either fix or
>>     to make a considerate progress on: #445, #397, #517, #519, #515,
>>     #516, #513 (concurrency), #512, #507, #504, #502, #501, #499,
>>     #497, #493, #487, #478, #477, #468, #465, #399, #396, #391, #390,
>>     #382, #322, #295, #172, #160, #106, #145, #112, #82, #509.
>>
>>     All the bug numbers can be viewed on
>>     [GitHub](https://github.com/yi-editor/yi/issues/). Please note
>>     that some of these are documentation bugs: Yi suffers from poor
>>     documentation and I believe that's what the main problems in
>>     gaining developers and users has been. When time or area I'm
>>     working on allows, missing documentation will be written.
>>
>>     If I find any issue that have been fixed or are no longer
>>     applicable, the reports will simply be closed. The issues are very
>>     varied: unicode problems, keymap problems, highlighter problems,
>>     reloading problems, testing problems, mode problems… There is
>>     certainly enough work to entertain anyone for a longer amount of
>>     time while making Yi visibly better.
>>
>>     The list of issues is simply an indicator of which problems the
>>     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.
>>
>>     Alongside this goal, I'll write any modes for Yi as I find time
>>     for them. The completion of concurrency part of the project allows
>>     us to write many of the modes frequently requested by people
>>     wishing to use Yi which are currently impossible/unfeasible to
>>     write.
>>
>> * What deliverables do you think are reasonable targets? Can you
>>   outline an approximate schedule of milestones?
>>
>>     The plan is based on the GSoC time line:
>>     20 April - 19 May – while this is a bonding period, I'm already a
>>     part of the Yi community and have a fair grasp of it. I'd start to
>>     look into this project as early as this period (and in fact I plan
>>     to make steps towards it before this date which means some of the
>>     outlined issues might get fixed early ;) ).
>>
>>     19 May - 23 June – coding period; by this point I expect to have
>>     decided on which concurrency model we'll use and have a good idea
>>     of how it'll be implemented. By the end of this period,
>>     concurrency should either be completed or nearly done, depending
>>     on any unexpected problems that might come up. The deliverable
>>     would be Yi with (at least some) concurrency support.
>>
>>     24 June - 11 August – second part of the coding period; work on
>>     any of the listed (or unlisted bugs) and finish up concurrency if
>>     it is still not done. Write extra Yi modes, libraries and
>>     documentation as time allows.
>>
>>     11 August - 18 August – post-coding period; write any missing
>>     documentation, promote any cool new stuff we wrote ;) While I can
>>     not think of a specific deliverable, many bugs should now be
>>     fixed, Yi should have a lot more documentation, tests and modes.
>>
>>     As a final note regarding the time line, it is not strictly
>>     necessary that the project implements concurrency first: while
>>     some bugs might need such support, many simply do not. If it's
>>     convenient to fix something that I had originally planned to for
>>     the second part of the project, I'll do so.
>>
>> * 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?
>>
>>     Second year CS student. I program on regular basis using Haskell.
>>     I contribute to a bunch of FOSS projects as it seems necessary
>>     (see [my GitHub](https://github.com/Fuuzetsu)).
>>     I have successfully completed GSOC in 2013 which involved working
>>     on Haddock. To this day I help out with Haddock which often
>>     involves looking at the large GHC code base.
>>
>> * In what ways do you envisage interacting with the wider Haskell
>>   community during your project? e.g. How would you seek help on
>>   something your mentor wasn't able to deal with? How will you get
>>   others interested in what you are doing?
>>
>>     I have a [blog](http://fuuzetsu.co.uk/blog) which gets propagated
>>     onto Haskell Planet. I'm active on IRC and many Haskell-related
>>     mailing lists. IRC, mailing lists and any relevant literature is
>>     where I'd seek help were I to get stuck on something my mentor
>>     can't help me with. I find that news about Yi are very popular and
>>     get propagated by the community itself very easily so I doubt
>>     there will be any problem getting people interested.
>>
>>     I'm very easily reachable over e-mail and IRC and all the
>>     development is done in public.
>>
>> * Why do you think you would be the best person to tackle this
>>   project?
>>
>>     I've been interested in Yi for a couple of months and have already
>>     wrote some commits, closed quite a few issues and filed even more
>>     issues on my own. I have access to the Yi repository and
>>     I help anyone looking to get started with Yi. I have about 2 years of
>>     Haskell experience and had my fair share of staring at library
>>     code.
>>
>>     As mentioned before, I'm active as a member of the community and
>>     help out with one of the core Haskell projects (Haddock).
>>
>>
>> --
>> Mateusz K.
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskel... at haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>

-- 
Michal Antkiewicz, M.Sc., Ph.D
Research Engineer
Network for the Engineering of Complex Software-Intensive Systems (NECSIS)

University of Waterloo
http://gsd.uwaterloo.ca/mantkiew
mantkiew at gsd.uwaterloo.ca
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140310/da674ca7/attachment.html>