Group Email Manager

login signup
In favor of explicit argument Shiro Kawai (09 Aug 2020 01:33 UTC)
Re: In favor of explicit argument Lassi Kortela (09 Aug 2020 06:46 UTC)
Re: In favor of explicit argument Marc Nieper-Wißkirchen (09 Aug 2020 09:27 UTC)
Re: In favor of explicit argument Adam Nelson (10 Aug 2020 22:25 UTC)
Re: In favor of explicit argument Shiro Kawai (10 Aug 2020 23:46 UTC)
Re: In favor of explicit argument Marc Nieper-Wißkirchen (11 Aug 2020 07:58 UTC)
Re: In favor of explicit argument Alex Shinn (11 Aug 2020 01:29 UTC)
Re: In favor of explicit argument Marc Nieper-Wißkirchen (11 Aug 2020 07:17 UTC)
Re: In favor of explicit argument Jim Rees (11 Aug 2020 16:45 UTC)
Re: In favor of explicit argument Marc Nieper-Wißkirchen (11 Aug 2020 16:57 UTC)
Re: In favor of explicit argument Alex Shinn (12 Aug 2020 02:20 UTC)
Re: In favor of explicit argument John Cowan (12 Aug 2020 02:49 UTC)
Re: In favor of explicit argument Arthur A. Gleckler (12 Aug 2020 03:23 UTC)
Re: In favor of explicit argument Marc Nieper-Wißkirchen (12 Aug 2020 13:29 UTC)
Re: In favor of explicit argument Marc Nieper-Wißkirchen (12 Aug 2020 19:46 UTC)
Re: In favor of explicit argument Alex Shinn (13 Aug 2020 00:40 UTC)
Re: In favor of explicit argument Marc Nieper-Wißkirchen (13 Aug 2020 07:18 UTC)
Re: In favor of explicit argument Alex Shinn (14 Aug 2020 01:24 UTC)
Re: In favor of explicit argument Adam Nelson (13 Aug 2020 01:13 UTC)
Re: In favor of explicit argument John Cowan (13 Aug 2020 01:53 UTC)
Re: In favor of explicit argument Adam Nelson (13 Aug 2020 03:09 UTC)
Re: In favor of explicit argument Alex Shinn (13 Aug 2020 03:16 UTC)
Re: In favor of explicit argument John Cowan (13 Aug 2020 03:31 UTC)
Re: In favor of explicit argument Marc Nieper-Wißkirchen (13 Aug 2020 08:04 UTC)
Re: In favor of explicit argument Jim Rees (13 Aug 2020 18:24 UTC)
Re: In favor of explicit argument Marc Nieper-Wißkirchen (13 Aug 2020 20:05 UTC)
Re: In favor of explicit argument John Cowan (14 Aug 2020 02:41 UTC)
Re: In favor of explicit argument Marc Nieper-Wißkirchen (14 Aug 2020 06:34 UTC)
Re: In favor of explicit argument Marc Nieper-Wißkirchen (14 Aug 2020 13:30 UTC)
Re: In favor of explicit argument Marc Nieper-Wißkirchen (14 Aug 2020 14:08 UTC)
Re: In favor of explicit argument Alex Shinn (15 Aug 2020 22:56 UTC)
Re: In favor of explicit argument Marc Nieper-Wißkirchen (16 Aug 2020 07:55 UTC)
Re: In favor of explicit argument Alex Shinn (14 Aug 2020 02:29 UTC)
Re: In favor of explicit argument Marc Nieper-Wißkirchen 13 Aug 2020 20:04 UTC 
Here is my proposal for a SRFI incorporating the ideas so far. While
writing it, another use case has come to my mind, the possible idea of
hygienic keywords in the context of SRFI 177. Back then, we had put
aside this idea for a while because of likely name clashes when
independent modules define hygienic keywords of the same name. This
can apparently be solved using our ideas here. (And for that use case,
the possibility of binding auxiliary syntax locally (and not only
through a magic library) is very helpful, e.g. for writing a macro
that translates from symbol keywords to hygienic keywords.)

----

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="utf-8">
    <title>SRFI 206: Auxiliary Syntax Keywords</title>
    <link href="/favicon.png" rel="icon" sizes="192x192" type="image/png">
    <link rel="stylesheet" href="https://srfi.schemers.org/srfi.css"
