> 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

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

I'll just toss this idea out there:

I want to be able to pick a runtime to compile against. Some Ada compilers
allow me to specify a runtime to use with a --RTS flag. This, of course,
also means we'd need to write more runtime variants.

I dropped this on the haskell_proposals reddit for safe keeping/evaluation:
[url]http://www.reddit.com/r/haskell_proposals/comments/azjah/pluggable_rts_for_ghc_pickyourownruntime/[/url]

/jve

On Sun, Jan 31, 2010 at 6:04 AM, Malcolm Wallace <
[email]malcolm.wallace@cs.york.ac.uk[/email]> 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
>
> _______________________________________________
> Haskell-Cafe mailing list
> [email]Haskell-Cafe@haskell.org[/email]
> [url]http://www.haskell.org/mailman/listinfo/haskell-cafe[/url]
>

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

On Sun, Jan 31, 2010 at 12:04 PM, Malcolm Wallace <
[email]malcolm.wallace@cs.york.ac.uk[/email]> 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)


Here's a proposal for a project I'd be willing to mentor:

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

Almost all web applications need to generate HTML for rendering in the
user's browser. The three perhaps most important properties in an HTML
generation library are:

- High performance: Given that the network introduces a lot of latency the
server is left with very little time to create a response to send back to
the client. Every millisecond not spent on generating HTML can be used to
process the user's request. Furthermore, efficient use of the server's
resources is important to keep the number of clients per server high and
costs per client low.

- Correctness: Incorrectly created HTML can result in anything from
incorrect rendering (in the best case) to XSS attacks (in the worst case).

- Composability: Being able to create small widgets and reuse them in
several pages fosters consistency in the generated output and helps both
correctness and reuse. (Formlets play a big roll here but being able to
treat HTML fragments as values rather than as strings is important too.)

Combinator libraries, like the 'html' package on Hackage [1], address the
the last two criteria by making the generated HTML correct by construction
and making HTML fragments first class values. Traditional templating systems
generally have the first property, offering excellent performance, but lacks
the other two.

Task: Create a new HTML combinator library, based on the 'html' library,
that's blazing fast, well tested and well documented. Also improve upon the
'html' package's API by e.g. splitting the attribute related functions into
their own module.

Tools: QuickCheck for testing, Criterion for benchmarking, and Haddock for
documenting.

1. [url]http://hackage.haskell.org/package/html[/url]

-- Johan

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

Hi Johan,

On Fri, Mar 5, 2010 at 6:18 AM, Johan Tibell <johan.tibell@gmail.com> 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.


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

-- iquiw
_______________________________________________
Haskell-Cafe mailing list
[email]Haskell-Cafe@haskell.org[/email]
[url]http://www.haskell.org/mailman/listinfo/haskell-cafe[/url]

On Fri, Mar 5, 2010 at 4:48 AM, iquiw <iku.iwasa@gmail.com> wrote:

> Hi Johan,
>
> On Fri, Mar 5, 2010 at 6:18 AM, Johan Tibell <johan.tibell@gmail.com>
> 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

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

On Fri, Mar 5, 2010 at 8:07 AM, Johan Tibell <johan.tibell@gmail.com> wrote:

> On Fri, Mar 5, 2010 at 4:48 AM, iquiw <iku.iwasa@gmail.com> 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.
>

This should of course have been "unqualified"!

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

On Fri, Mar 5, 2010 at 4:07 PM, Johan Tibell <johan.tibell@gmail.com> 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
_______________________________________________
Haskell-Cafe mailing list
[email]Haskell-Cafe@haskell.org[/email]
[url]http://www.haskell.org/mailman/listinfo/haskell-cafe[/url]

Johan Tibell <johan.tibell@gmail.com> 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.

--
(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
[email]Haskell-Cafe@haskell.org[/email]
[url]http://www.haskell.org/mailman/listinfo/haskell-cafe[/url]

On Fri, Mar 5, 2010 at 3:46 PM, Achim Schneider <barsoap@web.de> wrote:

> Johan Tibell <johan.tibell@gmail.com> 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

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

Johan Tibell <johan.tibell@gmail.com> wrote:

> On Fri, Mar 5, 2010 at 3:46 PM, Achim Schneider <barsoap@web.de>
> wrote:
>
> > Johan Tibell <johan.tibell@gmail.com> 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
[email]Haskell-Cafe@haskell.org[/email]
[url]http://www.haskell.org/mailman/listinfo/haskell-cafe[/url]