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)
|
On Sat, 13 Aug 2005, [ISO-8859-1] Jens Axel Søgaard wrote: >felix winkelmann wrote: >> On 8/12/05, Michael Sperber <xxxxxx@informatik.uni-tuebingen.de> wrote: >> >>>The issue has come up in the discussion, but hasn't really been in the >>>focus yet: >>> >>>I'd like to suggest that compound expressions be represented by an >>>opaque type rather than by pairs. This would ensure a modicum of >>>abstraction, and would *really* make comprehensive the ability of all >>>syntax objects to carry location information. I've come to appreciate >>>this added layer of abstraction in PLT Scheme. > >Representing syntax-objects using normal lists does breaks the >abstraction, and I too prefer the extra layer of abstraction. For what it's worth, I prefer to have the syntax objects just be lists, amenable to manipulation with car, cdr, cons, etc. As Alan Perlis said, "It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures." There's an impulse to make everything a different type, which may arise in the idea of type checking as error checking, but distinguished types frequently diminish simplicity, conciseness, and convenience by requiring casting back and forth every time we do something, or else cause duplication of code and cognitive overhead by requiring their own set of primitives for manipulation and general work. When we can avoid introducing a new type, I think we should. A separate type for lists-used-as-syntax-transformers is, IMO, like a separate type for numbers-used-to-count-bottle-caps or numbers-used-to-count-seconds -- pretty pointless and detrimental to conciseness, cnvenience, and simplicity. It makes a nice "toy" example for someone writing about Ada or Pascal making a point about error checking as handled by type checking, but this is Scheme, and our data are not statically typed anyway. Or, as someone else put it.... We don't need no indirection We don't need no flow control No data typing or declarations Hacker, Leave those lists alone. Hey! Hacker! Leave those lists alone. All in all it's just a pure Lisp function call.... --Attribution Lost