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
Cbut's semantics which I'll get to in a
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... why? (I do
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 handling the
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 Cbut 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 Cbut reads to me as a *mutating* operator. That is, I
would expect the above code snippet to give me a C$z.y
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
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 called s
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
==
---
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
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
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 the
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:
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 $false;
And
$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 and
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
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
19 matches
Mail list logo
