Hello! Mark H Weaver <m...@netris.org> skribis:
> Andy Wingo <wi...@pobox.com> writes: > >> On Wed 16 Nov 2011 04:58, Mark H Weaver <m...@netris.org> writes: >> >>> I think there are better ways to address this problem. I will explore >>> these in another email. >> >> I look forward to this. Please be sure to address the following issues: >> >> * Debian upgrading guile to a newer version, without recompiling >> guile-foo which depends on a hygienically introduced identifier. >> >> * A user modifying a Scheme file from Guile, in the spirit of the >> LGPL, and expecting it to work with program Foo, without recompiling >> Foo (again, in the spirit of the LGPL). > > If we must avoid the recompilations, then I see only one solution: > simply refrain from introducing hygienic top-level identifiers in the > expansions of public interfaces. IMHO, this isn't so bad. If a > top-level variable needs to be expanded in user code, then you'd better > explicitly choose a stable name for it. That’s right. However, in some cases, one may want to write a macro, that introduces an identifier that’s really an implementation detail, and something the author does not want users to bother with. See, for instance, ‘define-wrapped-pointer-type’. Initially, I would have liked to not have a TYPE-NAME argument, because it’s not necessary for the user, and really an implementation detail. Yet, producing a hygienic top-level name wasn’t possible, so the TYPE-NAME argument had to be kept. This is acceptable in this example, but one could probably come up with use cases where it’s more embarrassing. > If you want the name to be programmatically based on some or all of > the macro arguments, this can already be done using `symbol-append', > `datum->syntax' et al. Yes, but it’s not hygienic. [...] > To be more specific: I think we need to record, in every syntax > transformer bound at top-level, the name of the module where it's bound. > Then, within the dynamic extent of `compile-file', (probably using a > fluid) we'd need to accumulate the set of modules whose macro > transformers are used during compilation of the file. This set of > modules (the compile-time dependencies) would be included in the .go > file. Sounds like a good plan! > I think we need this _anyway_. Right now, if you change the way an > exported macro works (for example a macro that defines a record type), > you must _manually_ force recompilation of other modules that expand > that macro. I actually ran into this problem while working on adding > new compiler environment types. Yes, that’s something one quickly encounters when incrementally modifying code with Geiser, for instance. Thanks, Ludo’.
