That's not really what I'm looking for, but it's pretty neat.

What I'm looking for is something like this:

    my $xml_fragment = <records>
                         <record id="001">foo</record>
                         <record id="002">bar</record>
                       </records>;
    my @nodeset = $xml_fragment =~ qx!//records[@id = '001']!;
    die "ids should be unique!\n" if @nodeset > 1;
[download]

Note that no quoting is needed around the xml fragment; the angle-brackets should be sufficient to identify it as an xmlnode (including the whitespace). Also note that I'm inventing a qx quote operator to wrap an xpath expression, and overloading =~ to allow me to execute the xpath expression on my $xml_fragment scalar, which contains an xmlnode data element. The return value of the qx operator is a nodeset, which is just an array of xmlnode scalars.

Doug.

I guess I don't see the advantage of having something like this built into the language. It's both easy and reasonable to implement it in an extension (i.e. a "library" or "module").

(PS: qx is already in use.)

Interestingly, what the OP describes (basically, to promote XML expressions and constructs to first class objects) is not so foreign to language designers. I know at least to cases when it was done: one is Comega for C# and the other is XML::XSH. The latter one lets you mix in Perl and XML expressions, so it is really nice example of building XML into the language.

rg0now

Sure, my example is easily done using XML::LibXML, but it'd take a lot more code. This is similar to the fact that regular expressions in other languages are generally implemented as add-in libraries, and have the same capabilites as perl's regexes, but are a lot more cumbersome to use.

Also, if this were implemented as a native type, I have a gut feeling that it'd fit naturally into other expressions in a way that would be unnatural or impossible with the library approach.

For example, I'd bet Storable would be able to persist an xmlnode scalar to disk, and read it back in, in a way that looks just like persisting any other datatype. This is something that you just can't do with XML::LibXML without going through a complete deparse/reparse cycle, and the maintainer of XML::LibXML is pretty adamant about keeping it that way.

There would probably also be more natural fits with existing perl keywords, like grep/map/sort/foreach, which are cumbersome when you need to use a libraries methods to work with xml.

That's my hope, at least.

Doug.

PS: yeah, I thought qx was already in use, but you get the idea

Also, angle brackets are already used as well, so that would not suffice as identifying an xmlnode.

It is curious that you'd want these elements built in to perl, since (with only minor modification) your example code could be made to work with existing tools anyway.

=oQDlNWYsBHI5JXZ2VGIulGIlJXYgQkUPxEIlhGdgY2bgMXZ5VGIlhGV