Re: PRAGMA musing: "no scope"

tchrist@perl.com writes:
:     BEGIN {
: 	no scope;  # previous nested lexical scope boundary erased
: 	require Config;
: 	if ($Config::Config{archname} =~ /i186/) {
: 	    no scope;  # previous nested lexical scope boundary erased
: 	    use integer;
: 	    no  warnings qw/numeric/;
: 	    use warnings qw/FATAL overflow/;
: 	} 
:     } 
: 
: This is only slightly more disgusting than upscope.  And it doesn't
: allow an unrelated/non-nested scope to be pierced, such as a do()ne file.

Offhand, I think I'd rather see something that explicitly puts things
into the currently compiling scope, bypassing however many levels
necessary to do that.  More like a chomp than a chop, if you catch my
drift.  Or kind of like how Carp works, looking for a different package
than the current one.

    BEGIN {
	require Config;
	if ($Config::Config{archname} =~ /i186/) {
	    use comppad;  # current runtime lexical scopes erased
	    use integer;
	    no  warnings qw/numeric/;
	    use warnings qw/FATAL overflow/;
	} 
    } 

I suppose

    use comppad;

could be generalized to 

    use pad ':comp'

or some such.  And maybe even abbreviated

    use pad;

Note that this would also allow do/require/use files to do lexical
things to the user, as long as this isn't done within a BEGIN in the
used file.  There are various interesting issues, however.  Suppose
module Foo.pm has

package Foo;

BEGIN {
    use pad;
    my $foo;
}

{
    use pad;
    my $bar = $foo;
}

Presumably $foo would be installed into the current lexical scope, and
$bar would be installed into each lexical scope that uses Foo.  But
would $foo actually be visible within the "use pad" scope?  Does "use
pad" really make an alias for the currently compiling scope that
actually exists in Foo.pm's scope as well?  What if there's a "my $foo"
in the caller's lexical scope, do we use that one first or last?  What
about if we start mixing various "use pad" calls in a single block.
Which code gets executed in which pad?  The mind boggles.

It is at times like these that one wishes for the compiler to simply
parse the return value of "use" if it's anything other than 1 or 0.
But that gives lousy error messages, as does any textually based macro
system.

Perhaps we should allow use to return a PARSE block, which will execute
like a sub in the user's space but give decent error messages in the
used module.  Of course, we'd still have to parse the PARSE block within
the correct pad, but at least we'd know to reparse it for every user, and
it'd stick out like a sore thumb, unlike "use pad".  And we still have
the issue of what

    PARSE {
	my $bar = $foo;
    }

would mean.

This is all getting rather close to macros or templates or something else
equally (un)palatable...

Pardon me for brainstorming in your general(izational) direction.

Larry

• PRAGMA musing: "no scope" by Tom Christiansen
• Re: PRAGMA musing: "no scope" by Larry Wall
• Re: PRAGMA musing: "no scope" by Ilya Zakharevich
• Re: PRAGMA musing: "no scope" by Tom Christiansen
• Re: PRAGMA musing: "no scope" by Jeff Pinyan