What's the status on this? Have we applied as organization? Do we have enough mentors? Cheers, Johan On Mon, Feb 1, 2010 at 4:02 PM, Edward Kmett wrote:

I would happily participate as a mentor again and I am willing to step up as administrator if you want to get it off your plate.

-Edward Kmett

On Sun, Jan 31, 2010 at 6:04 AM, Malcolm Wallace < malcolm.wallace@cs.york.ac.uk> wrote:

...

Google has announced that the Summer of Code programme will be running again this year. If haskell.org people would like to take part again this year, then we need volunteers:

First, * suggestions for suitable projects (in the past this was organised using a reddit) * an administrator to co-ordinate the application to Google (I have done it for the last three years but am very willing to hand on to someone else)

Google will accept applications from organisations in the period 8th - 12th March 2010, approx 1900UTC.

If haskell.org is accepted again, students can apply between 29th March - 9th April. More volunteers will be required:

* to review student applications and choose which to accept * to supervise the accepted students

Both of these roles are called "mentor" in the Google system. Putting together a good team of mentors before applying as an organisation is helpful towards us being accepted into the programme.

Regards, Malcolm

I'd also be happy to mentor. Where is the official place to collect project ideas? We used trac previously, are we still using it or are we now on Reddit? Thanks, Neil 2010/2/1 sterl :

Malcolm Wallace wrote:

...

Google has announced that the Summer of Code programme will be running again this year.  If haskell.org people would like to take part again this year, then we need volunteers:

I'd be happy to mentor again as well. It's important to bear in mind that the total number of mentors plays a small role in slot allocation, but far more important is to maximize the amount of high-quality applications -- the more students we encourage to submit proposals, the more proposals we will be able to fund: http://socghop.appspot.com/document/show/program/google/gsoc2009/studentallo...

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

On Tue, Feb 2, 2010 at 5:11 PM, Johan Tibell wrote:

On Tue, Feb 2, 2010 at 2:06 PM, Neil Mitchell wrote:

...

I'd also be happy to mentor. Where is the official place to collect project ideas? We used trac previously, are we still using it or are we now on Reddit?

Is there a way to prune the reddit list? Some of the projects (like 'text') are already done. Also, voting doesn't work well for reddit as we're still seeing votes from last year. -- Johan

You can prune them personally with 'hide', and I suppose the subreddit moderator can delete expired entries. -- gwern

On Wed, 03 Feb 2010 23:34:34 +0100, Neil Mitchell wrote:

Hi Gwern,

Please update: "haskell-src-exts -> haskell-src" **Unknown**

This project was an unqualified success. haskell-src-exts is now one of the most commonly used Haskell libraries, achieved the goals in the project proposal, and is an essential piece of Haskell infrastructure.

You can see this using Roel van Dijk's reversed dependencies overview [1]: 23 direct and 57 indirect dependencies on haskell-src-exts-1.8.0 Regards, Henk-Jan van Tuyl [1] http://bifunctor.homelinux.net/~roel/cgi-bin/hackage-scripts/package/haskell... -- http://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html --

Gwern Branwen wrote:

On Wed, Feb 3, 2010 at 8:14 PM, Henk-Jan van Tuyl wrote:

...

On Wed, 03 Feb 2010 23:34:34 +0100, Neil Mitchell wrote:

...

Hi Gwern,

Please update: "haskell-src-exts -> haskell-src" **Unknown**

This project was an unqualified success.  haskell-src-exts is now one of the most commonly used Haskell libraries, achieved the goals in the project proposal, and is an essential piece of Haskell infrastructure.

You can see this using Roel van Dijk's reversed dependencies overview [1]: 23 direct and 57 indirect dependencies on haskell-src-exts-1.8.0

Regards, Henk-Jan van Tuyl

And how many of those used haskell-src-exts *before* the SoC project? And would have used it regardless? You can't point to a popular project which got a SoC student, and say look at how popular it is - obviously the SoC student was hugely successful.

Regardless of that, is there any reason to disregard Neil's summary and not update your page? Ganesh =============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ===============================================================================

You can add me to the list of voices that were unwilling to use it before the summer-of-code project due to the random incompatibilities caused by the huge supply of extensions it supported out of the box, but who were happy to switch to it after the changes were made to make them configurable. That said, I don't support a major public application. But keep in mind haskell-src-exts is used by almost every quasiquoter that wants antiquotation, so the improvements in mere compatibility with Haskell 98 as a baseline have had fairly wide-reaching impact, affecting almost every one of those 23 (or 57 depending how you count) dependencies on the haskell-src-exts library. One might argue that that well exceeds your 3 or 4 feature user guideline. =) The rest is just gravy that happens to permit a number of applications such as refactoring browsers that were impossible with the previous implementation. And, as I recall, the fairly radical exploratory "pretty print . parse = id" goal was explicitly listed merely as a secondary goal on the original application. It seems hardly appropriate to judge the impact of the entire SoC effort on the impact of that secondary exploratory component. -Edward Kmett On Fri, Feb 5, 2010 at 12:48 PM, Gwern Branwen wrote:

