On Sat, 30 Sep 2000 00:57:47 +0100, Hugo wrote:
>:"local" inside embedded code will no longer be supported, nor will
>:consitional regexes. The Perl5 -> Perl6 translator should warn if it
>:ever encounters one of these.
>
>I'm not convinced that removing either of these are necessary to the
>main thrust of the proposal. They may both still be useful in their
>own right, and you seem to offer little evidence against them other
>than that you don't like them.
"local" promotes the idea of semi-permanently changes global data. That
is a very coding practice, it shouldn't be encouraged. The fact that
it's pretty hard to predict precisely when embedded code will be called
(see the example in the RFC), that too, conflicts with this.
It most definitely doesn't fit into the spirit of assertions.
There's an RFC requesting that *all* of these advanced features should
go. There's no justification there, either. I'm limiting myself here to
mentioning the features I do no consider essential for assertions to be
useful. It doesn't need local. Is that good enough for you? You may keep
it if you wish, but it is not essential.
And I do think that the semantics of "local" don't fit well into the
rest of Perl. Clearly, in
(?{local $c = $c+1 })
the scope of $c should be limited to this embedded code block!?!
>I do like the idea of making (?{...}) an assertion, all the more
>because we have a simple migration path that avoids unnecessarily
>breaking existing scripts: wrap $code as '$^R = do { $code }; 1'.
Good. :-)
>If you want to remove support for 'local' in embedded code, it is
>worth a full proposal in its own right that will explain what will
>happen if people try to do that. (I think it will make perl
>unnecessarily more complex to detect and disable it in this case.)
Quite the contrary, I think. My guess is that this support for loacl
*complicates* implementation, and probably by a substantial amount.
>Similarly if you want to remove support for (?(...)) completely,
>you need to address the utility and options for migration for all
>the available uses of it, not just the one addressed by the new
>handling of (?{...}).
You're talking about conditional regexes? I am curious to see just *one*
good reason to keep them in. I've not yet seen anything using a regex
that makes use of it (appart from Perl5's embedded code assertions),
that can't be done without it. Anybody is free to prove me wrong.
--
Bart.
