Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

[svn:perl6-synopsis] r12875 - doc/trunk/design/syn

5 views
Skip to first unread message

la...@cvs.perl.org

unread,
Oct 9, 2006, 3:22:28 AM10/9/06
to perl6-l...@perl.org
Author: larry
Date: Mon Oct 9 00:22:24 2006
New Revision: 12875

Modified:
doc/trunk/design/syn/S05.pod

Log:
P5's s[pat][repl] syntax is dead, now use s[pat] = "repl"


Modified: doc/trunk/design/syn/S05.pod
==============================================================================
--- doc/trunk/design/syn/S05.pod (original)
+++ doc/trunk/design/syn/S05.pod Mon Oct 9 00:22:24 2006
@@ -14,9 +14,9 @@
Maintainer: Patrick Michaud <pmic...@pobox.com> and
Larry Wall <la...@wall.org>
Date: 24 Jun 2002
- Last Modified: 4 Oct 2006
+ Last Modified: 8 Oct 2006
Number: 5
- Version: 35
+ Version: 36

This document summarizes Apocalypse 5, which is about the new regex
syntax. We now try to call them I<regex> rather than "regular
@@ -88,10 +88,18 @@

s/pattern/{ doit() }/

+or:
+
+ s[pattern] = doit()
+
Instead of C</ee> say:

s/pattern/{ eval doit() }/

+or:
+
+ s[pattern] = eval doit()
+
=item *

Modifiers are now placed as adverbs at the I<start> of a match/substitution:
@@ -2876,15 +2884,71 @@
the longest one wins. In the case of two identical sequences the
first in order wins.

+=back
+
+=head1 Substitution
+
There are also method forms of C<m//> and C<s///>:

