On 4/20/02 3:02 PM, "Me" <[EMAIL PROTECTED]> claimed:
> banana now red;
> "foo" now false;
> banana now foo;
> banana now tainted;
>
> I read 'now' as somewhat suggestive of changing something.
I actually rather like this keyword. It not only suggests that something has
changed, but tha
> [2c. What about ( data) or (ops data) normally means non-capturing,
> ($2 data) captures into $2, ($foo data) captures into $foo?]
which is cool where being explicit simplifies things, but
ain't where implicit is simpler. So, maybe add an op ('$'?)
or switch that makes parens capturing by d
I agree 'but' seems a tad odd, and I like the elegance of your
suggestion at first sight. However...
> First, but is just strange. I have a thing and I want to tell you it
is
> red, so I say 'but'. Huh?
banana but red;
"foo" but false;
According to Larry, run time properties will most
Let me see if I understand the final version of your (Mike's)
suggestions
and where it appears to be headed:
Backwards compatibility:
perl5 extended syntax still works in perl6 if one happens to use it.
Forward conversion:
Automatic conversion of relevant perl5 regex syntax to perl6 is simple.
Larry,
Please don't use 'but' to associate runtime properties to things.
Please call it 'has'.
First, but is just strange. I have a thing and I want to tell you it is
red, so I say 'but'. Huh?
Using 'has' makes a nice parallel with 'is' for compile time properties:
What you are is determinted
> He then went on to describe something I didn't understand at all.
> Sorry.
Few corrections to what you wrote:
To avoid the problem of extending {} to support new features with a
character 'x', without breaking stuff that might have an 'x' immediately
after the '{', my proposal is to require on
