Parsing macros (was: Control flow variables)
Larry Wall wrote:
> So far we've only allowed "is parsed" on the macro itself, not on
> individual arguments. Still, that's an interesting idea.
Forgive me if this has already been addressed, but this could have some
useful applications:
So far, everything I've read about macro parsing concentrates on parsing
the positional arguments; I haven't seen anything about how to go about
defining a custom parse rule for the list arguments. In particular, I'm
thinking about something along the lines of:
macro element(name, [EMAIL PROTECTED] is parsed /\s+/)
is parsed / \< /? () \s* (.*?) /? \> /
{...}
where the "is parsed" trait of the list parameter defines a rule used to
split the string fed into it into a list of arguments.
I could see something similar being done for named parameters, but you'd
need to define both a "split" rule and a name-vs-value parse rule, and
you'd have to address if (and if so, how) a named parameter can be
inserted between positional and/or list parameters.
=
Jonathan "Dataweaver" Lang
__
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/
Re: [perl] RE: s/// in string context should return the string
[EMAIL PROTECTED] (Allison Randal) writes: > We talked about this today. Our current thought is to retroactively > write the Synopses and keep those up-to-date (with notes in the outdated > parts of the A's and E's pointing to the relevant section of the > S's). To be honest, I don't care how it's actually done, I just want to avoid having Larry pop up and say "Sheesh, didn't you know X?", where X is something we've never heard of before and contradicts many things he's said publically in the past. -- lathos: nothing can make up for the middle class dinner party couple sex ARSE of Sade
Re: Control flow variables
[EMAIL PROTECTED] (Austin Hastings) writes:
> What does C do?
That's the operator that's used to assign values to C<$^x> and
friends in closures. In all its glory, you give it a set of values,
and it assigns them to a block's undefined variables, quieting those
annoying warnings:
@x = 1..10;
scatter @x {
$the = 1;
$teh + $the * $The
}
# ==> 1 + 1 * 2 = 3
/s
RE: Control flow variables
> -Original Message-
> From: Larry Wall [mailto:[EMAIL PROTECTED]
> On the other hand, putting the default up front is clearer if the
> block is long. Could even be something like:
>
> @foo = gather is default(@results) {
> for @a -> $x { pick $x if mumble($x) }
> }
And C is a better name than C, overall.
What does C do?
=Austin
Re: [perl] RE: s/// in string context should return the string
Simon wrote: > > How should we go about bringing A3 up to match current reality? It is, after > all, over two years old now. We talked about this today. Our current thought is to retroactively write the Synopses and keep those up-to-date (with notes in the outdated parts of the A's and E's pointing to the relevant section of the S's). Allison
Re: Control flow variables
On Wed, Nov 19, 2003 at 09:12:01AM -0600, Jonathan Scott Duff wrote:
: On Tue, Nov 18, 2003 at 09:36:31PM -0800, Larry Wall wrote:
: > As for the original question that started this whole silly thread,
: > control structures that return values should probably be considered
: > some kind of generator, and have an explicit "yield"-like statement
: > that is orthogonal to "last" and such. Such a generator would be
: > explicitly marked, as with "do {...}" above, only different. The
: > inside of such a generator after the loop is the natural place
: > to say what happens if nothing in the loop "works".
:
: I don't understand ... Do you mean something like this?
:
: confer {
: for @a -> $x { ... } || beget @results;
: }
:
: where "confer" is the do-like marker and "beget" is the yield-like
: statement. But why not this?
:
: for @a -> $x { ... } or do { ... }
:
: I need an example.
Sorry, I wasn't being very clear. It wouldn't be logically attached to
the outside of the for, but to the inside of the "confer", or whatever:
@foo = gather {
for @a -> $x { pick $x if mumble($x) }
DEFAULT { @results }
}
In which case you could also write:
@foo = gather {
DEFAULT { @results }
for @a -> $x { pick $x if mumble($x) }
}
But it might be clearer to put it outside:
@foo = gather {
for @a -> $x { pick $x if mumble($x) }
} or @results;
On the other hand, putting the default up front is clearer if the
block is long. Could even be something like:
@foo = gather is default(@results) {
for @a -> $x { pick $x if mumble($x) }
}
Larry
Re: Control flow variables
Gordon Henriksen writes:
> Larry Wall wrote:
>
> > On Tue, Nov 18, 2003 at 06:28:59PM -0500, Gordon Henriksen wrote:
> >
> > > my @b = for @a -> $_ {
> > > ...
> > > }
> >
> > That will be a syntax error. Generators are too mind-stretching to
> > inflict on novices [...]
>
> I making the point that within the context of this we-wish-loops-were-
> expressions discussion, the "for expression" was simply another way
> to spell map, at least when autoiterating an array.
>
> I certainly wasn't thinking in terms of coroutines--they absolutely
> deserve a large syntactic barrier.
I don't think generate{} and yield() were supposed to indicate
coroutines. Instead, it's more like Mathematica's Sow[] and Reap[],
which would work (Perl6-ized) as follows:
@a = reap {
sow 1;
some-other-statement;
sow 2;
} # @a is (1,2)
It's a nice concept; it simplifies certain kinds of list processing
greatly. It would easily be implemented with coroutines, which might
also explain the yield().
Luke
RE: Control flow variables
Larry Wall wrote:
> On Tue, Nov 18, 2003 at 06:28:59PM -0500, Gordon Henriksen wrote:
>
> > my @b = for @a -> $_ {
> > ...
> > }
>
> That will be a syntax error. Generators are too mind-stretching to
> inflict on novices [...]
I making the point that within the context of this we-wish-loops-were-
expressions discussion, the "for expression" was simply another way
to spell map, at least when autoiterating an array.
I certainly wasn't thinking in terms of coroutines--they absolutely
deserve a large syntactic barrier.
> > # (Apologies for the perl5-isms.)
> > for @a -> $_ {
> > push @b: do { ... };
> > }
>
> Hmm? I see no perl5-isms there. Or rather, I see no
> non-perl6-isms...
It's been a while since I read Apocalypses; I wasn't sure if do { }
(still) meant what I meant it to mean ("the result of the last
statement in the block"). There was also a scalar() in there when I
wrote the apology, but I removed it on further consideration of the
equivalence to map {}. :)
--
Gordon Henriksen
IT Manager
ICLUBcentral Inc.
[EMAIL PROTECTED]
Re: [perl] RE: s/// in string context should return the string
On Wed, Nov 19, 2003 at 06:17:33PM +, Simon Cozens wrote: > [EMAIL PROTECTED] (Larry Wall) writes: > > Sigh. There's no =~ operator in Perl 6. > > How should we go about bringing A3 up to match current reality? It is, after > all, over two years old now. Isn't Allison the maintainer? Just prod her with an email or two. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Control flow variables
On Tue, Nov 18, 2003 at 09:36:31PM -0800, Larry Wall wrote:
> As for the original question that started this whole silly thread,
> control structures that return values should probably be considered
> some kind of generator, and have an explicit "yield"-like statement
> that is orthogonal to "last" and such. Such a generator would be
> explicitly marked, as with "do {...}" above, only different. The
> inside of such a generator after the loop is the natural place
> to say what happens if nothing in the loop "works".
I don't understand ... Do you mean something like this?
confer {
for @a -> $x { ... } || beget @results;
}
where "confer" is the do-like marker and "beget" is the yield-like
statement. But why not this?
for @a -> $x { ... } or do { ... }
I need an example.
thanks,
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: Control flow variables
On Wed, Nov 19, 2003 at 09:30:15AM -0700, Luke Palmer wrote:
: Piers Cawley writes:
: > All of which means you can wrap it up in a macro and prove Simon's
: > point about what's syntax and what's CP6AN:
: >
: >macro unless_all( Block &test is parsed //,
: > Block &consequence, [EMAIL PROTECTED] )
: > { my $guard = Object.new;
: >for [EMAIL PROTECTED], $guard
: > -> { when $guard { &consequence() ; last }
: > when &test { last } } }
: >
: > But I've probably got the signature slightly wrong.
So far we've only allowed "is parsed" on the macro itself, not on
individual arguments. Still, that's an interesting idea.
: I think the only thing that's wrong with your signature is that you said
: "macro" instead of "sub". Well, and &test has to be finessed into an
: executable block somehow, but we're not supposed to know how yet.
Hmm, how about statement:unless_all and modifier:unless_all?
: > Higher Order Functions/Methods/Macros are great aren't they?
:
: What a modern thinker! Use a *function* to do a common task? *What*
: are you talking about!? :-)
Well, you mayn't put "is parsed" on a function. Macros have special
rules to enforce lexical scoping of syntax munging, since the syntax
must be known when the call is parsed. A function call can be parsed
without such special knowledge.
Larry
Re: Control flow variables
On Tue, Nov 18, 2003 at 06:28:59PM -0500, Gordon Henriksen wrote:
: Whuh? Tangential at best... The result would be the same as in a
: non-vectorized version, just repeated automatically for you.
:
: my @b = for @a -> $_ {
: ...
: }
That will be a syntax error. Generators are too mind-stretching to
inflict on novices as ordinary syntax. You'll have to say something
explicit like:
my @b = generate {
for @a -> $_ {
yield ...
}
}
It's vaguely possible that "generate" and "do" are the same thing.
It's quite possible that the best name is something else entirely.
But "for" ain't it...
: Should be broadly equivalent to:
:
: my @b = map { ... } @a;
:
: - OR -
:
: # (Apologies for the perl5-isms.)
: for @a -> $_ {
: push @b: do { ... };
: }
Hmm? I see no perl5-isms there. Or rather, I see no non-perl6-isms...
Larry
Re: Control flow variables
On Wed, Nov 19, 2003 at 08:08:49AM +1100, Damian Conway wrote:
: Michael Lazzaro wrote:
:
: >So, just to make sure, these two lines are both valid, but do completely
: >different things:
: >
: >return if $a;
:
: Means:
:
: if ($a) { return }
:
:
: >return if $a { $a }
:
: Means:
:
:if ($a) { return $a } else { return undef }
No, it's a syntax error. You must write
return do { if $a { $a } }
to mean that. At least in my version of Perl 6. AIFIYP.
Sentences are a basic concept in all human languages. I've decided
that it's a bad psychological mistake to overgeneralize phrase-level
syntax to encompass sentence-level syntax. The Perl 6 grammar
will know when it's starting to parse a statement, and will
make distinctions based on that. That implies that any sub/macro
definitions for "if" have to be overloaded on parser state somehow.
We could play "multi" tricks, but I suspect the right solution is
more on the order of how we differentiate prefix:+ from infix:+.
So perhaps statement level "if" is statement:if, while modifier "if"
is modifier:if. Huffman says those should be long anyway.
It may well be that there is a generalization to be made here, but
it's more on the order of foo:bar refers to some grammar rule
or set of rules named foo.
Also, since multi is orthogonal to naming, it'd be possible to define
things such that all variants of "if" and "while" look like this:
multi sub *statement:if (...
multi sub *modifier:if (...
multi sub *statement:while (...
multi sub *modifier:while (...
But that sort of generality would completely screw up the optimizer,
I expect, since multi is an inherently run-time concept. It would
also create a great deal of magical action at a distance. Lexically
scoped macros (or other grammatical mods) are a much better approach
to control structure variation. There might be some room for lexically
scoped multi subs defining control structure, but you'd still probably
take the optimizer hit.
Larry
Re: [perl] RE: s/// in string context should return the string
[EMAIL PROTECTED] (Larry Wall) writes: > Sigh. There's no =~ operator in Perl 6. How should we go about bringing A3 up to match current reality? It is, after all, over two years old now. -- End July 2001 - Alpha release for demonstration at TPC
Re: [perl] RE: s/// in string context should return the string
On Wed, Nov 19, 2003 at 09:03:38AM -0500, Austin Hastings wrote: : : : > -Original Message- : > From: Joe Gottman [mailto:[EMAIL PROTECTED] : > Sent: Tuesday, November 18, 2003 9:58 PM : > To: Perl6 : > Subject: Re: [perl] RE: s/// in string context should return the string : > : > : > - Original Message - : > From: "Austin Hastings" <[EMAIL PROTECTED]> : > To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> : > Sent: Tuesday, November 18, 2003 3:04 PM : > Subject: [perl] RE: s/// in string context should return the string : > : > : > > As a "Bvalue" where possible, so they can cascade and nest. : > : >Excuse me. I know enough C++ to know the difference between an lvalue : > and an rvalue, but what the heck is a BValue? : : Something which could be Bound to another rex. Vis (p5): : : $x =~ s/foo/bar/ =~ s/moo/goo/; : : Might as well make them chainable. Sigh. There's no =~ operator in Perl 6. And it's not at all clear that ~~ should be associative. In fact, it's not at all clear that ~~, a symmetrical operator, should bind to any kind of mutator (using the term loosely). Operations that have side effects are inherently asymmetrical and should probably be bound with . in any event. And that does associate left to right, though there are no guarantees that the returned value of a method is the left one. The only mutator operator that currently does that is "but". So maybe it could be something like: $x but s/foo/bar/ but s/moo/goo/; We'd have to make "property" context recognize mutators for that to work, though. I'm more inclined to make $x.s/foo/bar/.s/moo/goo/; work somehow. Basically .s would be a postfix quote macro, or some such. I'm not sure I want to propose macromethods just yet. The compile-time vs run-time typing and scoping issues would be hairy. Having said all that about ~~ vs mutators, I note two interesting facts-in-waiting: 1) The ~~ operator likes to match using regexes. 2) We've defined any regex to be a potential mutator if it uses . Ah, consistency... Larry
Re: Control flow variables
Piers Cawley writes:
> All of which means you can wrap it up in a macro and prove Simon's
> point about what's syntax and what's CP6AN:
>
>macro unless_all( Block &test is parsed //,
> Block &consequence, [EMAIL PROTECTED] )
> { my $guard = Object.new;
>for [EMAIL PROTECTED], $guard
> -> { when $guard { &consequence() ; last }
> when &test { last } } }
>
> But I've probably got the signature slightly wrong.
I think the only thing that's wrong with your signature is that you said
"macro" instead of "sub". Well, and &test has to be finessed into an
executable block somehow, but we're not supposed to know how yet.
> Higher Order Functions/Methods/Macros are great aren't they?
What a modern thinker! Use a *function* to do a common task? *What*
are you talking about!? :-)
Luke
Re: Control flow variables
Jonathan Scott Duff writes:
> On Tue, Nov 18, 2003 at 11:37:22PM +0100, Seiler Thomas wrote:
> > So... lets call a function instead:
> >
> > my $is_ok = 1;
> > for 0..6 -> $t {
> > if abs(@new[$t] - @new[$t+1]) > 3 {
> > $is_ok = 0;
> > last;
> > }
> > }
> > if $is_ok {
> > yada() # has sideeffects...
> > }
>
> my $t = 0..6;
> yada() if none(abs(@new[$t] ^- @new[$t+1])) > 3;
>
> :-P
Ghod I love junctions. :-)
Luke
> -Scott
> --
> Jonathan Scott Duff
> [EMAIL PROTECTED]
Re: Control flow variables
> "Randal" == Randal L Schwartz <[EMAIL PROTECTED]> writes: Randal> I actually consider that an annoying statement. I have to back up Randal> three times to figure out what it means. And before someone whips out the Schwartzian Transform to undermine my statement... please note that in Perl6, you'll be able to write that left to right, which I consider a wonderful plus. :) -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <[EMAIL PROTECTED]> http://www.stonehenge.com/merlyn/> Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: Control flow variables
> "Austin" == Austin Hastings <[EMAIL PROTECTED]> writes: Austin> This is surprising. Perl has never failed to provide me with Austin> an adequacy of rope in other places. Why get squeamish in this Austin> instance? The rope in other places provides overwhelming positive benefits as well, I gather. Everything is a tradeoff. Austin> Hmm. While I don't really expect to see leap year code written Austin> using nested modifiers, I think it would be nice to have each Austin> of them appear once: Austin> print for @a if $debug; I actually consider that an annoying statement. I have to back up three times to figure out what it means. I think Larry was on the right track here. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <[EMAIL PROTECTED]> http://www.stonehenge.com/merlyn/> Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
RE: Control flow variables
> -Original Message-
> From: Randal L. Schwartz [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, November 19, 2003 9:46 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Control flow variables
>
>
> > "Smylers" == Smylers <[EMAIL PROTECTED]> writes:
>
> Smylers> I also was under the strong impression that Larry had decreed
> Smylers> that we wouldn't have chained statement modifiers ... but I
> Smylers> thought it was because Larry had decided they would be a bad
> Smylers> thing to have rather than because they aren't feasible.
>
> They weren't chained in Perl5, very deliberately.
>
> Larry added modifiers partially to get "do { } while $cond" to work,
> and partially because he had used them in RSTS/E BASIC (which I've
> also used, and recognized immediately). But when people started
> nesting them, the code became incredibly unreadable quickly, so
> no-nesting for Perl was a deliberate choice, not an implementation
> detail.
This is surprising. Perl has never failed to provide me with an adequacy of
rope in other places. Why get squeamish in this instance?
> Unless Larry has come up with an overwhelming reason to permit them
> after years of not having them, I doubt we'd see that (IMHO mistake)
> in Perl6.
Hmm. While I don't really expect to see leap year code written using nested
modifiers, I think it would be nice to have each of them appear once:
print for @a if $debug;
=Austin
Re: Control flow variables
> "Smylers" == Smylers <[EMAIL PROTECTED]> writes:
Smylers> I also was under the strong impression that Larry had decreed
Smylers> that we wouldn't have chained statement modifiers ... but I
Smylers> thought it was because Larry had decided they would be a bad
Smylers> thing to have rather than because they aren't feasible.
They weren't chained in Perl5, very deliberately.
Larry added modifiers partially to get "do { } while $cond" to work,
and partially because he had used them in RSTS/E BASIC (which I've
also used, and recognized immediately). But when people started
nesting them, the code became incredibly unreadable quickly, so
no-nesting for Perl was a deliberate choice, not an implementation
detail.
Unless Larry has come up with an overwhelming reason to permit them
after years of not having them, I doubt we'd see that (IMHO mistake)
in Perl6.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[EMAIL PROTECTED]> http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
RE: Control flow variables
> Austin Hastings wrote:
>
> > I'm way not sure about how the vector context result of iteration
> structures
> > will work. Specifically, what happens when a loop forks a thread, or
> passes
> > to a parallelized coroutine? There may not actually BE a result. (Of
> course,
> > in a right-thinking system this will be noted, and replaced by a
> placeholder
> > object that will "wait" for the result if evaluated.)
>
> Whuh? Tangential at best... The result would be the same as in a
> non-vectorized version, just repeated automatically for you.
Would EVENTUALLY be the same as ...
Sure. The whole iterator/generator thing has already been covered, so I'm
pretty sure we've got the underpinnings.
> my @b = for @a -> $_ {
> ...
> }
>
> Should be broadly equivalent to:
>
> my @b = map { ... } @a;
>
> - OR -
>
> # (Apologies for the perl5-isms.)
> for @a -> $_ {
> push @b: do { ... };
> }
Yes. I think I made that point lower down. In fact, the "collector" behavior
of evaluating for in a vector context should help people transition from
C to C. (Only Satan, or his handpicked successor Damian, will help
them get from there to C/C, however. :-)
> If the non-vectorized version has hidden a thread join operation in a
> tied or otherwise magical result value, then so too would the vectorized
> version. But that's a completely orthogonal feature; unrelated and not
> in conflict.
True, but of course the scalar version doesn't have to wait for the results.
=Austin
RE: [perl] RE: s/// in string context should return the string
> -Original Message- > From: Joe Gottman [mailto:[EMAIL PROTECTED] > Sent: Tuesday, November 18, 2003 9:58 PM > To: Perl6 > Subject: Re: [perl] RE: s/// in string context should return the string > > > - Original Message - > From: "Austin Hastings" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> > Sent: Tuesday, November 18, 2003 3:04 PM > Subject: [perl] RE: s/// in string context should return the string > > > > As a "Bvalue" where possible, so they can cascade and nest. > >Excuse me. I know enough C++ to know the difference between an lvalue > and an rvalue, but what the heck is a BValue? Something which could be Bound to another rex. Vis (p5): $x =~ s/foo/bar/ =~ s/moo/goo/; Might as well make them chainable. =Austin
RE: Control flow variables
> Damian Conway wrote:
>
> > push @moves, [$i, $j];
> > for 0..6 -> $t {
> > if abs(@new[$t] - @new[$t+1]) > 3 {
> > pop @moves;
> > last;
> > }
> > }
Thomas Seiler writes:
> my $is_ok = 1;
> for 0..6 -> $t {
> if abs(@new[$t] - @new[$t+1]) > 3 {
> $is_ok = 0;
> last;
> }
> }
> if $is_ok {
> yada() # has sideeffects...
> }
Ironically, this flow control problem was solved many years ago indeed,
and with considerable elegance. To wit:
my $is_ok = 1;
for 0..6 -> $t {
if abs(@new[$t] - @new[$t+1]) > 3 {
goto SKIP_YADA;
}
}
yada();
SKIP_YADA:
Yeah, so I'm a trouble-maker. Sorry: I don't consider downwards,
scope-escaping goto to be harmful.
Does this cause a bit less heartburn?
YADA: {
my $is_ok = 1;
for 0..6 -> $t {
if abs(@new[$t] - @new[$t+1]) > 3 {
break YADA;
}
}
yada();
}
Loop controls are just goto in disguise, anyhow.
--
Gordon Henriksen
IT Manager
ICLUBcentral Inc.
[EMAIL PROTECTED]>
RE: Control flow variables
Austin Hastings wrote:
> I'm way not sure about how the vector context result of iteration
structures
> will work. Specifically, what happens when a loop forks a thread, or
passes
> to a parallelized coroutine? There may not actually BE a result. (Of
course,
> in a right-thinking system this will be noted, and replaced by a
placeholder
> object that will "wait" for the result if evaluated.)
Whuh? Tangential at best... The result would be the same as in a
non-vectorized version, just repeated automatically for you.
my @b = for @a -> $_ {
...
}
Should be broadly equivalent to:
my @b = map { ... } @a;
- OR -
# (Apologies for the perl5-isms.)
for @a -> $_ {
push @b: do { ... };
}
If the non-vectorized version has hidden a thread join operation in a
tied or otherwise magical result value, then so too would the vectorized
version. But that's a completely orthogonal feature; unrelated and not
in conflict.
--
Gordon Henriksen
IT Manager
ICLUBcentral Inc.
[EMAIL PROTECTED]
Re: Control flow variables
On Tue, Nov 18, 2003 at 11:37:22PM +0100, Seiler Thomas wrote:
> So... lets call a function instead:
>
> my $is_ok = 1;
> for 0..6 -> $t {
> if abs(@new[$t] - @new[$t+1]) > 3 {
> $is_ok = 0;
> last;
> }
> }
> if $is_ok {
> yada() # has sideeffects...
> }
my $t = 0..6;
yada() if none(abs(@new[$t] ^- @new[$t+1])) > 3;
:-P
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: Control flow variables
Michael Lazzaro writes: > [EMAIL PROTECTED] (Dan Sugalski) writes: > > > Luke Palmer: > > > > > That's illegal anyway. Can't chain statement modifiers :-) > > > > Will be able to. > > I was under the strong impression that Larry had decided that > syntactic ambiguities prevented this from happening. I also was under the strong impression that Larry had decreed that we wouldn't have chained statement modifiers ... but I thought it was because Larry had decided they would be a bad thing to have rather than because they aren't feasible. > (Now, of course, you will ask me for a cite to the thread, which I > can't even begin to find at this point...) Me neither. A Google Groups search on perl.perl6.language with the author 'Larry' doesn't through up anything relevant for "statement modifiers" or obvious variants. Smylers
RE: Control flow variables
No, because the
if $a
from "return if $a;" doesn't match the production
if [else ]
I so don't want to be anywhere near the Perl6 parser...
--
Gordon Henriksen
IT Manager
ICLUBcentral Inc.
[EMAIL PROTECTED]
> -Original Message-
> From: Michael Lazzaro [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, November 18, 2003 2:06 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Control flow variables
>
>
>
> On Tuesday, November 18, 2003, at 06:38 AM, Simon Cozens wrote:
> > Given that we've introduced the concept of "if" having a
> return status:
> >
> > my $result = if ($a) { $a } else { $b };
> >
>
> Would that then imply that
>
> sub blah {
>... # 1
>return if $a;# 2
>... # 3
> }
>
> ...would return $a if $a was true, and fall through to (3) if it was
> false?
>
>
> > [EMAIL PROTECTED] (Dan Sugalski) writes:
> >>> Luke Palmer:
> That's illegal anyway. Can't chain statement modifiers :-)
> >> Will be able to.
>
> I was under the strong impression that Larry had decided that
> syntactic
> ambiguities prevented this from happening. (Now, of course, you will
> ask me for a cite to the thread, which I can't even begin to find at
> this point...)
>
> MikeL
>
>
Re: Control flow variables
On Tue, Nov 18, 2003 at 11:05:57AM -0800, Michael Lazzaro wrote:
>
> On Tuesday, November 18, 2003, at 06:38 AM, Simon Cozens wrote:
> >Given that we've introduced the concept of "if" having a return status:
> >
> > my $result = if ($a) { $a } else { $b };
> >
>
> Would that then imply that
>
> sub blah {
> ... # 1
> return if $a;# 2
> ... # 3
> }
>
> ...would return $a if $a was true,
That makes no sense. Besides in the above fantasy, the result of the
"if" is the last thing evaluated in the block. In this case, the
block is a single "return" statement. Perhaps it would be clearer
thusly:
my $result = if ($a) { $b } else { $c };# Same as ...
my $result = ($a) ?? $b :: $c; # ?
> and fall through to (3) if it was
> false?
Of course, that's how it works :)
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: [perl] RE: s/// in string context should return the string
"Joe Gottman" <[EMAIL PROTECTED]> writes: > - Original Message - > From: "Austin Hastings" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> > Sent: Tuesday, November 18, 2003 3:04 PM > Subject: [perl] RE: s/// in string context should return the string > > >> As a "Bvalue" where possible, so they can cascade and nest. > >Excuse me. I know enough C++ to know the difference between an lvalue > and an rvalue, but what the heck is a BValue? A mystery to me.
Re: s/// in string context should return the string
Stéphane Payrard <[EMAIL PROTECTED]> writes: > s/// in string context should return the string after substituion. > It seems obvious to me but I mention it because I can't find it > in the apocalypses. Surely it should return the string after substitution, but with an appropriate 'but true' or 'but false' property depending on whether anything was substituted. Though that could have its own problems too.
Re: Control flow variables
Damian Conway <[EMAIL PROTECTED]> writes:
> David Wheeler wrote:
>
>> Isn't that just:
>> for @array_of_random_values_and_types, 'ok' -> $t {
>> when 'ok' { yada(); last }
>> last unless some_sort_of_test($t);
>> }
>> IOW, the topic is only 'ok' when all of the items in the array have
>> been processed
>
> Unless, of course, the string 'ok' is also one of the random_values_and_types.
> Hence my alternative solution.
Or:
my $guard = Object.new;
for @array_of_random_values_and_types, $guard
-> { when $guard { yada(); last }
last unless some_sort_of_test($_) }
If there's some danger of some weird equality thing somehow causing a
problem there, you might need to make a Guard class with a very strict
'=~' implementation, but otherwise I can't see any problem.
Of course, that's better if some_sort_of_test is actually a method,
because then it becomes:
my $guard = class { method some_sort_of_test { yada() }}.new;
for [EMAIL PROTECTED], $guard
-> { last unless .some_sort_of_test }
All of which means you can wrap it up in a macro and prove Simon's
point about what's syntax and what's CP6AN:
macro unless_all( Block &test is parsed //,
Block &consequence, [EMAIL PROTECTED] )
{ my $guard = Object.new;
for [EMAIL PROTECTED], $guard
-> { when $guard { &consequence() ; last }
when &test { last } } }
But I've probably got the signature slightly wrong.
Higher Order Functions/Methods/Macros are great aren't they?
