define-methodwould 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.
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-methodwould 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-methodshould 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-methodknow it shouldn't,
define-genericalso 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-methodcan see if they are used in a scope, then it seems there's a way. Since Sagittarius has
current-macro-envprocedures, it is possible to access compile time environment during macro expansion. Thus, it should even be able to detect whether or not
define-methodshould create an implicit generic function or not.
This should work, let's see.