Mark H Weaver <[email protected]> skribis: > [email protected] (Ludovic Courtès) writes: > >> Mark H Weaver <[email protected]> skribis: >> >>> In the end, here's how this works: 'with-ellipsis' binds a special >>> identifier named #{ $sc-ellipsis }# using a new 'ellipsis' binding type. >>> The new ellipsis identifier is stored within the binding. In order to >>> determine whether an identifier X is an ellipsis, the binding for >>> #{ $sc-ellipsis }# is looked up in the lexical environment of X. If the >>> binding is found and has binding-type 'ellipsis', then X is compared to >>> the identifier stored in the binding using 'bound-id=?'. Otherwise, X >>> is compared to '...' using 'free-id=?' as was done before. >> >> This looks nice! Thanks for providing the detailed reasoning, that’s >> insightful. >> >> Does something like this work: >> >> (define-syntax define-inline >> (with-ellipsis --- >> (syntax-rules () >> ((_ (name parms ---) exp ---) >> (define-syntax name >> (syntax-rules () >> ((_ args (--- ---)) >> ((lambda (parms ---) exp ---) >> args (--- ---))))))))) > > No, because as noted in the docs, the custom ellipsis does not propagate > to the generated code.
OK, right; it’d work with ‘with-ellipsis’ repeated after the inner ‘define-syntax’ I suppose. Actually my question was more about the ellipsis escaping form (... ...). It is affected by ‘with-ellipsis’, right? (It may be a obvious question, but I’m not familiar with the implementation.) [...] > It is important that the custom ellipsis does not propagate to the > generated code, so that we can use 'with-ellipsis' to implement R7RS > 'syntax-rules', which allows a custom ellipsis as its first operand, > before the literals list. In R7RS 'syntax-rules', the custom ellipsis > does not propagate to generated code. Yes, that make sense. > Note that as currently implemented, the effect of 'with-ellipsis' > also does not propagate into nested syntax definition forms such as > 'let-syntax', 'letrec-syntax', and 'define-syntax'. We could go either > way on this. Well, I think it’s fine this way, but then again I’ve been living in world without that feature. ;-) How does R7RS syntax-rules behave in that respect? I guess we should just follow suit. >> Could you wrap lines to 80 columns in psyntax.scm? > > Ordinarily I try to keep lines to 80 columns, but psyntax.scm already > has a great deal of code that violates that rule. Fixing that would be > a rather large commit, and I'm not sure it would be an improvement. OK (I do find it hard to read long lines, FWIW.) Thanks! Ludo’.
