On Tue, Aug 23, 2005 at 09:11:15AM -0600, Luke Palmer wrote: : On 8/23/05, Ingo Blechschmidt <[EMAIL PROTECTED]> wrote: : > Hi, : > : > (asking because a test testing for the converse was just checked in to : > the Pugs repository [1]) : > : > sub foo ($n, *%rest) {...} : > : > foo 13; : > # $n receives 13, of course, %rest is () : > : > foo 13, foo => "bar"; : > # $n receives 13 again, %rest is (foo => "bar") : > : > foo n => 13; : > # $n receives 13, %rest is (), right? : > : > foo n => 13, foo => "bar"; : > # $n receives 13, %rest is (foo => "bar"), right? : : Yep, that's all correct. Matter of fact, what %rest actually gets has : not been defined. "Maybe %rest mirrors all the named arguments, maybe : it doesn't". I can see a very small utility if it does, but it seems : like it would be faster[1] if it didn't. I think it's fair to say no : here. : : [1] Yeah, yeah, premature optimization and whatnot. You always have : the sig (*%hash) if you really want to.
The Apocalypse explicitly left the question open because of the performance issue, since we might be forced into copying all the entries of a potentially huge hash just to weed out a few entries. (Think environment variables.) You can't just mark certain entries as unavailable since it's probably a reference to someone else's hash. You could set up a proxying filter hash that makes some of the keys vanish, but then you're at the mercy of the owner of the real hash not to change the proxied hash while your function is executing, and there's some overhead in setting up the proxy hash. It's possible that COW hashes can be made to work efficiently. We'll need to copy hashes if we want to modify them to pass to subfunctions, just as when you change your environment it doesn't affect your parent process's environment variables. Actually, I envision the named arguments coming in as a separate list of pairs and hash refs, so we could just say that all readonly access to the slurpy hash actually scans that argument list. That assumes that we don't care that much about the efficiency of "environmental" lookups, but I think it might optimize for the common case of argument binding if we process positionals in order and do scanning lookups in the named list for missing positionals. Doing your primary scan on the named list to look for things that might or might not be wanted in the positional list is going to be really slow in cases where a lot of "environment" is passed around. Anyway, what I'm saying is that, assuming we bind the slurpy hash interface to the list implementation, we could just put "nulling" entries on the front of that list as we use up keys. So maybe that's a way to remove keys that's not too much overhead. I suppose we could even suppress that if there was a pragma allowing dups. So there's something to be said for the cleaner semantics. On the other hand, maybe those semantics are not actually cleaner. If we take environment variables as our model, we *don't* remove them from the environment when we "use" them, since child processes may want the same value. If we weed out values from the slurpy hash, we force environmental hashes to be passed some other way. Whether that's a feature or not depends on whether you view such an "environment" as default values for named parameter bindings. Larry