Opaque syntax objects Michael Sperber (12 Aug 2005 15:18 UTC)
Re: Opaque syntax objects felix winkelmann (12 Aug 2005 20:22 UTC)
Re: Opaque syntax objects Jens Axel Søgaard (12 Aug 2005 23:20 UTC)
Re: Opaque syntax objects Andre van Tonder (13 Aug 2005 00:25 UTC)
Re: Opaque syntax objects Michael Sperber (13 Aug 2005 07:46 UTC)
Re: Opaque syntax objects Jens Axel Søgaard (14 Aug 2005 19:45 UTC)
Re: Opaque syntax objects Andre van Tonder (14 Aug 2005 20:22 UTC)
Re: Opaque syntax objects bear (14 Aug 2005 17:48 UTC)
Re: Opaque syntax objects Keith Wright (13 Aug 2005 07:31 UTC)
Re: Opaque syntax objects Michael Sperber (13 Aug 2005 12:33 UTC)
Re: Opaque syntax objects Jens Axel Søgaard (14 Aug 2005 20:27 UTC)

Re: Opaque syntax objects Andre van Tonder 13 Aug 2005 00:24 UTC

On Sat, 13 Aug 2005, [ISO-8859-1] Jens Axel Søgaard wrote:

> Representing syntax-objects using normal lists does breaks the
> abstraction, and I too prefer the extra layer of abstraction.

This is often said, but I've never understood why people would think this.
Normally subtyping (see my earlier message) or genericity are regarded as
abstraction mechanisms, not abstraction-breaking mechanisms.  After all, people
don't normally say that generic + and * break the "integer" abstraction.  Why
should generic car/cdr be different here?

> Keeping this abstraction doesn't make destructuring significantly more
> impractical. Destructuring arguments using the pattern matching
> capabilities of syntax-case is unchanged with both representations,

I feel strongly that pattern matching should be library syntax.  For this
proposal, I personally prefer a design based on a small procedural core +
[quasi]syntax, rather than a rather complex special form.

> and
> in the case were it is neccessary to use normal Scheme operators, most
> often a call to syntax->list, which turns a syntax-object representing a
> list into a list of syntax-objects, is enough to solve the problem.

This can entail a rather expensive performance hit.

Cheers
Andre