On Fri, Apr 22, 2011 at 1:18 AM, Andre van Tonder <andre@het.brown.edu> 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
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports