[Top][All Lists]

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

Re: Feature request: Expose `ellipsis?' from

From: Mark H Weaver
Subject: Re: Feature request: Expose `ellipsis?' from
Date: Thu, 15 Nov 2018 05:59:06 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)

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

>  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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]