Trey Harris wrote:
>> sub repeat is multi ($desc is valued(1), &body) {
>> body(1);
>> }
>>
>> sub repeat is multi ($desc is valued(0), &body) {
>> }
>>
>> sub repeat is multi ($desc is valued(['A'..'F']), &body) {
>> die "Can't repeat hexadecimally";
In a message dated Thu, 29 Aug 2002, Damian Conway writes:
> And, of course, the C property would smart-match its value
> against the corrresponding argument, so one could also code optimized
> variants like:
>
> sub repeat is multi ($desc is valued(1), &body) {
> body(1);
>
Larry Wall wrote:
>
> : In summary: assuming Perl 6 allows user-defined while-ish structures, how
> : would it be done?
>
> I think the secret is to allow easy attachment of regex rules to sub
> and parameter declarations. There's little point in re-inventing
> regex syntax using declarations.
Larry wrote:
> sub while (&test is rx//, &body);
>
> or some such. That probably isn't sufficient to pick out of Perl's
> grammar rather than the current lexical scope.
I love the idea, but the property name needs to be more expressive
(and Huffmanly longer). Maybe:
sub while (
On Thu, 29 Aug 2002, Thomas A. Boyer wrote:
: Am I getting this straight?
As straight as any of us are getting it thus far. :-)
The process is intended to be convergent. That doesn't guarantee it
will converge, but that's the intention.
When I'm playing golf, I always expect to knock the ball
On Wed, 28 Aug 2002, Sean O'Rourke wrote:
: Being able to specify fixed arguments after a splat looks illegal, or at
: least immoral. It opens the door to backtracking in argument parsing,
: e.g.:
:
: sub foo (*@args, &func, *@more_args, $arg, &func) { ... }
:
: > Saying specifically a list
On Wed, 28 Aug 2002, Luke Palmer wrote:
> > Second, is there a prototype-way to specify the arguments to "for"
> > (specifically, the first un-parentesized multidimensional array argument)?
> > In other words, is that kind of signature expected to be used often enough
> > to justify not forcing p
> Second, is there a prototype-way to specify the arguments to "for"
> (specifically, the first un-parentesized multidimensional array argument)?
> In other words, is that kind of signature expected to be used often enough
> to justify not forcing people to explicitly extend the grammar?
If you'r
On Wed, 28 Aug 2002, Damian Conway wrote:
> Any subroutine/function like C that has a signature (parameter list)
> that ends in a C<&sub> argument can be parsed without the trailing
> semicolon. So C's signature is:
>
> sub if (bool $condition, &block);
>
> So the trailing semicolon isn't re
On Wed, 28 Aug 2002, Thom Boyer wrote:
: Damian Conway wrote:
: > Any subroutine/function like C that has a signature (parameter list)
: > that ends in a C<&sub> argument can be parsed without the trailing
: > semicolon. So C's signature is:
: >
: > sub if (bool $condition, &block);
:
:
Thom Boyer [mailto:[EMAIL PROTECTED]] wrote:
> sub while (bool $test, &body);
> sub while (&test, &body);
>
> But neither of these really works.
>
> The first would imply that the test is evaluated only once
> (and that once is
> before 'sub while' is even called). That'd be useles
Damian Conway wrote:
> Any subroutine/function like C that has a signature (parameter list)
> that ends in a C<&sub> argument can be parsed without the trailing
> semicolon. So C's signature is:
>
> sub if (bool $condition, &block);
So what does the signature for C look like? I've been w
Sean O'Rourke wrote:
> I hope this is wrong, because if not, it breaks this:
>
> if 1 { do something }
> foo $x;
>
> in weird ways. Namely, it gets parsed as:
>
> if(1, sub { do something }, foo($x));
>
> which comes out as "wrong number of arguments to `if'", which is just
> str
In a message dated Tue, 27 Aug 2002, Luke Palmer writes:
> No, it's right. But it doesn't break that. In the grammar, C-like
> languages include (something like):
>
> statement: expression ';'
> statement: if expression block
>
> So an if _statement_ terminates itself. The } on a line
On Tue, 27 Aug 2002, Luke Palmer wrote:
> No, it's right. But it doesn't break that. In the grammar, C-like
> languages include (something like):
>
> statement: expression ';'
> statement: if expression block
>
> So an if _statement_ terminates itself. The } on a line of its own is a
On Tue, 27 Aug 2002, Sean O'Rourke wrote:
> On Tue, 27 Aug 2002, Luke Palmer wrote:
> > On 27 Aug 2002, Piers Cawley wrote:
> > > Damian Conway <[EMAIL PROTECTED]> writes:
> > > > Debbie Pickett asked:
> > > > > (Offtopic: can I say:
> > > > > $c = -> $xyz { mumble }
> > > >
> > > > Yes. Though
On Tue, 27 Aug 2002, Luke Palmer wrote:
> On 27 Aug 2002, Piers Cawley wrote:
> > Damian Conway <[EMAIL PROTECTED]> writes:
> > > Debbie Pickett asked:
> > > > (Offtopic: can I say:
> > > > $c = -> $xyz { mumble }
> > >
> > > Yes. Though you need a semicolon at the end unless its the last
> > >
On 27 Aug 2002, Piers Cawley wrote:
> Damian Conway <[EMAIL PROTECTED]> writes:
> > Debbie Pickett asked:
> > > (Offtopic: can I say:
> > > $c = -> $xyz { mumble }
> >
> > Yes. Though you need a semicolon at the end unless its the last
> > statement in a block.
>
> Um... when did that rule co
On Mon, 26 Aug 2002, Glenn Linderman wrote:
: Damian Conway wrote:
: > For an C without modifiers, (...) are certainly unambiguous as delimiters.
: > So I think they should be allowed. Of course, it's Larry's call and he may
: > well prefer the simplicity of a blanket prohibition.
:
: So one thin
On Mon, 26 Aug 2002, Glenn Linderman wrote:
> because the rules and patterns are no longer regular, but if rx isn't a
> short form of regex, what is it a short form of?
It's a short form of "r$x" for some value of "$x" ;).
/s
Glenn Linderman asked:
> So one thing that bothers me in the whole discussion of rule vs rx
> differences and similarities, is that there was a previous discussion
> that said "regular expression" and "regex" should be deprecated terms
> because the rules and patterns are no longer regular, but i
Damian Conway wrote:
> For an C without modifiers, (...) are certainly unambiguous as delimiters.
> So I think they should be allowed. Of course, it's Larry's call and he may
> well prefer the simplicity of a blanket prohibition.
So one thing that bothers me in the whole discussion of rule vs rx
Luke Palmer wrote:
> Hang on... I thought parens weren't allowed as delimiters. Or does that
> not apply to rx()?
Well, yes, we *did* say that in A5 and E5.
But we were thinking of m// and s/// in particular and of patterns with
modifiers (which might take argument lists) in general.
For an
> > The only extra piece of syntactic sugar that C is giving us over
> > C[*] is the ability to have arbitrary delimiters.
>
> Not quite arbitrary. Alphanumerics aren't allowed, nor are colon or
> parens.
Aww, no alphanumerics anymore. That's too bad; it was so nice in poetry
to be able to wri
>>Not quite arbitrary. Alphanumerics aren't allowed, nor are colon or
>>parens.
>
> Of course. I didn't want to poison my entire sentence with footnotes
> for the obvious exceptions.
Yes. It wasn't directed at you particularly, but at those for whom the
exception isn't obvious. The problem bei
> > The only extra piece of syntactic sugar that C is giving us over
> > C[*] is the ability to have arbitrary delimiters.
> Not quite arbitrary. Alphanumerics aren't allowed, nor are colon or
> parens.
Of course. I didn't want to poison my entire sentence with footnotes
for the obvious excepti
Debbie Pickett wrote:
> So . . correct me if I'm wrong . . .
>
> C allows us to define both named and anonymous rules,
Yes.
> depending on context.
Depending on whether or not you provide a name.
> C allows us to define only anonymous rules.
Yes. And they can't take parameter lists.
> C
On Sun, 25 Aug 2002, Glenn Linderman wrote:
> Deborah Ariel Pickett wrote:
>
> > I'm imagining a table something like this:
> >
> > Subroutine Pattern matching
> >
> >
> > Default { c
> Funny you should mention that. This brings up something that I was
> afraid to mention before, lest it be regarded as too weird. There isn't
> any strong syntactic reason for subs to be delimited with just braces either.[*]
> Sure, there's a historical Perl precedent, and I'd probably be force
Deborah Ariel Pickett wrote:
> I'm imagining a table something like this:
>
> Subroutine Pattern matching
>
>
> Default { code } / pattern /
> delimiter
>
> Declare
Note! Some of the following is hypothetical, not strictly based on Apocalypses
and such. Now that your brain is in the right mode:
Uri wrote:
> > "DAP" == Deborah Ariel Pickett <[EMAIL PROTECTED]> writes:
> DAP> C allows us to define both named and anonymous rules, depending on
> DAP> co
> "DAP" == Deborah Ariel Pickett <[EMAIL PROTECTED]> writes:
DAP> C allows us to define both named and anonymous rules, depending on
DAP> context. C allows us to define only anonymous rules. C is
DAP> the more general one, and you can use it exclusively if that's what you
DAP> feel
Damian wrote:
> Debbie Pickett asked:
> > So my question is: why two words for regular expressions, but only one
> > for subroutines? Are "rule" and "rx" just alternate spellings, much as
> > Perl5's "for" and "foreach" are? If so, why the two keywords?
> > If not, why not?
> They are not quite
33 matches
Mail list logo
