Mailing List Archive: Perl: porters

[perl #108286] Wishlist: Overridable keywords

1 2 3

View All

Index | Next | Previous | View Threaded

zefram at fysh

May 20, 2012, 3:10 PM

Post #51 of 55 (48 views)
Permalink

Re: [perl #108286] Wishlist: Overridable keywords [In reply to]

Father Chrysostomos via RT wrote:
>On Sun May 20 05:09:10 2012, zefram [at] fysh wrote:
>> What does it mean to be a keyword?
>
>To use the built-in parser for that keyword.

This shouldn't be distinguishable from using an appropriate custom parser
that a user can attach to an arbitrary sub. Going to need more detail
if you're maintaining a distinction here.

>There is currently an ugly parser hack that makes "require" and
>"CORE::require" behave differently, in that the latter bypasses callbacks.

I think here you're talking about the difference that arises if a
sub CORE::GLOBAL::require is defined. This is not a problem to my
model. It's only a problem if you mistakenly suppose that require and
CORE::require must be the same thing, which, for exactly this reason,
they're patently not.

As it is, "CORE::require", used without sigil, always refers to the
baseline builtin behaviour. Its behaviour is not affected by any
CORE::GLOBAL::require. &CORE::require should exhibit the same behaviour.
So your later clearer question:

>What I was trying to ask was: Should an inlined CORE::require CV
>respect callbacks, the way the built-in function does?

(supposing that by "callbacks" you're referring to the CORE::GLOBAL::
mechanism) has a very simple answer: no, &CORE::require should not obey
CORE::GLOBAL::require.

This also immediately leads us to the blindingly obvious realisation
that unqualified "require" by default *does not* refer to CORE::require.
It refers to something else whose behaviour is derived from CORE::require
and CORE::GLOBAL::require, and in particular has compile-time magic that
looks at whether a CORE::GLOBAL::require has been defined. This something
else doesn't currently have a name. I've been privately thinking of it
as CORE::DEFAULT::require for some months, but I'm totally flexible on
what name we use to reify it. Anyway, the point is we *should* reify it,
we should explicitly distinguish between it and CORE::require, and we
should not get confused about having multiple entities with "require"
in their name.

Same goes for everything that's currently subject to CORE::GLOBAL::.

Is this the problem you were referring to? If you meant something else,
please explain further.

-zefram

zefram at fysh

May 21, 2012, 2:59 AM

Post #52 of 55 (49 views)
Permalink

Re: [perl #108286] Wishlist: Overridable keywords [In reply to]

Father Chrysostomos via RT wrote:
>Even if we don't reify it (and I don't see the practical application of
>its reification,

Obvious practical application is to be able to get the default behaviour
under a different name. "*demand = \&CORE::DEFAULT::require".

>I presume you mean that the parser invokes CORE::DEFAULT::* to decide
>how to handle a word like "require".

Yes.

>CORE::DEFAULT::require delegates to CORE::require in the absence of an
>override. But when there is an override it does its own parsing,
>bypassing the override's call checker.

Right, the complication is that it isn't a *complete* delegation to
CORE::GLOBAL::require.

>That's the discrepancy I was trying to describe. We really have quite a
>collection of different behaviours here with regard to CORE::GLOBAL.

Yes, and we must maintain all, or at least most, of those oddities.
We certainly can't start requiring CORE::GLOBAL::require overrides to
supply their own parser magic. The core-supplied CORE::require and
CORE::DEFAULT::require, however, must both have the parser magic built in.

>(In all those cases where I have talked about bypassing the call checker
>of an override, it is not actually bypassed, resulting in very strange
>bugs, such as "too many arguments" and "not enough arguments" errors
>from the same functional call.)

This behaviour is up for negotiation. I think it makes most sense
that the override's check-time magic *does* apply to a call generated
through the override mechanism. The override function should have the
opportunity to inline itself.

-zefram

zefram at fysh

May 21, 2012, 5:00 AM

Post #53 of 55 (48 views)
Permalink

Re: [perl #108286] Wishlist: Overridable keywords [In reply to]

Father Chrysostomos via RT wrote:
>I'd love to hear them. What I've come up with does have a few rough
>edges that I've been trying to iron out.

My basic concept is that the keyword-style name lookup searches through
a path-like sequence of namespaces (~= packages). By default you get
lookup in CORE::DEFAULT followed by standard sub name lookup. To override
a core keyword you should be able to stick some other namespace on the
front of the path, which provides the override.

Where we currently have feature flags that make additional keywords
available, such as feature "switch", the "use feature" directive needs
to add another package into the search path. For example, "given" and
"when" *won't* be in CORE::DEFAULT, they'll be in CORE::SWITCH.

You'd be able to completely replace the default set of keywords by
setting up a custom package and putting that into the path *in place of*
CORE::DEFAULT. So, for example, you can have "if" unbound, rather than
merely overridden. For the ultimate purist position, you import specific
CVs from CORE::DEFAULT into your current package (or lexical namespace)
and then *remove* CORE::DEFAULT from the path. You can operate with
a completely empty path as long as you've got the essential facilities
available through standard sub lookup.

Your "overrides" feature roughly corresponds to putting CORE::DEFAULT
*after* standard sub lookup in the search path. Not sure whether it's
useful to support that, in the absence of backcompat requirement.

>* foo'bar'x3 is equivalent to foo::bar::x3. print'bar'x3 is equivalent
> to print 'barbarbar';

Ooh, interesting difference. This is quite similar to hov "s:" is treated
as the start of a substitution expression, whereas "x:" is a label.
I think this sort of special parsing behaviour ought to be a flag tied
to the CV for the keyword-like operator. Probably in the mg_private
field of the call-parser magic.

>* "require foo" implicitly quotes foo (adding .pm as well). "require
> time" is a version check guaranteed to fail.

Yow. We might want to remove that one.

-zefram

perl.p5p at rjbs

May 31, 2012, 7:38 PM

Post #54 of 55 (48 views)
Permalink

Re: [perl #108286] Wishlist: Overridable keywords [In reply to]

* Nicholas Clark <nick [at] ccl4> [2012-04-24T03:39:11]
> On Mon, Apr 23, 2012 at 03:13:39PM -0700, Father Chrysostomos via RT wrote:
> > On Mon Apr 23 14:03:27 2012, nicholas wrote:
> > > The intent of the changes appears to be to retain the 5.003 and earlier
> > > behaviour on what gets assigned for each construction, but change the
> > > loop behaviour to terminate on undefined rather than simply falsehood for
> > > the common simple cases:
> > >
> > > while (OP ...)
> > >
> > > and
> > >
> > > while ($var = OP ...)
> >
> > Except that while($var = each %h) implies defined(), but while(each %h)
> > does not. So something got screwed up. :-)
>
> Yes. I *thought* that question was about while(each %h) [not] assigning to
> $_, but I missed the [not] using defined.
>
> Pretty sure that the intent was that the intent at the time was to change it
> to use defined. And I'd guess that it was missed because it's not the same
> opcode structure.
>
> So that's a bug?

That is a bug.

--
rjbs

perl.p5p at rjbs

May 31, 2012, 7:49 PM

Post #55 of 55 (49 views)
Permalink

Re: [perl #108286] Wishlist: Overridable keywords [In reply to]

* Ricardo Signes <perl.p5p [at] rjbs> [2012-05-31T22:38:28]
> > So that's a bug?
>
> That is a bug.

Well, *was* a bug. :)

--
rjbs

Attachments:

signature.asc (0.48 KB)

1 2 3

View All

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads