This page is part of the web mail archives of SRFI 72 from before July 7th, 2015. The new archives for SRFI 72 contain all messages, not just those from before July 7th, 2015.
On Sat, 13 Aug 2005, [ISO-8859-1] Jens Axel Søgaard wrote:
>felix winkelmann wrote:
>> On 8/12/05, Michael Sperber <sperber@xxxxxxxxxxxxxxxxxxxxxxxxxxx> 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