Re: for loop and streams
-- On Thu, 26 Sep 2002 14:06:50 John Williams wrote: We should respect default values if arrays can declare them. Perhaps there will be a modifier for operator declarations to declare what the default behavior should be. Otherwise I don't know how different behaviors for different operators would be possible, especially for user-defined operators. Having an operator force some very narrow kind of context to control what the list returns is very strange. The list should respond in some generalized way (undef or whatever the list is set to pretend is undef) and have the operator choose how to respond to that, and return whatever it deems to be the result of the operation. Under this mechanic the only tricky part is figuring out when the list is exhausted and when it is passing the autoviv value legitimately. Related note, if we can define default values for a list, is that a compile time or runtime property. I confess as to not knowing quite how to tell. I would hope it was runtime for the syntax alone: users but autovivs (Anonymous User); -Erik sub operator:foo is hyper_default(1) ... I agree with Blech, but we can procrasticate doing it at least until Damian makes it clear how operators will define their behavior. Otherwise, a contextualized undef (0 in numeric context, '' in string) would seem DWIM to me. I wouldn't want to throw tons of warnings from one operation, so maybe hyper-operating on unequal lengths gets a new warning, instead of throwing lots of 'undefined value' warnings. ~ John Williams Is your boss reading your email? Probably Keep your messages private by using Lycos Mail. Sign up today at http://mail.lycos.com
Re: for loop and streams
At 12:40 PM -0700 9/26/02, Sean O'Rourke wrote: On Thu, 26 Sep 2002, Paul Johnson wrote: Is that sufficiently vague? Not vague enough, because the current implementation manages to miss the broad side of that semantic barn... The intention is to allow aggregates to have different default return values, IIRC. Right now we return undef as the default, when accessing elements that don't exist, but there are cases where you might want something else. (Numeric-only arrays might want to return 0, and string-only ones , for example) Different operators doing different things sounds awful to me, because it makes it hard to predict what will happen, because new operators will have to be able to control what they do with their operands, and because new types of array-like operands will have to tell operators how to treat them. Blech. Well... no, not really. I think this vagueness is my fault, as I badger Larry and Damian about it on occasion. The reason it's vague is that the Right Thing depends on the types of the variables on either side of an operator. Multiplying two matrices should work differently than multiplying two multidimensional arrays, or two vectors, or a vector by a matrix. We should get the default behaviour defined and in use so people get a handle on how things work, but we do want to make sure people keep in mind that it's the default behaviour, not the required behaviour. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Security model for Perl with good support in Parrot (Safe/Opcode etc.)
I have always longed for a more flexible security system that could limit what a part of code could do in Perl. In perl5 Safe.pm (and Safe::Hole) have serious limitations and problems since it is difficult to have the security-limited code (that executes in a safe compartment) have use packages or interact with code outside the compartment: Safe is not reentrant and Perl dies with a segfault if a safe code calls a shared function that calls in turn a different Safe compartment. That makes it difficult if not impossible to build a perl program that could run code from different users securily (web applications, servelets, user-submitted libraries, a programmable perl MUD, perlemacs...). I have been a lazy lurker and have not provided a RFC or a thread before since I assumed others would have the same problem and would do the job much more competenty. However since I could find no such topics in the RFCs and the Parrot mailing lists, I decided to start some action. I believe Perl6 needs a facility to run compartmented code (object-oriented and module-loading) that is tagged as to its permissions and owner ID. The goal would be to let such code use harmful actions only by calling permitteed outside functions that implement permission checks before calling potentially harmful code. That would mean a piece of user-submitted code closed in a secured compartment could use a limited subset of language (or parrot bytecodes) and some specially permited (shared) functions and method calls outside compartment. Those functions/methods should be able to call code in other compartments (or the same compartment). In this way, code outside the compartment could provide permission-controlled secure access to system facilities and other compartments. Such functionality would be enough for implementation of secure servlets, web/server/cluseter user submitted jobs and perl-based programmable multiuser environments such as MUDs/MUSHes, chatting and programming centers etc. Perhaps the source-info in the Parrot subsystem that is supposed to help in error-message generation could be extended to provide context for compartments and some sort of bytcode filters combined with parser/compiler filters could limit the compartmented code. Is anyone interested? My coding (in)abilities forbid me to actuall create patches, of course... __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com
RE: Security model for Perl with good support in Parrot (Safe/Opc ode etc.)
Kv Org [mailto:[EMAIL PROTECTED]] wrote I believe Perl6 needs a facility to run compartmented code (object-oriented and module-loading) that is tagged as to its permissions and owner ID. The goal would be to let such code use harmful actions only by calling permitteed outside functions that implement permission checks before calling potentially harmful code. I'm not an expert in this area, but I think that a capabilities based model is probably better than compartments. The model would be that a program starts with a set of capabilities; and then any code that it calls (or thread that it starts) would inherit these capabilies -- a function call (or thread start) could explicity deny some capabilities to the code that it calls; also, a function could return additional capabilities to the caller. Capabilities could be stored as a hash in the %MY pad. The capability to add stuff to that hash would, of course, be highly restricted. A capability is probably just an object: any module can define any number of capabilities; but only it (not its subclasses) has the right to create instances of that capability (which it can then return to a requesting caller). When a function later trys to use a protected method, that method would check that its Ccaller has an appropriate capability Dave.
