Re: autoload

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Sep 19,  5:58pm, Ray Andrews wrote:
}
} By gum it works if you get it exactly right:
} 
} -"zcompile ... (N-.:t)" ... or it barfs if there's a directory on the 
} same path. Fussy fussy.

You *really* don't want that :t in there.

} -"autoload +X -w ..." works with Sebastian's, but not with mine (which 
} are all functions).

This is either because (a) you needed "zcompile -k ..." with yours, or
(b) you have multiple functions per file, which we've already discussed
at length with respect to autoload.  [More on this below.]

} -"autoload -w ..." works with mine but not Sebastian's.

I think "autoload" is entirely superfluous in this case, because:

} -"source miscfunctions" *before* calling an autoloaded function to have 
} it work the first time.

Er, no.  In that case it's 99% certain the function isn't autoloaded at
all, rather it's simply been fully defined during the "source" command.
The "source" command is probably reading miscfunctions.zwc, though.

} -Append new dirs to FPATH or other things break.

I have no idea whether that means "the FPATH has to contain some new
stuff" or also "... and the new stuff has to go at the end, it can't
be put anywhere else".  Either could be true or false depending on the
context.

} I guess the zcompile of my dreams would be able to process both
} scripts and functions in one go

This has nothing to do with zcompile output and everything to do with
how the result is read back.  Scripts you want to "source ..." and
functions you want to define (and possibly also call, if defining is
happening as part of deferred loading).

(Maybe we should never have created the "autoload" command, because
that name just muddles up the act of creating a placeholder for
deferred loading with the actual deferred loading event itself.)

[I just noticed that the doc for zcompile refers to "execution of
scripts".  This is misleading, it should say "sourcing of scripts".
Execution (as in spawning a new shell to run a file that has execute
mode bit set) does not involve loading .zwc files; only "source"
and "." do that.]

Also zcompile has no way to guess if the file it's being used on is a
source-able script or a function body.  You'd need to tell it which,
somehow.  So "all in one go" would become some convoluted thing like

zcompileOfMyDreams --script=miscfunctions --function=n-list ...

} and be able to see the functions in 'miscfunctions' regardless of
} the filename

This is for all practical purposes impossible to do automatically.
In order to know what functions are in "miscfunctions", zcompile
would have to first *run* (source) that file, which might have
other side effects besides just defining the functions themselves.

Neverthe less zcompile does have a way to do what you're asking,
assuming you know there are no side-effects:

    ( # subshell so as not to muck up the parent
      unfunction -m \*		# clean out all extra functions
      source miscfunctions	# load the functions we care about
      zcompile -a -c miscfunctions.zwc	# compile all the functions
    )

Note that here you are explicitly doing the "run that file" step.

} and not try to digest existing .zwc's,
} and not worry about directories.

This is a philosophical issue along the same lines as CSH_NULL_GLOB.
If I name a bunch of things and some of them are wrong, should the
shell complain about them or not, and either way, should it skip
them and continue working on the ones that are correct?  Which is
more likely to produce the final result that the user expected?

Since the user is perfectly capable of filtering these out when the
argument list is built, I think the decision to complain and stop
is the correct one.

} And the autoload of my dreams would be able to pass all of it back
} every time.

Maybe if you try replacing "autoload" with its synonym "functions -u"
(create an undefined function) in your mental map, you'd get a better
idea of what you're asking.

What would it mean to create an undefined script?  What event would
cause it to become defined?