define-method
would create a generic function implicitly if there's none defined yet. It's convenient and I've written libraries (probably only one) depending on this behaviour. (c.f. (binary data)
)Convenience would usually be a trade-off of consistency, at least in my case. For example, this is a long standing bug (though, I've just issued):
(import (clos user)) (let () (define-generic foo)) foo ;; -> should be &undefinedThis is because
define-method
would create a generic function during macro expansion, and it would be an unexpected result in this case if it didn't:(begin (define-generic foo) (define-method foo (o) #t))In this case,
define-method
should not make implicit generic function, but macro expansions are done in the same compilation time as define-generic
. Thus, it's impossible to know if it should create or not. To let define-method
know it shouldn't, define-generic
also inserts binding into current environment (a library) during macro expansion.Can't I do better? Creating global binding during macro expansion is rather ugly, but I don't I can get rid of it (or maybe the future?). Yet, I think I can avoid to create unwanted one like above example. It's still just an idea but if
define-generic
and define-method
can see if they are used in a scope, then it seems there's a way. Since Sagittarius has current-usage-env
and current-macro-env
procedures, it is possible to access compile time environment during macro expansion. Thus, it should even be able to detect whether or not define-method
should create an implicit generic function or not.This should work, let's see.
No comments:
Post a Comment