[Scheme-reports] EVAL Andre van Tonder (23 Apr 2011 23:47 UTC)
[Scheme-reports] What happened to (UNQUOTE <expression> ...) Andre van Tonder (24 Apr 2011 00:04 UTC)
[Scheme-reports] Are generated toplevel definitions secret? Andre van Tonder (24 Apr 2011 00:15 UTC)
[Scheme-reports] COND, CASE, AND, ... macros are buggy Andre van Tonder (24 Apr 2011 00:24 UTC)
[Scheme-reports] Buggy definition of BEGIN Andre van Tonder (24 Apr 2011 00:33 UTC)
Re: [Scheme-reports] Buggy definition of BEGIN Jussi Piitulainen (24 Apr 2011 06:55 UTC)
[Scheme-reports] Restrictions on internal BEGIN? Andre van Tonder (24 Apr 2011 01:45 UTC)
Re: [Scheme-reports] Restrictions on internal BEGIN? Jussi Piitulainen (24 Apr 2011 07:20 UTC)
[Scheme-reports] Toplevel import scoping Andre van Tonder (24 Apr 2011 02:02 UTC)
Re: [Scheme-reports] Toplevel import scoping Alex Shinn (24 Apr 2011 02:44 UTC)
Re: [Scheme-reports] Toplevel import scoping Aaron W. Hsu (29 Apr 2011 17:11 UTC)
Re: [Scheme-reports] Toplevel import scoping Aaron W. Hsu (29 Apr 2011 17:10 UTC)
Re: [Scheme-reports] Are generated toplevel definitions secret? Andre van Tonder (24 Apr 2011 15:53 UTC)
(missing)
(missing)
(missing)
Re: Are generated toplevel definitions secret? Aaron W. Hsu (24 May 2011 18:51 UTC)
Re: [Scheme-reports] Are generated toplevel definitions secret? Sztefan Edwards (25 May 2011 14:32 UTC)
Re: Are generated toplevel definitions secret? Aaron W. Hsu (25 May 2011 20:03 UTC)
Re: [Scheme-reports] Are generated toplevel definitions secret? Perry E. Metzger (07 Nov 2011 18:40 UTC)
Re: [Scheme-reports] Are generated toplevel definitions secret? Perry E. Metzger (07 Nov 2011 18:45 UTC)
Re: [Scheme-reports] What happened to (UNQUOTE <expression> ...) Andre van Tonder (24 Apr 2011 03:10 UTC)
Re: [Scheme-reports] What happened to (UNQUOTE <expression> ...) Ray Dillinger (24 Apr 2011 16:20 UTC)
Re: [Scheme-reports] EVAL Alex Shinn (24 Apr 2011 02:10 UTC)
Re: [Scheme-reports] EVAL John Cowan (24 Apr 2011 06:56 UTC)

Re: [Scheme-reports] What happened to (UNQUOTE <expression> ...) Ray Dillinger 24 Apr 2011 16:19 UTC

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@het.brown.edu> 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@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports