embedding languages in Perl 6

[BÁRTHÁZI András]

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?

> SQL

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

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?

Bye,
Andras

[Larry Wall]

On Wed, Apr 20, 2005 at 05:08:51PM +0200, BÁRTHÁZI András wrote:
: 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.

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

[Larry Wall]

On Wed, Apr 20, 2005 at 06:57:00PM +0200, BÁRTHÁZI András wrote:
: 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 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

[Matt]

I sent this to BÁRTHÁZI only instead of BÁRTHÁZI and the list as well. So
here's a forward of what I sent and he replied to.

------- Forwarded message -------
From: Matt <ma...@weakmind.org>
To: "BÁRTHÁZI András" <and...@barthazi.hu>
Cc:
Subject: Re: embedding languages in Perl 6
Date: Wed, 20 Apr 2005 13:12:43 -0400

On Wed, 20 Apr 2005 12:57:00 -0400, BÁRTHÁZI András <and...@barthazi.hu>
wrote:

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

> Anyway, it's possible to write:
>
> $a=sql<select * from table>;
>

If not already possible, it would be neat to be able to define your own
quote blocks. Such as being able to define how to parse the below lines:

$result = q:sql/SELECT * FROM table/;

for q:sql/SELECT * FROM table WHERE id=$id/ {
say $_.id ~ ' -> ' ~ $_.value;
}

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.

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

[Matt]

On Wed, 20 Apr 2005 14:13:42 -0400, Larry Wall <la...@wall.org> wrote:
> 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

Good point.

On Wed, 20 Apr 2005 14:14:47 -0400, Juerd <ju...@convolution.nl> wrote:
> What is the benefit of this syntax over having a simple function that
> takes one argument, interpolating variables from CALLER::?
>
> for sql 'SELECT * FROM table WHERE id=$id' { ... }
>
>
> Juerd

You know, you are right. That would work. I just didn't put enough
thought into it, or else I would have realized that the specialized quote
serves no special purpose over a simple function.

[Larry Wall]

On Wed, Apr 20, 2005 at 01:51:11PM -0400, Matt wrote:
: If not already possible, it would be neat to be able to define your own

: quote blocks. Such as being able to define how to parse the below lines:
:
: $result = q:sql/SELECT * FROM table/;
:
: for q:sql/SELECT * FROM table WHERE id=$id/ {
: say $_.id ~ ' -> ' ~ $_.value;

: }

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

[BÁRTHÁZI András]

Hi,

> What is the benefit of this syntax over having a simple function that
> takes one argument, interpolating variables from CALLER::?
>
> for sql 'SELECT * FROM table WHERE id=$id' { ... }

The difference is between compile time parsing and runtime parsing. This
expression can be transformed to a prepare statement plus a call, which
is not just faster, but more safer, if $id contains aposthropes or other
characters.

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

[Juerd]

Matt skribis 2005-04-20 13:51 (-0400):

> If not already possible, it would be neat to be able to define your own
> quote blocks. Such as being able to define how to parse the below lines:

It is possible to create your own sql// if you want it.

> for q:sql/SELECT * FROM table WHERE id=$id/ {
> say $_.id ~ ' -> ' ~ $_.value;
> }

What is the benefit of this syntax over having a simple function that

takes one argument, interpolating variables from CALLER::?

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 Dondi]

On Wed, 20 Apr 2005, [ISO-8859-2] BÁRTHÁZI András wrote:

> 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>;

[snip]

> The ideas coming from Comega, the next version of CSharp(?). Here's an intro
> about it:

Some time ago I asked a somewhat related question that you can find under
the subject "Markup language-like features in Perl6?". It didn't raise
much feedback, though. And I should have expanded on the subject, but
never found the time to do so.

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"