[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: native compilation units

From: Lynn Winebarger
Subject: Re: native compilation units
Date: Sat, 11 Jun 2022 13:49:13 -0400

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:

      (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)
     (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:
  (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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]