[R6RS] Implicit naming for record procedures

[Michael Sperber]

Marc Feeley <feeley at iro.umontreal.ca> writes:

> But I think the record definition form should allow both implicit
> and explicit names, so everyone can be happy, right?

It doesn't work that way.  At the risk of sounding pompous:

> Programming languages should be designed not by piling feature on
> top of feature, but by removing the weaknesses and restrictions that
> make additional features appear necessary.

The beauty of proposals like SRFI 9 or Will's proposal or PLT's
DEFINE-STRUCT or Chez's DEFINE-RECORD is that they provide a clear
layering:

There's a lower layer for handling the mechanisms of creating record
types and the various associated procedures, and then there's a
mechanism on top that takes a certain view as to the common case.  The
common lower layer ensures that people can build their own
abstractions for what their common cases are while staying compatible
with the others.  Enforcing conventions is nice but secondary.  Will's
proposal, PLT's DEFINE-STRUCT, and Chez's DEFINE-RECORD are just
fairly simple macros built on these layers.  They don't do everything
one could want to do with macros, but they handle the common case in a
simple manner.  Having one giant do-it-all form for all the various
common cases also means that, if it doesn't cover absolutely all the
uses, if somebody does come along and wants to do one detail in a
different way, she's going to have to redo it all.

So, while I personally prefer SRFI 9 to implicit-naming
facilities---as long as there is a lower layer on top of which the
"common form" is built exist, I'd still be more amenable to something
from the above list rather than an all-singing all-dancing form.  In
either case (simple implicit-naming or all-singing all-dancing) I'd
probably build my own record-definition form (which would just adhere
to SRFI 9 or SRFI 57) for my own programs, and that seems fine to me.

-- 
Cheers =8-} Mike
Friede, V?lkerverst?ndigung und ?berhaupt blabla