Re: Precompiled wordcode zsh functions

[Sven Wischnowsky <wischnow@informatik.hu-berlin.de>]

Bart Schaefer wrote:

> On Feb 29,  8:45am, Sven Wischnowsky wrote:
> } Subject: Re: Precompiled wordcode zsh functions
> }
> } [...]  In my implementation digest files are really only one-file-
> } directories. I.e. they are searched like normal directories by
> } getfpfunc() (more precisely a utility function used by it). It will
> } not define all functions in the digest file immediately. I really
> } prefer that behaviour because a user has to worry about nothing when,
> } for example, he wants to override one of the functions with his own
> } definition in a directory earlier in $fpath.
> 
> I'm concerned that we should at least have a way to produce a warning
> about it.  I mean, if I were to invent a function named `_files' that
> had nothing to do with completion, and put it in a directory early in
> my $fpath -- even PWS's guide recommends putting your own functions
> before distributed ones -- three-quarters of the completion system
> would be mysteriously broken for me.  If the whole completion system
> has been hidden inside one giant file, how do I find out what has gone
> wrong?

That's one of the reasons why I'm not too happy with the thought of
installing such a digest file per-default. I mean, maybe we should
just leave it to the user to create his/her own digest files
containing the stuff (s)he really wants. The 400KB (yes, it's 400, the 
300 was a typo, sorry) isn't that much, is it? With that we would have 
the same situation as now. Also, the functions in the digest can, of
course, be listed, so it's the same problem as looking into the
directories in $fpath. Hm, maybe a function that checks everything in
$fpath to see which names are defined more than once? [1]

> And lest you think this is farfetched, please note that I've had the
> following in my .zshenv for many years now[*]:
> 
>     alias calc="noglob _calc"
>     _calc() { awk "BEGIN {print $*}" < /dev/null }
> 
> So existing user functions with leading underscores are not out of the
> question.  

I had functions beginning with an underscore myself...

> Oh, and what's the handling with respect to kshautoload vs. a function
> like _cvs that wants to define other functions and then call itself?

Currently zcompile just puts the contents of the files into the
wordcode files. I.e. functions in them behave exactly like the files.


Bye
 Sven

[1] There are other interesting possibilities for functions wrt
    compilation: a `recompile' function that checks file dates and
    digest files. A function for syntax-checking a file -- that's
    possible because the zcompile reports parse errors as usual and
    one can use /dev/null as the name of the target wordcode file.

--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de