On Sat, Jun 11, 2022 at 12:37 PM Stefan Monnier <monnier@iro.umontreal.ca>
wrote:

> >  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