On Fri, Apr 22, 2011 at 1:18 AM, Andre van Tonder <[email protected]> wrote: > On Thu, 21 Apr 2011, Alex Shinn wrote: >> >> The option of _not_ renaming I consider to be far more >> important than the ability to rename. I had honestly never >> considered that you might want to rename deliberately, and >> I see now that might have uses, but it seems the most >> common use will be to avoid conflicts from macros using >> the same keywords. There are many macros out there >> using common keywords like ":" and "<=", and it's a real >> pain not to be able to use them together without renaming >> one. You have to keep in mind all the renamings as you >> look at the code, and can't cut&paste examples. > > You can use them together. > > The way we got around this in the past is simply to share > the same keyword binding between macros, for example > > (module (base) > (export => cond ....) > > (define-syntax => error-message) > (define-syntax cond ......))
The fault in your logic here is that you must have a single base library with the binding in question. That's why I specifically used ":" and "<=" as examples because they won't be in the standard. Suppose we have (com sun java foo) which provides a macro using ":", and (com microsoft bar) which provides an unrelated macro using ":". They both define and export their own ":" binding. You then can't use those syntaxes together without renaming one of them. The whole approach doesn't scale. -- Alex _______________________________________________ Scheme-reports mailing list [email protected] http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