type="text/css">
    <meta name="viewport" content="width=device-width, initial-scale=1">
  </head>
  <body>
    <h1><a href="https://srfi.schemers.org/"><img class="srfi-logo"
    src="https://srfi.schemers.org/srfi-logo.svg" alt="SRFI logo"
    /></a>206: Auxiliary Syntax Keywords</h1>

    <p>Marc Nieper-Wißkirchen</p>

    <h2 id="status">Status</h2>

    <!--
    ??? the draft/final/withdrawn status of the SRFI, information on how
    to subscribe to its mailing list, and important dates in its history.
    The editor will add this section.
    -->

    <h2 id="abstract">Abstract</h2>

    <p>
      This SRFI defines a mechanism to define auxiliary syntax keywords
      independently in different modules that still have the same binding so
      that they can be used interchangedly as literal identifiers
      in <code>syntax-rules</code> and <code>syntax-case</code> expressions and
      can be both imported under the same name without conflicts.
    </p>

    <h2 id="issues">Issues</h2>

    <ul>
      <li>The sample Chibi-Scheme implementation is yet a work in progress.</li>
    </ul>

    <h2 id="rationale">Rationale</h2>

    <p>
      Literal identifiers in <code>syntax-rules</code>
      and <code>syntax-case</code> expressions match another
      identifier if and only if both identifiers have the same lexical
      binding or if both identifiers are the same and both have no
      lexical binding.
    </p>

    <p>
      Macro writers that need these literal identifiers as part of
      specific surrounding forms have therefore two choices.  Either
      they match against a bound or against an unbound identifier.
    </p>

    <p>
      Matching against an unbounded identifier is problematic because
      an unbounded identifier cannot be renamed.
    </p>

    <p>
      Usually, as in the derived forms defined in R6RS and R7RS, the
      literal identifiers are therefore bound.  Their bindings are
      called auxiliary syntax in R6RS and R7RS.
    </p>

    <p>
      This has a different kind of problem.  Often, the names for
      auxiliary syntax are either short common words
      (like <em>else</em>) or simple symbolic identifiers
      (like <em>=&gt;</em>).  Therefore, independent libraries may
      each export an auxiliary keyword but all with the same name.  This is
      problematic when the bindings are not mutually equal.
    </p>

    <p>
      This SRFI defines therefore a mechanism for independent
      libraries to independently export auxiliary syntax with mutually
      equal bindings.
    </p>

    <p>
      If syntax parameters are supported, this auxiliary syntax is a
      syntax parameter so that it can be hygienically be rebound
      through <code>syntax-parameterize</code>.
    </p>

    <p>
      This SRFI also defines a facility to define auxiliary syntax in
      the above sense lexically locally.  This can be used to bring
      back auxiliary syntax back into scope and can be interesting for
      macro writers.
    </p>

    <p>
      In the mailing list
      to <a href="https://srfi.schemers.org/srfi-177/srfi-177.html">SRFI
      177</a>, the idea of hygienic keywords (where keywords are
      understood in the sense of SRFI 177) has been discussed.
      Arguments in favor of hygienic keywords were the avoidance of
      any runtime overhead and that they bring in all the advantages
      of the usual Scheme macro hygiene.  One argument against
      hygienic keywords was that independent libraries may want to
      independently export hygienic keywords under the same name
      without conflicts.  That is now possible with this SRFI.
    </p>

    <h2 id="specification">Specification</h2>

    <h3>Syntax</h3>

    <p>
      This SRFI defines one syntax binding
      form, <code>define-auxiliary-syntax</code>.
    </p>

    <p><code>(define-auxiliary-syntax〈keyword〉〈symbol〉)</code></p>

    <p>
      This form is a definition that can be used wherever syntax
      definitions are allowed.
    </p>

    <p>
      The <code>〈keyword〉</code> is
      bound to (auxiliary) syntax named by <code>〈symbol〉</code>.
    </p>

    <p>
      A <code>〈keyword〉</code> bound
      through <code>define-auxiliary-syntax</code> has the same
      binding as another identifier if and only if the other
      identifier is also bound
      through <code>define-auxiliary-syntax</code> and with the same name.
    </p>

    <p>
      In a Scheme supporting syntax parameters
      (see <a href="https://srfi.schemers.org/srfi-139/srfi-139.html">SRFI
    139</a>), the auxiliary syntax are syntax parameters.
    </p>

    <h3>Libraries</h3>

    <p>
      This SRFI defines two libraries, <code>(srfi 206)</code>
      and <code>(srfi 206 *)</code>.
    </p>

    <p>
      The <code>define-auxiliary-syntax</code> keyword is (the sole
      identifier) exported by the library <code>(srfi 206)</code>.
    </p>

    <p>
      The library <code>(srfi 206 *)</code> is a (magic) library that
      can, in import sets, only be referenced in the form <code>(only
      (srfi 206 *) 〈identifier〉…)</code>.  This import set imports
      the <code>〈identifier〉</code>s, each bound at top-level as if
      through <code>define-auxiliary-syntax</code> to auxiliary syntax
      with the respective name.
    </p>

    <h3>Interoperability</h3>

    <p>
      In a Scheme implementation supporting this SRFI, all auxiliary
      syntax, in particular the
      identifiers <code>else</code>, <code>=&gt;</code>, <code>unquote</code>,
      <code>unquote-splicing</code>, <code>_</code>, <code>...</code>
      defined in <code>(scheme base)</code> behave as if defined
      through <code>define-auxiliary-syntax</code> with their
      respective names.
    </p>

    <p>
      Syntax parameters that have no sensible initial binding
      (like <code>yield</code>
      of <a href="https://srfi.schemers.org/srfi-190/srfi-190.html">SRFI
    190</a>) shall be bound through <code>define-auxiliary-syntax</code>.
    </p>

    <h2 id="implementation">Implementation</h2>

    <p>This SRFI cannot be implemented portably in R6RS or R7RS
      alone.  A sample implementation for Chibi-Scheme will be provided.
    </p>

    <!-- <a href="srfi minus ???-sample.scm">Source for the sample
