develooper Front page | perl.perl5.porters | Postings from March 2006

Re: how should %^H work with lexical pramas

Thread Previous | Thread Next
Rafael Garcia-Suarez
March 29, 2006 04:09
Re: how should %^H work with lexical pramas
Message ID:
Nicholas Clark wrote:
> which means that you can't change the value of $^H{"sort"} at runtime and
> expect it to change how the sort ops (in scope) behave.

$^H and %^H are really for how to affect compilation. As implemented,
they're simply not useful at run-time, be it for reading from or writing

For me that's different from a scoped setting that is set and read at
runtime. For that, I think the right way to do it is to have a global
variable ${^SETTING} that you can set at runtime, and restrict locally
via local(). OK, that's not lexical.

3rd type of situation : you want to be able to get the value of the
compile-time hint at run-time because you're going to need it as well.
This is the case of, because you have both compile-time
warnings and run-time warnings. And, as a matter of fact,
don't use %^H, but another magic variable, a bit field, stored in cops
so its value is still accessible after compilation.

> Do lexical pragmas want to read %^H at compile time, and bake it in?

Core lexical pragmas only need that (Robin's patch having solved the
problems with %^H in eval{}).

> Or do they expect %^H at run time to be lexically set correctly, so that they
> can read it then?
> (Or both?)

That's a new problem, which is summarized as : "how to write one's own
lexical pragmas ?" In your import()/unimport() methods you'll be able to
set and get values in %^H, as core pragmas do (sort, overload, open,
charnames). But to get a useful pure-perl pragma, what you need is to
get at run-time the value that $^H{yourpragma} had at compile-time in
the caller's scope.

A concrete example should help; let's say you want to write a pragma
foo, providing a function foo::do_that() that does different things
depending on whether the 'use foo' pragma is in effect in the current
lexical scope. Then, in the body of do_that(), you'll need to test what
the value of $^H{foo} was at compile-time in the caller's scope.

Then, maybe the solution is, as you said, to have a duplicate of %^H
that is populated with values from %^H during compilation, and which is
accessible at run-time (probably read-only, but it's better to avoid
that if possible.) What's absolutely needed, though, is to store them in
the most compact way possible. So a linked list of HE (pointed to by
cops) can be a solution, so when you enter a new scope where a new value
is added to %^H you only need to add it in front of the linked list. (If
you have several values, including undef, in the linked list, the first
one wins.) Access time is less important here.

See how much scorn he has for human means.
    -- Purgatorio, II, 31

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About