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
