Re: [Scheme-reports] What happened to (UNQUOTE <expression> ...)

[Ray Dillinger <bear@x>]

On Sun, 2011-04-24 at 11:12 +0900, Alex Shinn wrote:
> On Sun, Apr 24, 2011 at 9:04 AM, Andre van Tonder <andre@x> wrote:
> > and (unquote-splicing <expression> ...)?
> >
> > In other words, more than one argument to UNQUOTE(-SPLICING).
> >
> > These were added in R6RS to fix some well-known shortcomings of quasiquote.
> > The issue and the R6RS solution had been known for a long time and were
> > discussed by many authors for many years before being adopted.
> > I for one liked the change and probably have code that depends on it.
> 
> It looks reasonable to me, but could you point us
> to the discussions or rationales?
> 
> Specifically, how is (unquote-splicing a b c) different from
> ,@a ,@b ,@c ?

I am sort of under the impression that this change was and is a subtle
mistake.

The problem happens in composing QUASIQUOTE forms where the current
environment is different for each form.  

In other words, if I have a QUASIQUOTE that expands into a function
definition containing another QUASIQUOTE, then inside the interior
QUASIQUOTE form it is not obvious which environment an UNQUOTE or
UNQUOTE-SPLICING form refers to.  

Regarding UNQUOTE and UNQUOTE-SPLICING as forms of EVAL with a 
single-argument case sugared, they suffer from the same problems that 
single-argument EVAL suffered from.  I consider it reasonable that a
second argument ought to specify an environment rather than another form
to evaluate, because that's the semantics we eventually agreed on for
the base form of EVAL.  Given the proposed semantics of additional
arguments as additional forms to evaluate (which was a common extension
to EVAL back in the day) deprives us of the "natural" place for an
environment specifier, and results in code that will break the same 
way if and when these additional EVAL forms get fixed.  

IMO, some Scheme Committee will inevitably fix this eventually because
sooner or later it will become clear that we have failed to get rid of
the problematic single-argument EVAL completely, until this is done. 
Having made our choice on EVAL, requiring environment specifiers for 
UNQOUTE and UNQUOTE-SPLICING is a design consistency issue.

				Bear



_______________________________________________
Scheme-reports mailing list
Scheme-reports@x
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports