Michal, Yi is an extensible text editor, not an IDE. There’s room for both. -- Kyle Marek-Spartz On March 10, 2014 at 10:28:35 AM, Michal Antkiewicz (mantkiew@gsd.uwaterloo.ca) wrote:

Hi Mateusz,

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?

Just an idea..

Cheers, Michal

On Mon, Mar 10, 2014 at 11:09 AM, 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 Haskell-Cafe@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@gsd.uwaterloo.ca _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On Mon, Mar 10, 2014 at 11:41:57AM -0400, mantkiew@gsd.uwaterloo.ca wrote:

Yes, absolutely. What I meant was that having Yi used in Leksah could provide more momentum for development. ‎I didn't mean to merge the two projects into one. 

Michal   Original Message   From: Kyle Marek-Spartz Sent: Monday, March 10, 2014 11:29 AM To: Mateusz Kowalczyk; Michal Antkiewicz Cc: haskell-cafe Subject: Re: [Haskell-cafe] Yi project proposal for GSOC 2014

Michal,

Yi is an extensible text editor, not an IDE. There’s room for both.

-- Kyle Marek-Spartz

On March 10, 2014 at 10:28:35 AM, Michal Antkiewicz (mantkiew@gsd.uwaterloo.ca) wrote:

...

Hi Mateusz,

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?

Just an idea..

Cheers, Michal

On Mon, Mar 10, 2014 at 11:09 AM, 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 Haskell-Cafe@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@gsd.uwaterloo.ca _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On 10/03/14 15:58, Daniel Trstenjak wrote:

On Mon, Mar 10, 2014 at 11:41:57AM -0400, mantkiew@gsd.uwaterloo.ca wrote:

...

Yes, absolutely. What I meant was that having Yi used in Leksah could provide more momentum for development. ‎I didn't mean to merge the two projects into one.

But then you would have to write an interface between Yi and Leksah and these kind of big interfaces IMHO never really work that well.

I think it makes more sense to have libraries which are shared by Yi and Leksah, which could also be used by other applications and therefore are a bigger win for the whole Haskell ecosystem.

Greetings, Daniel _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Actually, I hear that it's possible to embed Yi inside of Leksah. I have never tried Leksah out but perhaps that's more of what you're after. But yes, generic libraries (that can be used by Yi and Leksah) are certainly a thing that gets written while implementing something (at least from my experience). It is listed as one of the benefits. It's a nice side effect I suppose. -- Mateusz K.

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...@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@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@gsd.uwaterloo.ca

On 10/03/14 16:28, Vagif Verdi wrote:

...

there's already hdevtools

There you go. Another one! See what i'm saying? So much wasted effort and a dozen of half baked programs all of which implement low hanging fruit of the same set of basic features and have no resources left to deliver truly powerful and polished capabilities.

FYI, Yi doesn't aim to be an editor for Haskell (although we certainly strive to support it for obvious reasons). It aims to be written and ‘scriptable’ in Haskell but in the end that's more or less where it ends. Yi certainly doesn't aim to be a Haskell IDE! We have in fact some support for variety of things. Here are the just the lexers that Yi currently has. -rw-r--r-- 1 shana shana 3135 Dec 23 23:53 Abella.x -rw-r--r-- 1 shana shana 6192 Mar 10 12:19 Alex.hs -rw-r--r-- 1 shana shana 460 Dec 13 04:29 BasicTemplate.x -rw-r--r-- 1 shana shana 4396 Mar 10 12:19 Cabal.x -rw-r--r-- 1 shana shana 3804 Jan 7 18:51 common.hsinc -rw-r--r-- 1 shana shana 1172 Mar 10 12:19 Compilation.x -rw-r--r-- 1 shana shana 4294 Mar 10 12:19 Cplusplus.x -rw-r--r-- 1 shana shana 4294 Mar 10 12:19 C.x -rw-r--r-- 1 shana shana 3360 Dec 13 04:29 GitCommit.x -rw-r--r-- 1 shana shana 5995 Mar 10 12:19 GNUMake.x -rw-r--r-- 1 shana shana 10378 Mar 10 12:19 Haskell.x -rw-r--r-- 1 shana shana 9664 Dec 23 23:53 JavaScript.x -rw-r--r-- 1 shana shana 4229 Mar 10 12:19 Java.x -rw-r--r-- 1 shana shana 1806 Mar 10 12:19 JSON.x -rw-r--r-- 1 shana shana 16615 Mar 10 12:19 Latex.x -rw-r--r-- 1 shana shana 9427 Dec 13 04:29 LiterateHaskell.x -rw-r--r-- 1 shana shana 4466 Mar 10 12:19 ObjectiveC.x -rw-r--r-- 1 shana shana 4263 Dec 23 23:53 OCaml.x -rw-r--r-- 1 shana shana 3438 Mar 10 12:19 Ott.x -rw-r--r-- 1 shana shana 15750 Mar 10 12:19 Perl.x -rw-r--r-- 1 shana shana 3520 Mar 10 12:19 Python.x -rw-r--r-- 1 shana shana 4179 Mar 10 12:19 Ruby.x -rw-r--r-- 1 shana shana 3191 Mar 10 12:19 Srmc.x -rw-r--r-- 1 shana shana 914 Mar 10 12:19 SVNCommit.x -rw-r--r-- 1 shana shana 648 Jan 15 10:16 Whitespace.x To further reinforce what I'm trying to say, if we ever needed some IDE-like features for Haskell, we could certainly use hdevtools: they are 2 completely different projects, without any real overlap. I hope this clears it up. -- Mateusz K.

And what exactly stops your one-to-rule-them-all from just becoming yet another one?

We are not discussing here what tool is the best and try to mandate everyone to use it. We are discussing how to efficiently use the scarce development resources (time, money) for the benefit of haskell community. It does not matter if the specific tool will succeed in adoption or not. Trying to create one is still the best course of action.

Build a consensus *first*

The consensus is already there. It is obvious the demand for such tool is high, hence many (failed) attempts. Failed because of the lack of resources and coordination.

As far as I can see, it is based on wishful thinking alone.

I already pointed at existing successful implementations (clojure's nrepl and lisps slime-swank). If they can do it, so can we. On Monday, March 10, 2014 10:05:41 AM UTC-7, Brandon Allbery wrote:

On Mon, Mar 10, 2014 at 12:28 PM, Vagif Verdi javascript:

...

wrote:

...

...

there's already hdevtools

There you go. Another one! See what i'm saying? So much wasted effort and a dozen of half baked programs all of which implement low hanging fruit of the same set of basic features and have no resources left to deliver truly powerful and polished capabilities.

And what exactly stops your one-to-rule-them-all from just becoming yet another one? (Or: what exactly means that the world will flock to your proposal instead of continuing to do what it already does?) As far as I can see, it is based on wishful thinking alone.

Build a consensus *first* and make sure you're serving everyone else's needs and that everyone else is interested. Otherwise you end up with https://xkcd.com/927/.

-- brandon s allbery kf8nh sine nomine associates allb...@gmail.com javascript: ball...@sinenomine.net javascript: unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

[image: Close] Read more >> Options >> [image: Visit Answers.com] http://www.answers.com?initiator=FFANS

On 17/03/14 21:10, Ketil Malde wrote:

...

We are not discussing here what tool is the best and try to mandate everyone to use it. We are discussing how to efficiently use the scarce development resources (time, money) for the benefit of haskell community.

Well, in the end the proposals will be voted over. Less general proposals are likely to get fewer votes.

...

The consensus is already there. It is obvious the demand for such tool is high, hence many (failed) attempts. Failed because of the lack of resources and coordination.

Say what? I'm not familiar with the others, but Emacs and haskell-mode and ghc-mode and darcsum works pretty well for me - I'd certainly not call them failures.

(Of course, I would rather see somebody spending GSoC working on them, but I accept that other people prefer other systems. But while I'm at it, some things I might like to see would be:

- quickcheck/flymake support, so that funcitons with failing unit tests are highlighted automatically - code coverage highlighting in buffer - org-mode-like folding and refiling - automatic import/export list management - perhaps easy navigation between source and core? )

-k

As I pointed out, Yi is not one of these attempts. The people in this sub-thread made their own thread (Haskell IDEs or something) so you might want to reply there. -- Mateusz K.

guys, move the yak shaving / shedding to another thread please, lets Help give Mateusz feedback for his proposal on contributing to a haskell editor. What are some ancillary sub tasks you can do independent of the concurrency piece? Concurrency is hard and evil and tricky. It'd be great if you work that out, but *IF* that blows up into a thorny mess, what are some other sub projects you plan to do either way? -Carter On Mon, Mar 10, 2014 at 1:27 PM, Daniel Trstenjak < daniel.trstenjak@gmail.com> wrote:

...

There you go. Another one! See what i'm saying? So much wasted effort and a dozen of half baked programs all of which implement low hanging fruit of

...

same set of basic features and have no resources left to deliver truly

On Mon, Mar 10, 2014 at 09:28:50AM -0700, Vagif Verdi wrote: the powerful

...

and polished capabilities.

Sorry, but I don't like this kind of attitude.

Wasted effort? People having fun hacking around and perhaps don't want to coordinate with several people to get something done, because that's what they already have to do at their day job.

It's a lot of work to get something powerful and polished, and in a lot of cases this doesn't even happen in a commercial setting and even fewer people will do it in their spare time.

...

On Monday, March 10, 2014 9:22:16 AM UTC-7, Michal Antkiewicz wrote:

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...@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskel...@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 mant...@gsd.uwaterloo.ca

...

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Yi isn't a tool designed solely to edit Haskell source code any more than vim is designed solely to edit vim-script. As far as I'm aware the only editor to swallow its tail to that point where editing other file types is largly a side-goal is emacs. ;) Leksah and Yi have very different goals. Yi could profitably exist without *any* integration with ghci for editing other languages, as its stated goal is to be an editor scriptable with Haskell, much like emacs is an editor scriptable with elisp. Leksah aspires to be an IDE. Lashing out at the existence of Yi, because it might be used by someone some day to edit Haskell seems misguided and rather off topic to the subject of working on the concurrency aspects of a text editor. -Edward On Mon, Mar 10, 2014 at 12:04 PM, Vagif Verdi wrote:

I do not think we need more haskell aware editors and IDEs. There's more than enough already: emacs, vim, Eclipse, Leksah, Yi. What we need though is a IDE backend so any editor can use it to provide hakell IDE features. As it stands right now all haskell IDEs reinvent the wheel in some incompatible manner. EclipseFp has scion, some emacs modes develop ghc-mod backend. Leksah lives in its own world. ghci added some IDE support features recently. This fragmentation hurts us.

I would say making ghci a full-blown IDE backend akin lisps slime-swank or clojure nrepl would be the best approach.

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...@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On 10/03/14 16:13, Roman Cheplyaka wrote:

* Mateusz Kowalczyk [2014-03-10 15:09:49+0000]

...

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.

From what I've seen, the less uncertainty there is in a GSoC project, the better it works. For example, the situation in your past GSoC project where it was decided in the middle that instead of implementing markdown syntax you're going to do other things is undesirable, IMO.

That was indeed unfortunate. Well, technically Markdown was only part of the project and ‘the other things’ were the other part of the project. I do understand where you're coming from however.

3 months is a very short time for a research project. (By research I mean not academic research, but finding a way (or the best way) to do something.) And here you're basically saying "there are several ways to do that, we'll figure out what to do as we go".

We're aware of this. The problem is that if I were to conduct this research starting today and it takes a week to settle on which approach we'll take, we end up with close to no discussion period as the proposal submissions are open for 10 days. I left it open like this because it's an implementation detail: after playing with it for a few days, it might turn out that the FRP approach is actually amazing and we should do that. I'd rather not tie myself to a specific implementation before even considering other options. If I state today that we'll use STM, I'm stuck with STM even if it turns out a terrible idea. In the end the goal is to allow for concurrency in the editor state, and that much should be clear.

If, on the other hand, it was already decided what the right architecture for concurrency in Yi should be, and it was just a matter of someone doing the work, it would be a good project.

In this case, deciding on the right architecture is part of doing the work.

Roman

-- Mateusz K.

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.

On 11/03/14 08:04, Carter Schonwald wrote:

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

I am far too well aware of this ;P The reason why I'm not even mentioning this as a possibility is because it is a terrible thing to do and requires a lot of juggling to behave more or less like you'd want it. Even today I have my emacs freeze up when I run cabal repl inside of it for the first time. Also as I mentioned, we have no means to periodically run things, which means we can't periodically query our subprocess. There is no mechanism for such scheduling and while doing it in a single thread like emacs and vim do is *a* way to do it, you yourself point out that it's sub-par. So yeah, I'm not even starting to consider that option, I don't want to end up with yet another editor that doesn't do actual concurrency. -- Mateusz K.

On 11/03/14 20:46, Evan Laforge wrote:

I support this idea for purely selfish reasons. I write haskell in vim, and I'm constantly bothered by vim bugs that will likely never be fixed, and I don't dare try to fix them myself because vim source is such a jungle. I have several extensions for syntactic manipulation written in vimscript and python, and they mostly work but not entirely reliably because vim extension is clumsy. I use tags and they also have problems, but once again I'm not about to go in and redo vim's tag support. Etc. etc.

I do hope that this is where a lot of support for Yi will come from.

Yi is tempting because it promises to be a place where I could fix these things for real, but I've been discouraged in the past by immaturity (can't even get it to build) and lack of documentation. So I think some concentrated attention to the build, documentation, general cleanliness, and performance would be a great idea. I'm not too fussed about a lack of concurrency since I think there are more fundamental problems, but if it would result in improvements to those fundamental problems, I'm all for it.

While there are more fundamental problems as you mention, we don't stand a chance without concurrency to come close to what existing editors can do. Certainly documentation will get written during the project. I don't explicitly mention it partly because it should implied that we document what we're doing and partly because Google doesn't allow for documentation projects so I didn't want to make it sound like one. PS: If you can't get it to build or are struggling otherwise, please pop into #yi on Freenode and we will almost certainly be able to help you (although you might have to wait for one of us to be online). There's also a mailing list although you might have to wait a bit longer (although a reply is more certain). If you have any specific issues (even if they are “Please document XYZ”), please do make issues on GitHub! -- Mateusz K.