Front page | perl.perl5.porters |
Postings from May 2012
On Tue, May 15, 2012 at 05:29:43PM -0500, Jesse Luehrs wrote: > On Tue, May 15, 2012 at 05:59:22PM -0400, Eric Brine wrote: > > On Tue, May 15, 2012 at 4:55 PM, Jesse Luehrs <doy@tozt.net> wrote: > > > > > Okay, now I'm confused. What are you actually asking? Are you referring > > > to some potential future try/catch keyword that may be added to the > > > language in the future? > > > > > > No. Some try/catch keyword that can be added by anyone, today or even > > yesterday. > > Okay, this is where I was confused then. > > > > If you are, my position is that all of the > > > arguments I've been making about 'else' apply equally well to 'catch' > > > > and they should be treated the same (i.e., not overridable via the > > > keyword plugin mechanism). > > > > > > Well, that's what I thought you meant, but it makes no sense. Since I could > > have used any word instead of catch, it applies to every word. It makes no > > sense to prevent all keywords from being overridden by the keyword plugin. > > > > I believe the keyword plugin should not override "else" **immediately after > > an if/elsif block**. More generally, I believe the keyword plugin should > > not be called anywhere but where an expression is expected. > > > > > > FC: > > I'm ok with making C<else> and C<continue> reserved words to avoid the > > ambiguous message. Whoever might write try-catch can make C<catch> a > > reserved word too if they so desire, so consistency is still possible. > > Yes, I agree with all this (including making 'else' and 'continue' > reserved words). Actually, I'm less sure about 'continue', considering it's use as a flow control operator within given/when. Not entirely sure what should be done about that case (reusing keywords for radically different things makes parsing pretty annoying). -doyThread Previous | Thread Next