Email list hosting service & mailing list manager

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 Jens Axel Søgaard 14 Aug 2005 19:44 UTC

Andre van Tonder wrote:
> 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?

This is largely a matter of taste, but I don't think of syntax as lists,
where as I think of integers as numbers.

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

The purpose of the do-primes example was to show that simple
destructuring is possible without using syntax-case.

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

What is "rather expensive"?

--
Jens Axel Søgaard