[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: comments on and questions about SRFI 93



> * The abstract says that the design "...also supports source-object
> correlation, ...  Did you mean only that the representation of syntax
> objects is up to the implementation, and that the implementation can
> therefore maintain additional information like source-object
> correlation?" If so, the SRFI document should mention that somewhere.

This is mentioned briefly in the first paragraph of Section 3.5.  Perhaps
it should be made more explicit somewhere.

> It would be great if,
> perhaps in a later SRFI, a standard could be created for accessing and
> manipulating this information.

I agree.

> * In this paragraph in section 3.1, "references" should be
> "referenced:"
>
>    Expansion of each variable definition right-hand side is deferred
>    until after all of the definitions have been seen so that each
>    keyword and variable references within the right-hand side resolves
>    to the local binding, if any.

Thanks.

> * Also in section 3.1, this expression:
>
>    (lambda (x)
>      (define-syntax defun
>        (syntax-rules () [(_ (x . a) e) (define x (lambda a e))]))
>      (defun (even? n) (or (= n 0) (odd? (- n 1))))
>      (define-syntax odd? (syntax-rules () [(_ n) (not (even? n))]))
>      (odd? (if (odd? x) (* x x) x)))
>
> is said to expand to this:
>
>    (lambda (x)
>      (letrec* ([even? (lambda (n)
>                         (or (= n 0) (not (even? (- n 1)))))])
>        (even? x)))
>
> What happened to the squaring operation?  Shouldn't the expansion be
> this?:
>
>    (lambda (x)
>      (letrec* ([even? (lambda (n)
>                         (or (= n 0) (not (even? (- n 1)))))])
>        (not (even? (if (not (even? x)) (* x x) x)))))
>

Definitely.  Thanks.

> * Near the end of section 3.5, the third bulleted item is:
>
>    a nonlist, novector, nonsymbol value, or
>
> "Novector" should be "nonvector."

Thanks.

> * In section 3.6, the paragraph describing ellipses says, "otherwise,
> the expander would not be able to determine how many times the subform
> should be repeated in the output."  I've never understood precisely
> how Scheme macro systems decide how many expansions to do for a
> particular use of ellipses in the output template.  I can usually
> intuit what will happen, but I've never had a concrete understanding
> of the algorithm.  Would it be possible to expand on the algorithm
> here to make it absolutely clear?

Probably.  I've made a note to try to do this at some point.

> For example, in the definition of `case' that follows in that section,
> how are the ellipses that I've marked "question" below expanded?  Both
> `k' and `e2' are followed by ellipses in the pattern, and both appear
> in the template expression there.  How do we know to expand the
> template expression once per that particular part of the pattern?
>
>    (define-syntax case
>      (lambda (x)
>        (syntax-case x (else)
>          [(_ e0 [(k ...) e1 e2 ...] ... [else else-e1 else-e2 ...])
>           #'(let ([t e0])
>               (cond
>                 [(memv t '(k ...)) e1 e2 ...]
>                 ...             ;; question
>                 [else else-e1 else-e2 ...]))]
>          [(_ e0 [(ka ...) e1a e2a ...] [(kb ...) e1b e2b ...] ...)
>           #'(let ([t e0])
>               (cond
>                 [(memv t '(ka ...)) e1a e2a ...]
>                 [(memv t '(kb ...)) e1b e2b ...]
>                 ...))])))

Both k and e2 are directly followed by an ellipsis, and the pattern
containing the two of them is also followed by an ellipsis.  So both must
be followed by at least two ellipses in the output.  They are.  k and e2
are each directly followed by an ellipsis in the template, and the
template containing both is also followed by an ellipsis, the one you've
marked.  If you think about each ellipsis as a mapping operation, the
marked ellipsis maps a procedure that constructs one cond clause over a
list of a list of k's, a list of e1's and a list of a list of e2's.  The
ellipsis following k in the template maps the identity function over the
list of k's---in other words, it simply returns the list of k's.

> * In section 3.10, a definition is given for `identifier-syntax', but
> the first clause appears to be missing a call to
> `make-variable-transformer', which I've added here:
>
>    (define-syntax identifier-syntax
>      (syntax-rules (set!)
>        [(_ e)
>         (make-variable-transformer  ;; Should this be added?
>           (lambda (x)
>             (syntax-case x ()
>               [id (identifier? #'id) #'e]
>               [(_ x (... ...)) #'(e x (... ...))])))]
>        [(_ (id exp1) ((set! var val) exp2))
>         (and (identifier? #'id) (identifier? #'var))
>         (make-variable-transformer
>           (lambda (x)
>             (syntax-case x (set!)
>               [(set! var val) #'exp2]
>               [(id x (... ...)) #'(exp1 x (... ...))]
>               [id (identifier? #'id) #'exp1])))]))

Actually, the call to make-variable-transformer should not appear, so
that the expander never passes a set! expression to the transformer when
that form of identifier-syntax is used.

Kent Dybvig