[Haskell-cafe] Re: Anyone up for Google SoC 2010?

[Thomas Schilling]

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



-- 
Push the envelope.  Watch it bend.