Closed porky11 closed 7 years ago
I think there are other ways to handle this in general, and
particularly in the context of #155. For example, rather than
expanding argument forms to safe.{name}
, safe
could instead expand
them to convert-to-safe {name}
, which could use the various exists
functions from the introspection module to determine what to do.
yes, in most cases this can be done in different ways. And if there is really a case, where undefined-function
is really helpful, there could be written a macro, which converts all function calls inside into (call-or-undefined fn …)
, a macro which expands to undefined-function
or to the function call. (which is similar to safe)
But it's currently not that easy to write such macros (doesn't work correctly for safe
), since macro expansion seems not to work correctly and there is no way to manually macroexpand something (see #157)
undefined-function may be predefined like this
This only is useful, if in different contextes different version of this function may be used. Normally in some special package (for example the current package for debug reasons). This would require, that functions of some package will use the version of undefined-function as it is defined in this package, even if it is not imported to the current package, which the functions would belong to. (for example when you call
(pkg.fn args)
(pkg.undefined-function pkg.fn args)
will be called. This will enable some nice features I have in mind. See referencing issue