> 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
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
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.
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
> [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
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
