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

[Mark H Weaver <mhw@netris.org>]

Hi Marc,

Marc Nieper-Wißkirchen <marc@nieper-wisskirchen.de> writes:

> Am Mi., 14. Nov. 2018 um 20:11 Uhr schrieb Mark H Weaver <mhw@netris.org>:
>
>  > The `ellipsis?' procedure in psyntax.ss does exactly this, but it
>  > isn't available to user code. Re-implementing it is not possible
>  > without accessing internal details like the special identifier #{
>  > $sc-ellipsis }# and without resorting to hacks.
>
>  Surprisingly, it actually _is_ possible to do it portably in any
>  R[567]RS Scheme.  See 'match-check-ellipsis' near the end of
>  modules/ice-9/match.upstream.scm.
>
> This is why I wrote "without resorting to hacks". :-)

Heh, fair enough :)

>  > Thus, I would like to ask to add `ellipsis?' to the list of procedures
>  > exported by Guile (like `identifier?` or `bound-identifier=?` already
>  > are).
>
>  I'll need to think about how this could be exposed in the API.  It's not
>  as simple as exporting that procedure.  The 'ellipsis?' procedure is not
>  able to answer the question by looking only at the syntax object; it
>  also needs the macro-expansion environment 'r', which you do not have.
>  'identifier?' and 'bound-identifier=?' only need the syntax objects.
>
> I think I understand (please correct me if I am wrong): If we want to
> check whether `e' is the current ellipsis, we cannot simply look up
> the binding of `(datum->syntax e '$sc-expand)' because the wrap of `e'
> may be different than the wrap of the, say, `syntax-case' or `syntax'
> form in which `e' appears.

That's not what I meant, but anyway I've since discovered that the
problem I raised has an easy solution.  It turns out that Andy Wingo
added a fluid variable 'transformer-environment', private to
psyntax.scm, that allows us to retrieve the needed environment 'r' from
the dynamic environment.

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

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.

If you think of it this way, it should be clear why you can't tell by
looking at an identifier whether it is the current ellipsis in a given
lexical environment.  The information simply isn't there.

Anyway, as I wrote above, the good news is that we can get 'r' from the
dynamic environment.

I have a draft patch to add a unary predicate to (system syntax), but
I'd like to work on it a bit more before posting it.

     Regards,
       Mark