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
