Autoloaded keywords (Re: Proof of concept: "static" parameter scope)

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Oct 3,  8:19pm, Peter Stephenson wrote:
} Subject: Re: Proof of concept: "static" parameter scope
}
} It's just the same as
} 
} % zyyy() { burble x=(a b c); print $x }
} % zyyy
} zyyy: number expected
} 
} as it should be.  Maybe you'd forgotten that parentheses are parsed so
} as not to make white space work as a word separator?

Yes, that's sort of it.  I was expecting a different error in the event
that they'd been interpreted as glob qualifiers, so I assumed they had
not been.

} This certainly doesn't help you make a syntactic structure dynamically
} loadable, but that's always going to be hairy.  I think our choices are
} - provide adequate means, probably turned on by default, to load everything
} early enough that it just works.  This means the distribution would enable
} "private", or whatever, as a keyword out of the box.  If we don't I don't
} think this is worth doing.  (Of course you can still use disable -r in am
} initialisation file.)
} - go a step even further than that and just compile it in (but you can *still*
} disable -r).

The latter would be fine if we're just talking about "private" and as
has been mentioned we could pick up some efficiencies by adding a real
PM_PRIVATE flag bit (though we are running out of PM_* bit positions).

However, if we're talking about generalizing the mechanism, we can't
reasonably assert that we'll enable every module-defined keyword via a
change to the default distribution.

I'm leaning toward

} - document it and live with it

but another thought is to in fact add autoloadable keywords as a module
"feature" type and check every word as it's parsed to see if it needs to
trigger an autoload.  This shouldn't be that much worse than checking
every word to see if it's an alias (and has the same pitfalls ... in
fact in ksh many of what we have harcoded as builtins are implemented
[or at least documented] as aliases).

} - decide it's too hairy and limit ourselves to autoloading an option to
} local etc.

I hadn't considered autoloadable *options* ... how would that work?

Here's yet another idea -- perhaps an extension of "autoload" that
specifies which modules have to be zmodload'd before the function can
be autoloaded and run.  Correspondingly the in-memory function image
would record the set of modules that were loaded when it was parsed,
sort of like sticky options, and would return a runtime error if
those modules were no longer loaded.  (Or perhaps only if it were
unable to REload them, but that might be too much automation.)  We'd
have to be sure that zcompile wrote out that state.  (Does it now
preserve sticky options?)