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?

 > SQL

$a=select * from table;
for(select * from table where id>5) {
   say $_.id ~ ' -> ' $_.value;

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?

Bye,
   Andras

That's somewhat ambiguous with our current qw// notoation.

: > 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.

: 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?

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.

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>;
    $a=`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.

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
macros were term:<`\<> and term:<`select>, then any unrecognized
`...` could still default to qx//.  Of course, then you'd have to be
careful about things like:

    $meow = `</dev/tty cat`;

We've also proposed reserving ` for introducing units, but that would
be where an operator is expected, not a term, so it doesn't conflict
with term usages unless you also want to use those terms as subscripts.
In other words, Juerd could overload postfix:<`> to do %hash`foo if he
still wants to do that, but then he couldn't also use ` to mark units.

Larry

The question is what will be clear to the reader of the code.

: >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.

I was classifying XML as "fad".  :-)

: >    $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 `.

I think that would be relatively easy to unlearn.

: 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. :)

Sure, just not in Standard Perl 6, which lasts no longer than down
to the first "use".

: >    $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 think something like that is a lot more readable than the "dangling"
sql syntax.

: >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. ;)

It can do it easily.  Just not by default.  :-)

: >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.

Details, details...  Now where did I put my spare bikeshed...  :-)

Larry

--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

That's certainly doable, for some value of certainly.  But see below.

: Or someone could write a module for P6SQL ? (Pardon me for not remembering
: exactly how HEREDOCs work in P6)
:
:       p6sql_query "SQLPROC">>
:
:       $result = SELECT * FROM table
:       FOREACH ROW IN $result AS $field
:               SAY $field.id " -> " $field.value
:       END FOREACH
:
:       SQLPROC
:
: Or maybe I'm getting a bit too crazy.

Heredocs are variants on q:to<SQLPROC> these days, but if you're going
to be mixing Perl and SQL syntax, it's probably better to dispense
with the heredoc and just have a language variant so that you can
parse it at compile time.  A heredoc would tend to delay your parse
till run-time, and you'd still have to mix up your parsers somehow.
I don't offhand see a good reason for delaying your parse till run
time, and I can see good reasons for wanting to make your SQL visible
to some optimizer or other at compile time.  (You can certainly parse
at compile time and delay various bindings till run time, so that's not
what is at issue here.)

Larry

Maybe other abstraction would be possible, too.

What about this (I'm not really sure, if it's ok):

INSERT INTO table (col1, col2) VALUES %row;

And it will be:

INSERT INTO table (col1, col2) VALUES (?,?)

   and

%row.col1, %row.col2 will be insert as values.

Bye,
   Andras

    for sql 'SELECT * FROM table WHERE id=$id' { ... }

Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html

Michele
--
I agree with Tore; it's sort of a Zen question.
    If you have to ask, it means you won't understand the answer.
    If you know enough to understand the answer, you won't need the question.
- Joe Smith in clpmisc, "Re: Perl neq Python"