Front page | perl.perl5.porters |
Postings from May 2012
On Tue, May 15, 2012 at 09:42:19AM -0700, Father Chrysostomos via RT wrote:
> On Tue May 15 00:44:43 2012, doy@tozt.net wrote:
> > On Mon, May 14, 2012 at 10:02:58PM -0700, Father Chrysostomos via RT
> wrote:
> > > On Mon May 14 20:53:49 2012, doy@tozt.net wrote:
> > > > On Mon, May 14, 2012 at 08:47:58PM -0700, Father Chrysostomos via RT
> > > wrote:
> > > > > On Mon May 14 18:25:51 2012, doy@tozt.net wrote:
> > > > > > Hmmm, good point. Backtracking isn't really a thing we can
> (easily)
> > > > > > do.
> > > > > > A better idea may be to just disallow elsif and else from being
> > > > > > overridden at all. Why do we need to allow this? (It's not really
> > > > > > quite
> > > > > > parallel to continue, as I mentioned earlier.)
> > > > >
> > > > > We could make else and elsif into exceptions, but the whole point of
> > > > > this proposal was to avoid these types of exceptions.
> > > >
> > > > If the whole point is just to avoid back compat issues with an
> > > > existing problematic misfeature, I don't see the issue with
> handling it
> > > > specially.
> > >
> > > Well, I suppose we could start with that, since we could easily change
> > > it later.
> > >
> > > I just don’t like the inelegance of the model that results. We are back
> > > to ‘you can override everything, except...’ or ‘everything is a sub in
> > > CORE::, except...’.
> >
> > I don't understand how you get to this position though. Is it just
> > because 'else' happens to be spelled with alphanumeric characters? It
> > already has no meaning at all in the language outside of the context of
> > an 'if' statement, I don't see what is gained by putting the override
> > here. What does "you can override else" even mean? We've already
> > decided that it means nothing, so I don't understand what the goal is
> > here. The language itself would be effectively identical if the if
> > statement syntax looked like (ignoring elsif for the moment)
> > "if (foo) { foo_is_true() } { foo_is_false() }", and so I don't see how
> > adding the ability to override else through this very specific mechanism
> > makes anything less confusing - it seems more confusing to me.
>
> I think I’ve been a bit unclear. When I talked about ‘if’ falling back
> to the keyword plugin, I meant that it would give up trying to parse any
> more and simply leave whatever follows to be part of the next statement.
>
> >
> > > At one time chr had special syntax. Then prototypes were introduced, so
> > > now it has ;$ syntax. So it is no longer a special case. I was hoping
> > > I could extend that further; i.e., eliminate all special cases by making
> > > them part of a more general scheme.
> >
> > Making 'else' overridable via this mechanism feels more like a special
> > case to me than leaving it out. All other keywords that this more
> > general scheme handles can be used as a stand-alone statement, but this
> > is not true of 'else' or 'elsif'.
>
> So are you saying that else should not be overridable anywhere? Or are
> you saying that the ‘if’ parsing should swallow up any ‘else’ it sees,
> regardless of what follows (allowing else to be overridden in other
> contexts)? (And the third option is for ‘if’ to swallow up ‘else’ only
> when ‘{’ follows it.)
>
> I could implement it either way; I just need to start somewhere.
I don't think else should be overridable. "else { foo() }" is already
a syntax error (outside of the context of an if statement), and having
a keyword that's overridable except for that it breaks if you insert an
if statement above it seems particularly useless to me. If there are any
actual useful reasons for allowing this, I'd be interested in hearing
them, but I think in terms of consistency it makes more sense for the
keyword plugin to only handle things that are already statements on
their own.
-doy
Thread Previous
|
Thread Next