On Thu, Dec 01, 2005 at 10:54:14AM -0500, Rob Kinyon wrote:
: I just read the slides about CAPerl (http://caperl.links.org/) and it's an
: interesting idea. Leaving aside the question of whether this would work in
: Perl5 or not, I think it would be very interesting to look at building this
: concept into Perl6. Here's how I'd envision doing so:
We should probably think about as a potential variant of the recent
env addition to S02.
: * Any subroutine is allowed to work with the parameters it was given.
: (If you didn't want it to work with those, why did you give them to it?)
Um, maybe because you're calling a set of routines, and some of the routines
are interested in some of the initializers but not others? Currently we
have methods implicitly all having *%_ to soak up unexpected arguments.
: Variables outside its scope are, by default, not allowed.
Maybe we need to differentiate lexical and dynamic scoping here. The
env mechanism is only addressing dynamic scoping of lexicals. And we
turn on $_ visibility by default. That would be a considered a security
hole under this model.
: * When looking at a variable you're allowed to see, you are only allowed
: to use the methods it exposes - no peeking!
I'm not entirely sure what this means. What counts as a method?
Use as an rvalue? Use as an lvalue. Modification?
Different scopes see different sets of methods to attributes depending
on whether the attribute is private/public, rw or readonly, native
or boxed type. I can see a lot of times where you might be allowed
to read a native value but not write it, for instance. (Possibly
readonly access to any externals should be the default for eval,
even if we don't go with a stronger capabilities model.)
: * A subroutine may be explicitly granted access to a variable in a
: parent scope through the grant keyword. (More later.)
More or less what the env declarator does.
: * A subroutine may be disallowed access to a variable in a parent scope
: through the revoke keyword. (More later.)
That would currently have to be done with an inner my scope to hide
the env scope.
: * Access to resources outside the program (files, etc) must be provided
: to the subroutine through parameters or explicit grants.
Hmm. What if you want to provide part of %ENV? I suppose one would have
to copy in your own env %ENV.
: * The outermost scope is completely trusted. (Someone has to be ...)
What's an outermost scope? Dynamic or lexical? What about modules that
can be executed directly?
: Grant/revoke (names may be changed, as needed) take the following
: (pseudocode) signatures:
: grant ( Sub, Var, [Var, ... ] )
: revoke( Sub, Var, [Var, ... ] )
Seems inside out to me in the use vars vs our sense. I think
these things want to associate with the declaration, which is why
things like our and env are declarators. Minor magical stuff
that is orthogonal to declarators ends up as traits.
: It is an error to:
: * attempt to grant/revoke access to a variable you don't have access to
: * attempt to grant/revoke access to a variable that isn't in scope for
: the grantee
More good reasons for attaching the grant to the declaration in the
first place. If you're going to grant access by delegation then you
should *use* delegation, I expect.
Larry
