Re: embedding languages in Perl 6
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=elemselemContent #1/elemelemContent #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
Re: embedding languages in Perl 6
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=elemselemContent #1/elemelemContent #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 id5) {
: 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=`elemselemContent #1/elemelemContent #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
Re: embedding languages in Perl 6
Hi,
: I'm just wondering, if the following would be possible with Perl 6 or not?
:
: XML
:
: $a=elemselemContent #1/elemelemContent #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 id5) {
: 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=`elemselemContent #1/elemelemContent #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=xmlelemselemContent #1/elemelemContent #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=sqlselect * 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
Re: embedding languages in Perl 6
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=`elemselemContent #1/elemelemContent #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=xmlelemselemContent #1/elemelemContent #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=sqlselect * 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
Fwd: Re: embedding languages in Perl 6
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 [EMAIL PROTECTED]
To: BÁRTHÁZI András [EMAIL PROTECTED]
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 [EMAIL PROTECTED]
wrote:
It would be nicer to say:
$a=xmlelemselemContent #1/elemelemContent #2/elem/elems;
But native xml parsing is better, I think. :)
Anyway, it's possible to write:
$a=sqlselect * 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/
Re: Fwd: Re: embedding languages in Perl 6
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:toSQLPROC 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
Re: Fwd: Re: embedding languages in Perl 6
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
Re: Fwd: Re: embedding languages in Perl 6
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
Re: Fwd: Re: embedding languages in Perl 6
On Wed, 20 Apr 2005 14:13:42 -0400, Larry Wall [EMAIL PROTECTED] wrote:
Heredocs are variants on q:toSQLPROC 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 [EMAIL PROTECTED] 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.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
