Re: scheme seems neater

From: Anton van Straaten (anton_at_appsolutions.com)
Date: 04/08/04 

Date: Thu, 08 Apr 2004 21:03:04 GMT

Jeff Dalton wrote:
> "Anton van Straaten" <anton@appsolutions.com> writes:
...
> > For example, in Bawden & Rees' 1988 paper "Syntactic Closures", after
> > describing the various scenarios which violate hygiene and referential
> > transparency, the authors summarize it like this:
> >
> > "All of these problems are consequences of the fact that macros are
> > oblivious to the lexical scoping of the program text that they are
> > constructing. Any macro facility that proposes to address this
shortcoming
> > also has to take into account that sometimes the macro writer needs
explicit
> > control over scoping."
>
> Ok, but that's "explicit control over scoping", which syntactic
> closures provides. Some other Scheme macro systems don't, though.
> They do what's thought to be the right thing, rather than giving
> control.

All of the so-called hygienic systems (afaik) support referential
transparency by default, meaning (in this context) that you can write a
macro without taking special steps, expand it anywhere, and it will behave
the same way, depending only on its explicitly provided inputs. To achieve
this, you need "hygiene", and this is the sense in which I consider hygiene
a basic requirement. The broader goal is to achieve the sorts of semantic
properties from macros that can be relied on in the rest of Scheme.

> > It's this desire to integrate with lexical scoping, which also implies
> > referential transparency, that in Scheme at least, drives the design of
> > these macro systems. Hygiene is just a really basic issue you have to
take
> > care of in order to achieve that.
>
> But the advent of hygienic macros was what made this a big deal.
> Before that, people were happy to implement and use ordinary Lisp
> macro systems in Scheme.

Part of the problem with this discussion is that the term "hygienic macros"
begs the question. I think it puts a misleading focus on what amounts to an
implementation detail, which becomes apparent when you examine what the
hygienic systems actually do.

> > To some extent, the term "hygienic macro" focuses on a particular
technical
> > requirement of the implementation of these macro systems, and may cause
the
> > larger context to be missed, as in "geez, you designed a whole
complicated
> > new macro system just to avoid unintended capture??", when there's a lot
> > more to it than that.
>
> What's the lot more?

The fact that the macros are semantically sound with respect to the target
language. I don't think you can claim that hygiene means this, but it's
fair to say that you need hygiene to implement this.

Then, in systems more flexible than syntax-rules, like syntax-case, the "lot
more" is the ability to capture variables and introduce capturing variables
but in a way in which explicit control of lexical scope is provided. This
explicit scope control is not required merely to be "hygienic", but it is
required to provide a macro system of at least equal power to defmacro which
integrates with the target language's semantics.

> For me, and I think for quite a few other people as well, the
> preceived complexity is almost all about hygiene and avoiding
> all the different cases of unintentional capture.

I don't deny that perception exists, but nevertheless that perception is
focused around what is essentially an implementation detail, and misses the
bigger picture.

To attempt a hopefully helpful analogy, it would be like calling values in
Lisp or objects in Java "pointer-free values", because they don't allow
C-style pointer errors. It's an accurate enough description, in context,
but it doesn't actually give much insight into the properties of such
values. Focusing on "hygiene" seems to be similarly misleading.

> > It sounds like you're talking about syntax-rules. In that case, since
> > standard Scheme is not allowed within syntax-rules macros, you do indeed
> > have a different language, one which is guaranteed to interact correctly
> > with the lexical structure of the target language.
>
> Right, and that's the sort of thing I had in mind above when saying
> some systems didn't give you control, they just did what was thought
> to be the right thing

Syntax-rules doesn't have to guess what the right thing is, since it never
allows variable capture under any circumstances, short of cheating and using
it to redefine binding operators so you can "simulate" capture. As a
result, syntax-rules always does the right thing, but has limitations in
what it can do.

> (though if I remember correctly, syntax-rules
> had some kind of clause that gave you some control).

I can't think of anything like that.

> Also, syntax-case allows ordinary Scheme, but it has some other
> stuff as well. Patterns, template-filling. Do they become
> available forordinary list processing? It doesn't look like
> they do.

Those constructs operate on a specific data type, the syntax object. If you
want to process lists with them, you'd have to convert them to syntax
objects and back, e.g. here are some ordinary function definitions of car
and cdr using syntax-case and associated functions to destructure the
provided list:

(define (kar x)
  (syntax-object->datum
    (syntax-case (datum->syntax-object #f x) ()
      ((xar xdr ...) (syntax xar)))))

(define (kdr x)
  (syntax-object->datum
    (syntax-case (datum->syntax-object #f x) ()
      ((xar xdr ...) (syntax (xdr ...))))))

(kar '(3 2 1)) => 3
(kdr '(3 2 1)) => (2 1)
(kar (list 3 2 1)) => 3
(kdr (list 3 2 1)) => (2 1)

(And yes, those conversion functions are way too verbose!)

The point is, they're essentially ordinary Scheme constructs which you can
use in ordinary code. Within the syntax-case macro itself, you also use
ordinary code except in the "pattern" position. The only constraint on the
"template" position is that it must return a syntax object; other than that,
it's ordinary Scheme code.

> And macros are written using pattern-matching and
> templates (syntax-case and syntax), not ordinary Scheme,
> though ordinary Scheme can be mixed in.

That's a choice. You only use the syntax-case form if you want to match
patterns. However, the syntax-case system as a whole is bigger than that.
You can write macros completely procedurally without using the syntax-case
form, still making use of syntax objects. You do at some point need to use
a syntax object constructor, like 'syntax', quasisyntax, or
datum->syntax-object, to create syntax objects, but you can use ordinary
Scheme and convert back and forth and do whatever you like. You could write
such macros in defmacro style if you wanted to, using quasisyntax and
related operations that correspond directly to quasiquote, but for syntax
objects.

Perhaps the biggest problem with the accessibility of syntax-case is that
it's usually presented in much more abstract terms.

Anton

Relevant Pages

  • Re: scheme seems neater
    ... >> hygiene is a goal. ... Any macro facility that proposes to address this shortcoming ... Some other Scheme macro systems don't, ... and an abstract data type for syntax that supports richer ...
    (comp.lang.lisp)
  • Re: scheme seems neater
    ... > Lisp defmacro-style macros were not as acceptable for Scheme as they were ... macro system for Scheme was partly that defmacro -- which was ... language (without hygiene), I already had it. ... > reasons that the CL community is uninterested in other macro systems, ...
    (comp.lang.lisp)
  • Re: scheme seems neater
    ... >> Scheme is a macro system which respects that structure and integrates ... >> about how a macro is expected to interact with its lexical context. ... I'm trying to express that hygiene is ... requirement of the implementation of these macro systems, ...
    (comp.lang.lisp)
  • Re: How to think about Scheme macros, was Re: scheme seems neater
    ... Given syntax-case, syntax-rules is theoretically redundant, but when all you ... and makes the macro a ... To be more PC, lexically-aware macros could ... But as you've gathered, I would emphasize lexical scope over hygiene, ...
    (comp.lang.lisp)
  • Re: scheme seems neater
    ... >> what amounts to an implementation detail, ... I agree it's also a property of a macro system. ... user of a hygienic macro system doesn't have to worry about hygiene. ... The reason syntax-case can look impenetrable to the uninitiated has to do ...
    (comp.lang.lisp)
Loading