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