implementation.</a> -->

    <h2 id="acknowledgements">Acknowledgements</h2>

    <p>
      Credit goes to John Cowan, Adam Nelson, Jim Rees, Alex Shinn, and
      everyone else who initially discussed the idea for this SRFI on the
      <a href="https://srfi.schemers.org/srfi-197/srfi-197.html">SRFI
197</a> mailing list.
    </p>

    <h2 id="copyright">Copyright</h2>
    <p>Copyright &copy; Marc Nieper-Wißkirchen (2020).</p>

    <p>
      Permission is hereby granted, free of charge, to any person
      obtaining a copy of this software and associated documentation files
      (the "Software"), to deal in the Software without restriction,
      including without limitation the rights to use, copy, modify, merge,
      publish, distribute, sublicense, and/or sell copies of the Software,
      and to permit persons to whom the Software is furnished to do so,
      subject to the following conditions:</p>

    <p>
      The above copyright notice and this permission notice (including the
      next paragraph) shall be included in all copies or substantial
      portions of the Software.</p>
    <p>
      THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
      EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
      MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
      NONINFRINGEMENT.  IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
      BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
      ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
      CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
      SOFTWARE.</p>

    <hr>
    <address>Editor: <a
href="mailto:srfi-editors+at+srfi+dot+schemers+dot+org">Arthur A.
Gleckler</a></address></body></html>

Am Do., 13. Aug. 2020 um 20:24 Uhr schrieb Jim Rees <xxxxxx@gmail.com>:
>
> On Tue, Aug 11, 2020 at 10:20 PM Alex Shinn <xxxxxx@gmail.com> wrote:
>
>> Jim's solution hooks into the module system, though as a nitpick I think
>> a syntactically cleaner variant is to assume a module called `(auto)`
>> which exports nothing by default but can auto-generate bindings when
>> used with an `only` import spec:
>>
>>     (import (only (auto) <> <...>)))
>>
>> There is a somewhat related precedent in Lisps which auto-generate
>> cxr bindings.
>
>
> Okay, done and done!    It was a lot of work to re-factor the library-exports layer to support finite and (temporarily) infinite sets.   Once that was complete, (only (auto) <> <...>) worked fine, and the ($cxr) library implementation was only 38 lines of code (and ~ 1/3 of that identical boilerplate to the (auto) support code).
>
> =L2REPL> (import (only ($cxr) caaaaaaaaaaaaaaaaaaaaaaaaaaar))
> =L2REPL> (caaaaaaaaaaaaaaaaaaaaaaaaaaar '(((((((((((((((((((((((((((((42))))))))))))))))))))))))))))))
> ((42))
>
> That was fun!