Hi,
: I'm just wondering, if the following would be possible with Perl 6 or not?
: : > XML
: : $a=<elems><elem>Content #1</elem><elem>Content #2</elem></elems>;
: : say $a.elems[0].elem[1].content; # "Content #1"
: : for ($a.elems) { say $_.content; }
: : or XPath like syntax on a structure?
That's somewhat ambiguous with our current qw// notoation.
Yes, I've realized it. One of the reason of my mail was this.
: > SQL
: : $a=select * from table;
: for(select * from table where id>5) {
: say $_.id ~ ' -> ' $_.value;
: }
That one would be pretty easy to do with a "select" macro, if you could figure out how to terminate the SQL parse.
It ends, when a non opened ')', a ';' or a '}' is coming. Of course, that's not all cases, but it seems to be not so hard to find the all possible cases.
: The ideas coming from Comega, the next version of CSharp(?). Here's an : intro about it:
: : http://www.xml.com/pub/a/2005/01/12/comega.html?page=2
: : Or just search for "comega" with you favourite search engine.
: : The first one, creating native XML support for a language is not new, : E4X (EcmaScript for XML) is about the same:
: : http://www.ecma-international.org/publications/standards/Ecma-357.htm
: : I think both about macros, and it seem's it will be possible extend Perl : 6 with them. But what do you think about extending Perl 6 (or Perl 6.1) : with native XML handling, like it's native regular expression / rule : handling?
Let me note, that E4X is not just about declaring, but processing, too.
We should avoid installing fads or domain-specific sublanguages into Standard Perl 6, but it's easy enough to change the language with a single "use" or macro. I see that doing select is trivial and doesn't impact anything in Standard Perl 6, since Perl 5's select() is likely going away anyway.
I'm not sure, if XML is more domain specific than regexp or not. I think it's somewhere related to text processing as much as regexpes.
It's a little harder to sneak <foo>...</foo> into the language since we have <foo> to mean qw/foo/ as a term. Perhaps this is indicating
that we should reserve a character for introducing user-defined terms.
I suppose the logical candidate for that is ` these days, since pretty
much everything else in ASCII land is taken. So you could write
a macro on ` that treats the next thing as a self-terminating construct.
(That is, no terminating ` is required, though the default `...` could
still parse to mean q:x/.../, I suppose. You'd lose that if you redefine
term:<`> to something else, but no big loss, unlike <foo>.) Anyway,
you'd get things like:
$a=`<elems><elem>Content #1</elem><elem>Content #2</elem></elems>;
I don't like it. I've learned at Perl 5 and in other languages, that ` need a closing `.
It would be nicer to say:
$a=xml<elems><elem>Content #1</elem><elem>Content #2</elem></elems>;
But native xml parsing is better, I think. :)
$a=`select * from table`;
It looks better, but I think ` isn't needed for it. Anyway, I agree, that SQL is a more domain specific language, that it should come from a module - at least you have to give for initialization somewhere the server address, the user and the password (or other connection parameters), so it's better to do it at with a setup sub.
Anyway, it's possible to write:
$a=sql<select * from table>;
I've gone ahead and terminated the sql variant like a quote construct just to clarify the end of it, since SQL is not so obviously self-terminating as XML is.
If MS Comega and E4X can do it, I think Perl 6 could do it easily, too. ;)
You could not, of course, have both of those unless you did lookahead to see if the next thing was < or select. Hmm, maybe that should be standard behavior for user-defined ` extensions. If the actual
I agree, except the notation.
Bye, Andras
