On Dec 19, 2017, at 3:03 PM, Panicz Maciej Godek <xxxxxx@gmail.com> wrote:

2017-12-19 20:38 GMT+01:00 Jim Rees <xxxxxx@gmail.com>:
 
Secondly,  the re-use of the underscore identifier exported by (scheme base) and suggested to be re-exported by (srfi 156))…

It’s not that I think it would normally create an issue, but if it does create an issue, solving it may be difficult.    Users who only dabble in syntax-rules macros occasionally may get very confused.   I suppose its no bigger an issue than those created by other auxiliary syntax, but in this case the same identifier is being used in two completely unrelated ways.    I’m not strongly opposed, but this just seems like asking for trouble.

If I knew how to apply this suggestion, I'd do that eagerly.
However, I was rather confused, because I didn't know which module system I should use (I've found out that R7RS and R6RS have different module systems!)



The suggestion would be to use just about any other identifier that isn’t already in use with a different meaning & purpose.

My first choice would be <> — because it’s serving the same purpose as the identifier from (srfi 26), which has been final for a very long time.    It’s unlikely someone would run into a conflict.

Here are some random punctuation chars from a US keyboard that I don’t think have any standard uses in Scheme and are legal identifiers according to R7RS (I know R6RS has some differences in lexical syntax, so these might not all be legal there):

! ? @ $ ^ % &  : /

It’s likely there are common uses for some of these identifiers already that I’m unaware of.

There’s still another option that some might like — let the caller provide the identifier.  Using (srfi 139) syntax parameters, one can add a with-isvar macro:

(with-isvar ()
      body …
      (is  < 10)
      ...
      (is  = ?))

You could still have a default identifier when with-isvar is not used.  This may be more complex than anyone needs, and it requires (srfi 139) support, but it was a fun programming exercise for me this afternoon for proof of concept.