On Fri, Feb 5, 2010 at 6:20 AM, Sittampalam, Ganesh wrote:

...

Gwern Branwen wrote:

...

On Wed, Feb 3, 2010 at 8:14 PM, Henk-Jan van Tuyl wrote:

...

On Wed, 03 Feb 2010 23:34:34 +0100, Neil Mitchell wrote:

...

Hi Gwern,

Please update: "haskell-src-exts -> haskell-src" **Unknown**

This project was an unqualified success. haskell-src-exts is now one of the most commonly used Haskell libraries, achieved the goals in the project proposal, and is an essential piece of Haskell infrastructure.

You can see this using Roel van Dijk's reversed dependencies overview [1]: 23 direct and 57 indirect dependencies on haskell-src-exts-1.8.0

Regards, Henk-Jan van Tuyl

And how many of those used haskell-src-exts *before* the SoC project? And would have used it regardless? You can't point to a popular project which got a SoC student, and say look at how popular it is - obviously the SoC student was hugely successful.

Regardless of that, is there any reason to disregard Neil's summary and not update your page?

Ganesh

I prefer to wait. haskell-src-exts was popular before, it was popular after. The question is not whether the patches were applied, or whether the mentor told Google it was successful, but whether it was the best possible use of the SoC slot. If features do not get used, then it wasn't a good SoC. If you know 3 or 4 uses of the new haskell-src-exts features in (relatively) major applications like hlint, then I'll concede the point and mark it a success.

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

On Fri, Feb 5, 2010 at 3:38 PM, Niklas Broberg wrote:

I'm at a loss as to what criteria is actually used to judge success here. It seems to me a bit like the eternal discussion between "basic research" and "applied research". Just because something (research/library/project) doesn't have an immediate, palpable impact and/or delivers a visible tool, that certainly doesn't imply that it doesn't have merit or won't have as profound an impact on the domain, if more diffuse than a tool (or other palpable deliverable) would.

/Niklas

There may be an eternal discussion on it, but it seems pretty clear to me which side SoC comes down on: http://code.google.com/soc/ "Through Google Summer of Code, accepted student applicants are paired with a mentor or mentors from the participating projects, thus gaining exposure to real-world software development scenarios and the opportunity for employment in areas related to their academic pursuits. In turn, the participating projects are able to more easily identify and bring in new developers. Best of all, more source code is created and released for the use and benefit of all." or http://socghop.appspot.com/document/show/program/google/gsoc2009/faqs#goals # Google Summer of Code has several goals: * Get more open source code created and released for the benefit of all * Inspire young developers to begin participating in open source development * Help open source projects identify and bring in new developers and committers * Provide students the opportunity to do work related to their academic pursuits during the summer (think "flip bits, not burgers") * Give students more exposure to real-world software development scenarios (e.g., distributed development, software licensing questions, mailing-list etiquette) -- gwern

If the goal is to have "more source code [..] created and released for the use and benefit of all", how does my project fail to achieve this?

Also, it is worth pointing out that from Google's point of view, they are most interested in whether the programme yields students who stick around and continue to contribute to open source projects. I think Niklas and his HSE library very visibly pass on both criteria - quality code that is actively used, and a continuing contribution. Regards, Malcolm

Hello! [snip]

We're particularly interested in three things: (i) making Darcs faster (ii) building nice GUI tools and (iii) working seamlessly with SVN/Git repositories [snip]

...

Both of these roles are called "mentor" in the Google system. Putting together a good team of mentors before applying as an organisation is helpful towards us being accepted into the programme.

I'll volunteer as a mentor if it helps.

Darcs users: if you have a few spare hours this summer, this would be a most excellent way to participate. Stick your hand up :-)

I am volunteering as a mentor as well. My schedule is too crammed to go the student way this year (and, probably, any future year). I am particularly interested in mentoring (i) kinds of projects mentioned by Eric above, but other will do, depending on what prospective students come up with. Yours, Petr.

On Fri, Mar 5, 2010 at 4:48 AM, iquiw wrote:

Hi Johan,

On Fri, Mar 5, 2010 at 6:18 AM, Johan Tibell wrote:

...

Here's a proposal for a project I'd be willing to mentor: = A high-performance HTML combinator library using Data.Text =

Nice project! I would like to see the project will be accepted.

