The XML module in Phobos

[Andrei Alexandrescu]

Daniel Keep wrote:
> 
>> Andrei Alexandrescu wrote:
>>> It would be great if you could contribute to Phobos. Two things I hope
>>> from any replacement (a) works with ranges and ideally outputs ranges,
>>> (b) uses alias functions instead of delegates if necessary.
> 
> There's really only one sane way to map XML parsing to ranges: pull
> parsing, which is more or less already a range.  For those unfamiliar
> with it, this is how you use Tango's pull parser right now:
[snip]
> This would fairly naturally map to a range of parsing events and look
> something like:
> 
> foreach( event ; new PullParser!(char)(xmlSource) )
> {
>     switch( event.type )
>     {
>         /* again with the cases */
>     }
> }

Looks great. The network I/O could run separately too, in a 
consumer/producer fasion.

> Of course, most people HATE this method because it requires you to write
> mountains of boilerplate code.  Pity, then, it's also the fastest and
> most flexible.  :P  (It's a pity D doesn't have extension methods since
> then you could probably do something along the lines of LINQ to make the
> whole thing utterly painless... but then, I've given up on waiting for
> that.)
> 
> This is basically the only way to map xml parsing to ranges.  As for
> CONSUMING ranges, I think that'd be a bad idea for the same reason
> basing IO entirely on ranges is a bad idea.

Interesting. Could you please give more details about this? Why is 
range-based I/O a bad idea, and what can we do to make it a better one?

And what's the way that avoids writing boilerplate code but is slower? 
Is that the method that calls virtual functions (or delegates) upon each 
element received?

> The only other use for ranges I can think of is one already mentioned by
> Benji: traversal of a DOM.  Ranges don't apply to SAX because that's
> what pull parsing is. :D

Yah, I was thinking of the DOM traversal too. Yum.

> To Andrei: I sometimes worry that your... enthusiasm for ranges is going
> to leave us with range-based APIs that don't make any sense or are
> horribly slow (IO in particular has me worried).  But then, I suppose
> that also makes you the perfect person to figure out where they CAN be used.
> 
> Plus, that way it's your fault if it doesn't work out.  :P

I don't think you need to worry about my doing anything that's 
inherently slow. Performance is a big concern where I'm coming from (and 
also where I'm going to; incidentally all job offers I've been getting 
are in high-performance computing). As for excessive enthusiasm, that's 
always a risk but I'm sure I'll hear from you all if I lose my bearings.


Andrei