[Haskell-cafe] Yi project proposal for GSOC 2014
mantkiew at gsd.uwaterloo.ca
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?
> On Monday, March 10, 2014 8:09:49 AM UTC-7, Mateusz Kowalczyk wrote:
>> 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
>> 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
>> 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 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
>> * 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
>> 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
>> 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
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
Michal Antkiewicz, M.Sc., Ph.D
Network for the Engineering of Complex Software-Intensive Systems (NECSIS)
University of Waterloo
mantkiew at gsd.uwaterloo.ca
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-Cafe