In a message dated Thu, 31 Aug 2006, Juerd writes:
Hm. I don't know how "but" works exactly, but in the realm of syntactic
sugar, this is appealing:
$foo but s/foo/bar/
I like it.
This should be easy to make work in theory, but for the problem with
C's semantics which I'll get to in a mom
Luke Palmer skribis 2006-08-31 15:48 (-0600):
> > I don't think using a method (even if called "s") is good huffman
> > coding. My expectation is that copying substitution will be used much -
> > perhaps even more than mutating substitution!
> And so a method called "s" is poor huffman coding... wh
Michael Snoyman skribis 2006-08-31 15:13 (-0700):
> > :g
> That said, I think to a certain extend it *is* a modifier on the match.
> It's saying "match bar globally," and then subst says "everything that the
> regex matched should be replaced by baz." I think that's a pretty intuitive
> way of han
Jonathan Lang skribis 2006-08-31 15:35 (-0700):
> IIRC, :g is an adverb, and adverbs are merely syntactic sugar for
> named parameters. So perhaps the signature for the substitution
> method should include a slurpy hash of modifiers...
In which case you'd end up parsing the keys, because we have
Trey Harris skribis 2006-09-01 0:17 (-0700):
> I think these semantics are Almost Right, but yet Entirely Wrong. The
> problem is that C reads to me as a *mutating* operator. That is, I
> would expect the above code snippet to give me a C<$z.y> of 17, but leave
> C<$p.y> as 0. Surely this is
In a message dated Fri, 1 Sep 2006, Juerd writes:
Trey Harris skribis 2006-09-01 0:17 (-0700):
I think these semantics are Almost Right, but yet Entirely Wrong. The
problem is that C reads to me as a *mutating* operator. That is, I
would expect the above code snippet to give me a C<$z.y> of
What is the behaviour of an *uncaught* exception, particularly with
respect to CHECK/END/LEAVE/LAST blocks, destructors, overloading of
the stringify operator on exception objects, the order in which these
things are executed, and the exit code of the process? (And anything
else that I haven't thou
2006/9/1, Juerd <[EMAIL PROTECTED]>:
Luke Palmer skribis 2006-08-31 15:48 (-0600):
> > I don't think using a method (even if called "s") is good huffman
> > coding. My expectation is that copying substitution will be used much -
> > perhaps even more than mutating substitution!
> And so a method
Author: larry
Date: Fri Sep 1 09:14:33 2006
New Revision: 11653
Modified:
doc/trunk/design/syn/S04.pod
Log:
Clarified that do-block takes no statement modifiers.
Modified: doc/trunk/design/syn/S04.pod
==
--- doc/tru
On Wed, Aug 30, 2006 at 01:37:33PM +0800, Agent Zhang wrote:
: Hi, there~
:
: I think S04 says too little about statement modifiers. Please comment
: on the following code samples. Are they valid Perl 6?
:
:do { say } for 1..3;
The do-BLOCK construct does not allow statement modifiers.
:
I'm not sure if I have seen this requested or discussed.
Is there a parsing reason why Perl 6 would allow nested statement modifiers or
is it mainly a sanity-please-don't-hurt-my-eyes reason.
It is silly to do things such as:
say "Interesting" if $just_because if $because;
But it is sort of us
In a message dated Fri, 1 Sep 2006, Paul Seamons writes:
I'm not sure if I have seen this requested or discussed.
This was definitively rejected by Larry in 2002:
http://www.nntp.perl.org/group/perl.perl6.language/9343
He has not revisited the issue in the several times it has come up since.
On 9/1/06, Trey Harris <[EMAIL PROTECTED]> wrote:
In a message dated Fri, 1 Sep 2006, Paul Seamons writes:
> I'm not sure if I have seen this requested or discussed.
This was definitively rejected by Larry in 2002:
http://www.nntp.perl.org/group/perl.perl6.language/9343
He has not revisited t
In a message dated Fri, 1 Sep 2006, jerry gay writes:
On 9/1/06, Trey Harris <[EMAIL PROTECTED]> wrote:
In a message dated Fri, 1 Sep 2006, Paul Seamons writes:
> I'm not sure if I have seen this requested or discussed.
This was definitively rejected by Larry in 2002:
http://www.nntp.perl.or
> This was definitively rejected by Larry in 2002:
Yes. That is good to see and I do think I remember seeing that or some similar
postings come to think of it. Thank you for shaking my memory.
Now it is 2006. Object syntax has changed. Little bits and pieces (and
sometimes larger chunks) of
Paul Seamons schreef:
> The following is one more interesting case.
>
> say "Ok then" if $yes and $true unless $no or $false;
>
> Without nested modifiers you'd have either:
>
> say "Ok then" if $yes and $true and ! $no and ! $false;
>
> or
>
> say "OK then" unless ! $yes or ! $true or $no $or $fa
> $no or $false or $yes and $true and say "OK then" ;
>
> $no or $false or say "OK then" if $yes and $true ;
Thank you for your reply.
I know there are other ways to do it. I've had no choice but to do it other
ways in Perl5.
I don't think I have ever used that notation (outside of file open a
On Tuesday 29 August 2006 13:26, Jonathan Lang wrote:
> Perl6 handles both object-orientation (through inheritance) and
> role-playing (through composition).
What exactly does inheritance have to do with object orientation, except that
some OO systems support inheritance? Plenty of OO systems g
In reading about symbolic references, I didn't find any specific
language that mentioned using them in conjunction with methods or OO. I
would like to see specific language and examples added to the spec to
clarify this.
Here's a specific example which currently doesn't work in pugs.
It's attempti
19 matches
Mail list logo