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 bear 14 Aug 2005 17:47 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