perlbug-comment at perl
Jul 4, 2012, 2:24 PM
Post #1 of 1
(38 views)
Permalink
|
|
[perl #108286] Wishlist: Overridable keywords
|
|
On Mon May 21 05:00:56 2012, zefram [at] fysh wrote:
> 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.
How exactly would that work in practice? A pragma? ‘use keywords
"CORE::DEFAULT", __PACKAGE__’?
And where would lexical subs fit into that scheme? Should CORE::glob
fallback to a lexical glob, the way it falls back to a package sub (I
hope not)?
> 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.
What would the public API for that be? CvKEYWORD_on?
>
> >* "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.
But we mustn’t break ‘require if ...’.
On the other hand, I think require VERSION should be a *syntactic*, not
run-time, special case.
--
Father Chrysostomos
|
