On Tue, Dec 13, 2005 at 12:42:47PM +0200, Gaal Yahas wrote:
: S11 stipulates:
:
: * modules can decorate exports with tagsets
:
: * module users are the ones who control which imports are allowed,
: and what scoping to give each import. The default is always lexical.
:
: There are a few pieces missing in the puzzle, I think.
:
: First, can a module not suggest a scope for the consumer? If a module
: relies, for example, on setting up a 'state' variable in the caller, it
: would be tedious for the caller to have to request that kind of var
: every time. (If modules have no business demanding certain scopes from
: their callers, why should the caller even have the standard way of
: setting such scope?)
I think we can certainly let the module specify the default when
someone says
use Module <$hownow>;
rather than
use Module :my<$hownow>;
I suspect the notation for setting default on the module end is simply
to allow tag pseudo-sets that specify it:
my $hownow is export(:state); # override implicit :my default
: Second, where does a module consumer communicate configuration requests
: to the module? In Perl 5, the 'use' arguments have often been used for
: this purpose in an ad-hoc manner (e.g., 'use Test::More "no_plan"'),
: and while I agree it's good to make this more regular, that shouldn't
: mean it has to happen at runtime. Supposing there is an IMPORT hook we
: can use, it needs some speccing so that we don't go ad-hoc all over
: again. I don't have a proposal for how this would look like, but it
: shouldn't conflate import directives (that say something about how the
: caller sees the module) with other configurations (that say something
: about the demands made by the caller to the module).
Well, there's a lot to be said for ad-hoc, but yes, it would be good
to get control of the various forms of adhocracy so we know which
ones are necessarily ad hoc and which ones are that way accidentally.
I'm running into this difficulty right now with the perl5-to-perl5
translator. A lot of modules (and BEGIN blocks) just assume they
can call exit(0) if they know they can't possibly work right, despite
the fact that I'm not actually interested in running them--I'm only
interested in compiling against their interface. So right now I've
got kludges in place to transform exit() into a no-op when I know
I'm just trying to compile. But it'd be nice if we could give a way
for the modules to make this distinction so that we can work with
the interface even if the implementation is known to be bogus on
this architecture.
By the way, I can now translate about 95% of random Perl 5 code back
to identical Perl 5. So I'm getting closer to starting on Perl 6
translation. Though it'll still be a lot of work, insofar as the
translator often assumes it's only there to produce Perl 5. The
first comment in the translator is:
# Suboptimal things:
# type info is generally still implicit
# the madness calls are actually losing type information
# surrounding whitespace not consistently in or out of objects
# brace madprops tend to be too low in the tree
# encodings are a hack
# heredocs are a hack
# could use about 18 more refactorings...
# lots of unused cruft left around from previous refactorings
And that's leaving out the fact that I've broken some of the ordinary
test suite by installing extra nodes, and need to patch some of that
up before the madskills patch is ready to go back into bleadperl.
But maybe I can delegate some of that...
For instance, just yesterday I ran into this one. In the madskills
version I have to install an extra OP_STUB node to carry the
whitespace and comma madprops of something with an extra comma like:
@list = ($a, 1, 2, );
But that ended up breaking the test that "knows" that
substr($a, 1, 2, ) = ""
is legal because the substr only has 3 arguments. But that's because
the lexer just kind of lied about that extra comma not being there,
so by the time op.c's mod() function sees it, there *are* only 3 arguments.
Or the fact that the lexer simply drops things like trailing extra \E's
when it knows they'll have no effect. Or the fake brackets in ${foo[1]}.
Or going the other way, installing extra syntax for the various command
line switches that shouldn't show up in the translated version.
There are just all kinds of things like that where perl has fibbed to
itself and then relied on those fibs in other places. That's why it
has taken most of a year to get this far. (Well, that, and me being
interested in everything else at the same time, which is just part of
the problem of being me.)
Nevertheless, I'm now confident that we can hit the original p5-to-p6
spec of translating 95% of scripts at least 95% accurately.
Larry