Perhaps it's not scope of the project, but if compatibility doesn't matter, I want new HTML library have uniform naming convention for functions that based on element or attribute.

For example, function name should be; - "e_" + element name ("html", "head", "body" => "e_html", "e_head", "e_body") "a_" + attribute name ("href", "id", "class" => "a_href", "a_id", "a_class") or - "e" + capitalized element name ("html", "head", "body" => "eHtml", "eHead", "eBody") "a" + capitalized attribute name ("href", "id", "class" => "aHref", "aId", "aClass")

or some other convention.

I think I would use the module system for namespacing rather than using function prefixes. Like so: import Text.Html as E import qualified Text.Html.Attribute as A E.html ! [A.class_ "my-class"] (... more combinators ...) (Assuming that "!" is used to introduce attributes.) This allows you to use the element names and/or the attribute names unclassified if you so desire. html ! [class_ "my-class"] (... more combinators ...) Function names in the 'html' library are unpredictable from

corresponding element/attribute names... ("head", "base", "a" => "header", "thebase", "anchor")

I'm of the same opinion. The combinators should match the element/attribute names as far as possible. The rule that I had in mind was that the combinators should have exactly the same name as the corresponding element/tag except when the name collides with a keyword (e.g. "class"). If the name collides with a keyword we could e.g. always append a "_". Cheers, Johan

On Fri, Mar 5, 2010 at 4:07 PM, Johan Tibell wrote:

I think I would use the module system for namespacing rather than using function prefixes. Like so: import Text.Html as E import qualified Text.Html.Attribute as A E.html ! [A.class_ "my-class"] (... more combinators ...)

(Assuming that "!" is used to introduce attributes.) This allows you to use the element names and/or the attribute names unclassified if you so desire. html ! [class_ "my-class"] (... more combinators ...)

...

Function names in the 'html' library are unpredictable from corresponding element/attribute names...  ("head", "base", "a" => "header", "thebase", "anchor")

I'm of the same opinion. The combinators should match the element/attribute names as far as possible. The rule that I had in mind was that the combinators should have exactly the same name as the corresponding element/tag except when the name collides with a keyword (e.g. "class"). If the name collides with a keyword we could e.g. always append a "_".

That's fine. However, I think no one uses unqualified import actually because of conflict with basic functions ("head", "id", "map") and existent of single character functions ("a", "b", "i", "p"). Anyway, I like the project. Thanks, iquiw

On Fri, Mar 5, 2010 at 3:46 PM, Achim Schneider wrote:

Johan Tibell wrote:

...

= A high-performance HTML combinator library using Data.Text =

May I add

* Conceptual compatiblity with the W3C DOM. The library shoud be designed in a way that allows a thin / automatically generated wrapping layer to support DOM operations, where applicable.

?

It is a "keep that in mind", not absolute, requirement.

I'm not quite sure I understand what you have in mind. Do you mean that given a value of type Html you can e.g. query by ID to find children? Cheers, Johan

If it uses only one type for elements and perhaps another for attributes, Uniplate should fit any traversal needs perfectly. E.g., getElementByID: listToMaybe [ e | e <- universe doc, elemID e == target_id ] or similar. This is doing essentially a depth-first search, so if this is a common operation, you'd need some further optimisation, but then I'm not convinced "raw" HTML is a good internal representation anyway. On 5 March 2010 16:20, Achim Schneider wrote:

Johan Tibell wrote:

...

On Fri, Mar 5, 2010 at 3:46 PM, Achim Schneider wrote:

...

Johan Tibell wrote:

...

= A high-performance HTML combinator library using Data.Text =

May I add

* Conceptual compatiblity with the W3C DOM. The library shoud be  designed in a way that allows a thin / automatically generated  wrapping layer to support DOM operations, where applicable.

?

It is a "keep that in mind", not absolute, requirement.

I'm not quite sure I understand what you have in mind. Do you mean that given a value of type Html you can e.g. query by ID to find children?

The overall idea is that if we chose to write a browser in Haskell, which will come with an ECMAscript implementation in Haskell, it'd be nice if that HTML library could be developed into something that can be used as internal DOM representation (and messed with from the ECMAscript side) without breaking the already existing Haskell interface.

Also, web developers that know DOM inside out shouldn't be alienated by Haskell doing things in a way that isn't compatible with their intuition about how DOM/HTML works.

That is, the library should show potential to be queryable (with some generics library) with the same semantics as DOM, meaning that the information necessary to do that should be present.

...I don't mean that the library as implemented for the SoC must support such queries, but that e.g. a (to be written) library with the same haskell combinators that spews out an ADT instead of a string should be.

-- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited.

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

-- Push the envelope. Watch it bend.