- $str.match(//);
- $str.subst(//, "replacement");
- $str.subst(//, {"replacement"});
- $str.=subst(//, "replacement");
- $str.=subst(//, {"replacement"});
+ $str.match(/pat/);
+ $str.subst(/pat/, "replacement");
+ $str.subst(/pat/, {"replacement"});
+ $str.=subst(/pat/, "replacement");
+ $str.=subst(/pat/, {"replacement"});

-=back
+There is no syntactic sugar here, so in order to get deferred
+evaluation of the replacement you must put it into a closure. The
+syntactic sugar is provided only by the quotelike forms. First there
+is the standard "triple quote" form:
+
+ s/pattern/replacement/
+
+Only non-bracket characters may be used for the "triple quote". The
+right side is always evaluated as if it were a double-quoted string
+regardless of the quote chosen.
+
+As with Perl 5, a bracketing form is also supported, but unlike Perl 5,
+Perl 6 uses the brackets I<only> around the pattern. The replacement
+is then specified as if it were an ordinary item assignment, with ordinary
+quoting rules. To pick your own quotes on the right just use one of the C<q>
+forms. The substitution above is equivalent to:
+
+ s[pattern] = "replacement"
+
+or
+
+ s[pattern] = qq[replacement]
+
+This is not a normal assigment, since the right side is evaluated each
+time the substitution matches (much like the pseudo-assignment to declarators
+can happen at strange times). It is therefore treated as a "thunk", that is,
+as if it has implicit curlies around it. In fact, it makes no sense at
+all to say
+
+ s[pattern] = { doit }
+
+because that would try to substitute a closure into the string.
+
+Any scalar assignment operator may be used; the substitution macro
+knows how to turn
+
+ $target ~~ s:g [pattern] op= expr
+
+into something like:
+
+ $target.subst(rx:g [pattern], { $() op expr })
+
+So, for example, you can multiply every dollar amount by 2 with:
+
+ s:g [\$ <( \d+ )>] *= 2
+
+(Of course, the optimizer is free to do something faster than an actual
+method call.)
+
+You'll note from the last example that substitutions only happen on
+the "official" string result of the match, that is, the C<$()> value.
+(Here we captured C<$()> using the C<< <(...)> >> pair; otherwise we
+would have had to use lookbehind to match the C<$>.)

=head1 Positional matching, fixed width types

Juerd

unread,
Oct 10, 2006, 4:49:11 PM10/10/06
to perl6-l...@perl.org
la...@cvs.perl.org skribis 2006-10-09 0:22 (-0700):

> P5's s[pat][repl] syntax is dead, now use s[pat] = "repl"

Why keep the s?

substr works perfectly as both rvalue and lvalue, and I think m[], also
known as //, can do the same. No need to do things based on delimiter
(bracket versus non-bracket), then.

> + s[pattern] = doit()

m[pattern] = doit();
/pattern/ = doit();

> + $str.subst(/pat/, "replacement");
> + $str.subst(/pat/, {"replacement"});
> + $str.=subst(/pat/, "replacement");
> + $str.=subst(/pat/, {"replacement"});

Hmmm... I have no answer for the non-mutating version, but:

$str.match(/pat/) = "replacement";
$str.m(/pat) = "replacement";

> +This is not a normal assigment, since the right side is evaluated each
> +time the substitution matches

Can't this be generalized somehow? Return an lvalue proxy, like substr
does, and make thunking the default for certain LHS types.

I don't like special syntax that looks like normal syntax.
--
korajn salutojn,

juerd waalboer: perl hacker <ju...@juerd.nl> <http://juerd.nl/sig>
convolution: ict solutions and consultancy <sa...@convolution.nl>

Ik vertrouw stemcomputers niet.
Zie <http://www.wijvertrouwenstemcomputersniet.nl/>.

Larry Wall

unread,
Oct 10, 2006, 5:17:50 PM10/10/06
to perl6-l...@perl.org
On Tue, Oct 10, 2006 at 10:49:11PM +0200, Juerd wrote:
: la...@cvs.perl.org skribis 2006-10-09 0:22 (-0700):

: > P5's s[pat][repl] syntax is dead, now use s[pat] = "repl"
:
: Why keep the s?

Because @Larry felt it was better to keep the intent out in front.

: substr works perfectly as both rvalue and lvalue, and I think m[], also


: known as //, can do the same. No need to do things based on delimiter
: (bracket versus non-bracket), then.
:
: > + s[pattern] = doit()
:
: m[pattern] = doit();
: /pattern/ = doit();

We thought about that, but the intent is obscured.

: > + $str.subst(/pat/, "replacement");


: > + $str.subst(/pat/, {"replacement"});
: > + $str.=subst(/pat/, "replacement");
: > + $str.=subst(/pat/, {"replacement"});
:
: Hmmm... I have no answer for the non-mutating version, but:
:
: $str.match(/pat/) = "replacement";
: $str.m(/pat) = "replacement";

And I even predicted somewhere that someone would immediately ask for
a method form of pseudo-assignment. But macros and dynamic dispatch
don't mix well, and I think if you really want the macro it's just
about as easy to write:

$str ~~ s(/pat) = "replacement";

: > +This is not a normal assigment, since the right side is evaluated each
: > +time the substitution matches
:
: Can't this be generalized somehow? Return an lvalue proxy, like substr
: does, and make thunking the default for certain LHS types.

Well, I'm not sure I like that much hidden run-time apparatus, and it doesn't
solve the basic macroish problem that the replacement has to be a lazy thunk.

: I don't like special syntax that looks like normal syntax.

Then by all means also avoid these:

has $.answer = 42;
state $s = 0;

:-)

Larry

Larry Wall

unread,
Oct 10, 2006, 5:25:16 PM10/10/06
to perl6-l...@perl.org
On Tue, Oct 10, 2006 at 02:17:50PM -0700, Larry Wall wrote:
: $str ~~ s(/pat) = "replacement";

Er, cut-n-paste error. Make that:

$str ~~ s[pat] = "replacement";

Larry

Aaron Sherman

unread,
Oct 11, 2006, 10:32:13 AM10/11/06
to perl6-l...@perl.org
@larry[0] wrote:

> Log:
> P5's s[pat][repl] syntax is dead, now use s[pat] = "repl"

Wow, I really missed this one! That's a pretty big thing to get my head
around. Are embedded closures in the string handled correctly so that:

s:g[\W] = qq{\\{$/}};

Will do what I seem to be expecting it will?

How will that be defined in the Perl6-based parser? Will macros be able
to act as an LVALUE and modify their RVALUE in this way, or is this just
some unholy magic in the parser?

> + s[pattern] = doit()

> + s[pattern] = eval doit()

[...]


> +There is no syntactic sugar here, so in order to get deferred
> +evaluation of the replacement you must put it into a closure. The
> +syntactic sugar is provided only by the quotelike forms.

[...]


> +This is not a normal assigment, since the right side is evaluated each
> +time the substitution matches (much like the pseudo-assignment to declarators
> +can happen at strange times). It is therefore treated as a "thunk", that is,
> +as if it has implicit curlies around it. In fact, it makes no sense at
> +all to say
> +
> + s[pattern] = { doit }

Please clarify "quotelike forms", since to my untrained eye, the above
appeared to be contradictory at first (I read "quotelike forms" as s///
not s{...}).

Very interesting.

Larry Wall

unread,
Oct 11, 2006, 10:52:48 AM10/11/06
to perl6-l...@perl.org
On Wed, Oct 11, 2006 at 10:32:13AM -0400, Aaron Sherman wrote:
: @larry[0] wrote:
:
: >Log:
: >P5's s[pat][repl] syntax is dead, now use s[pat] = "repl"
:
: Wow, I really missed this one! That's a pretty big thing to get my head
: around. Are embedded closures in the string handled correctly so that:
:
: s:g[\W] = qq{\\{$/}};
:
: Will do what I seem to be expecting it will?

Yes, the right side is implicitly closurized and evaluated repeatedly
by the left side.

: How will that be defined in the Perl6-based parser? Will macros be able

: to act as an LVALUE and modify their RVALUE in this way, or is this just
: some unholy magic in the parser?

This is just a macro with a fancy "is parsed" rule, I think. It eats the =
in complete disregard for precedence. Nothing much to generalize, I think.

: >+ s[pattern] = doit()


: >+ s[pattern] = eval doit()
: [...]
: >+There is no syntactic sugar here, so in order to get deferred
: >+evaluation of the replacement you must put it into a closure. The
: >+syntactic sugar is provided only by the quotelike forms.
: [...]
: >+This is not a normal assigment, since the right side is evaluated each
: >+time the substitution matches (much like the pseudo-assignment to
: >declarators
: >+can happen at strange times). It is therefore treated as a "thunk", that
: >is,
: >+as if it has implicit curlies around it. In fact, it makes no sense at
: >+all to say
: >+
: >+ s[pattern] = { doit }
:
: Please clarify "quotelike forms", since to my untrained eye, the above
: appeared to be contradictory at first (I read "quotelike forms" as s///
: not s{...}).

s{...} is also a quotelike form. Basically I mean anything where
you get to choose your own quote characters, whether or not they are
brackets.

: Very interesting.

Yeah, we whacked on possible syntaxes a goodly long time on IRC the
other night. Trying to balance out history and visuals and semantics
and failure modes was all quite interesting, but in the absence of
more Unicode keys on the keyboard I'm liking this notation pretty
well, particularly since we've already used pseudo assignment in
other places to thunkize the right side.

Larry

0 new messages