<div dir="ltr"><div><div>Hi Mateusz, <br><br></div>An interesting application is always what drives development. There's a need to have a good IDE with strong editing support for Haskell written in Haskell. There's Leksah and there's Yi. Perhaps they could be integrated? <br>
<br></div><div>Just an idea..<br><br></div><div>Cheers,<br></div>Michal<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Mar 10, 2014 at 11:09 AM, Mateusz Kowalczyk <span dir="ltr"><<a href="mailto:fuuzetsu@fuuzetsu.co.uk" target="_blank">fuuzetsu@fuuzetsu.co.uk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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<br>
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/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<br>
feedback.<br>
<br>
Thanks!<br>
<br>
<br>
Yi concurrency, usability and hackability<br>
------------------------------------------<br>
<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<br>
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>
<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<br>
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<br>
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<br>
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/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<br>
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<br>
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<br>
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/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<br>
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<br>
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<br>
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<br>
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<br>
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<br>
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<br>
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<br>
the second part of the project, I'll do so.<br>
<br>
* What relevant experience do you have? e.g. Have you coded anything<br>
in Haskell? Have you contributed to any other open source software?<br>
Been studying advanced courses in a related topic?<br>
<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<br>
(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<br>
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<br>
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/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<br>
there will be any problem getting people interested.<br>
<br>
I'm very easily reachable over e-mail and IRC and all the<br>
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<br>
help out with one of the core Haskell projects (Haddock).<br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
--<br>
Mateusz K.<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>
</font></span></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>