Re: Fw: zsh POSIX_TRAPS option

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Oct 11,  9:42am, Jilles Tjoelker <jilles@xxxxxxxx> was quoted
} by Peter W. Stephenson:
} 
} Regarding the POSIX_TRAPS option, I can't help but wonder if making a
} difference between f() { ... } (POSIX functions) and function f { ... }
} (ksh functions) instead of adding more and more options would make
} things less complex.

That could have been a good idea when the "function" keyword was first
introduced, but we now have years of treating them equivalently to
think about.  (Also, whether functions have their own traps is based
on the LOCAL_TRAPS option, not the POSIX_TRAPS option, except for the
special case of the EXIT trap.)

In particular there's the problem of autoloaded functions.  We already
have several potentially confusing tricks to designate KSH_AUTOLOAD and
to define the of function correctly in the event the file is loaded
under the wrong regimen.  Having an additional behavior that changes
depending on these circumstances would seem to me more complex rather
than less, particularly if there's no way to test for that behavior.

} In ksh93, ksh functions have their own traps, while POSIX functions
} share the invoker's traps.

This is suddenly seeming familiar.  There may have been discussion of
changing zsh semantics of "function f" vs. "f()" at some earlier time,
but I have no idea how to do an efficient list archive search for it.

I have only a year-old version of mksh to conveniently play with.  What
does "have their own traps" imply during function execution about traps
that were set before the function was entered, when the function does
NOT redefine them?