develooper Front page | perl.perl5.porters | Postings from July 2012

[perl #108286] Wishlist: Overridable keywords

Thread Next
From:
Father Chrysostomos via RT
Date:
July 4, 2012 14:24
Subject:
[perl #108286] Wishlist: Overridable keywords
Message ID:
rt-3.6.HEAD-18676-1341437055-1766.108286-14-0@perl.org
On Mon May 21 05:00:56 2012, zefram@fysh.org 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


Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About