Re: Feature request: Expose `ellipsis?' from psyntax.ss

[Mark H Weaver]

Hi Marc,

Marc Nieper-Wißkirchen <address@hidden> writes:

>  > So what we actually need is a procedure of
>  > two arguments: `(ellipsis?  e ctx)' returns `#t' if the identifier `e'
>  > is the current ellipsis in the lexical environment of the identifier
>  > `ctx'.
>
>  Hmm.  I don't actually see a need for the second argument, do you?  I
>  can't think of a case where I'd want to 'e' to be different from 'ctx'.
>
> Let's assume we are writing a macro that reimplements syntax (or some
> variation thereof) and which has to check whether identifiers are
> ellipses. For example, the following could be given:
>
> (with-ellipsis e
>   (my-syntax a e)
>  
> Now, this could be a result of a macro expansion and e could carry
> different marks than with-syntax or my-syntax. This is why I have been
> thinking that one also needs the lexical context of my-syntax and not
> only the context of e.

I don't see what problem would be caused by 'e' carrying different marks
than 'my-syntax'.

As far as I can tell, in the end, the two instances of 'e' above will
effectively be compared to one another using 'bound-identifier=?'.  They
must have the same name and the same marks to match.  The marks on
'my-syntax' are irrelevant here.

Operationally, when (with-ellipsis e (my-syntax a e)) is expanded, 'e'
will be added to the macro expansion environment as the innermost
binding of the ellipsis identifier, and then (my-syntax a e) will be
expanded within that new expansion environment.  That is the expansion
environment that will be consulted by the 'ellipsis-identifier?'
predicate to find the current ellipsis identifier, which is compared
with its argument (after stripping its anti-mark) using
'bound-identifier=?'.

>  The issue I raised has to do with the fact that syntax-objects do not
>  contain their lexical environments.  The 'wrap' of a syntax-object
>  essentially only contains a set of deferred substitutions to be applied
>  to the identifiers within the syntax object, if they end up outside of a
>  quoted datum in the expanded code.  The wrap is primarily an efficiency
>  hack, but also enables the implementation of 'datum->syntax'.
>
>  If we eliminated the efficiency hack, and also 'datum->syntax', we could
>  implement identifiers more simply as a record containing two symbols:
>  the original symbol, and the symbol after all substitutions have been
>  applied.  Identifiers found within quoted datums would be interpreted as
>  their original symbols, and identifiers found anywhere else would be
>  interpreted as the symbols with the substitutions applied.
>
> Thanks for the explanation. I have been toying with my own
> implementation of the syntax-case system. In my implementation the
> (shared) lexical environments are part of the wraps (so the
> identifiers are in some way self-contained).

Interesting.  Are locally-bound macro transformers included in those
lexical environments?  If so, how do you implement 'letrec-syntax'?

> Will ellipsis? also work outside of macros? Say, what would be the
> result of the following (run-time) code?
>
> (with-syntax e
>   (ellipsis? #'e)

No, this is an error.  Like 'syntax-local-binding', the
'ellipsis-identifier?' predicate must be called within the dynamic
extent of a macro transformer call by the macro expander.

> P.S.: By the way, the module (system syntax) and in particular the
> procedure syntax-local-binding has already helped me a lot because I
> needed to attach extra information to symbols and Guile doesn't (yet)
> support Chez's define-property (well, this would be another feature
> request).

Hmm.  Can you tell me more specifically how you are using
'syntax-local-binding' to accomplish this?  As the Guile manual warns,
those interfaces are subject to change in future versions of Guile, and
therefore it is best to avoid them where possible.

     Regards,
       Mark