> Would it make sense to add a feature for declaring a function symbol value
> is constant and non-advisable, at least within some notion of explicitly
> named scope(s)? That would allow developers to be more selective about
> which functions are "exported" to library users, and which are defined as
> global function symbols because it's more convenient than wrapping
> everything in a package/module/namespace in a giant cl-flet and then
> explicitly "exporting" functions and macros via fset.
In which sense would it be different from:
(cl-flet
...
(defun ...)
(defun ...)
...)
Good point - it's my scheme background confusing me. I was thinking defun would operate with similar scoping rules as defvar and establish a local binding, where fset (like setq) would not create any new bindings.
(1) I don't know how much performance difference (if any) there is between
(fsetq exported-fxn #'internal-implementation)
and
(defun exported-fxn (x y ...) (internal-implementation x y ...))
(2) I'm also thinking of more aggressively forcing const-ness at run-time with something like:
(eval-when-compile
(cl-flet ((internal-implemenation (x y ...) body ...))
(fset exported-fxn #'internal-implementation)))
(fset exported-fxn (eval-when-compile #'exported-fxn))
If that makes sense, is there a way to do the same thing with defun?
Or perhaps cl-labels instead of cl-flet, assuming they are both optimized the same way.
Lynn