[R6RS] Rationale for INIT! clause

[Michael Sperber]

Many thanks for the comments, Will!

One issue stands out:

William D Clinger <will at ccs.neu.edu> writes:

> 9)  I would not be averse to dropping the init! <record clause>,
> but I can see why it is useful and how it would encourage people
> to write code that can be compiled more efficiently.

This is a hint that we haven't motivated the INIT! clause
sufficiently.  Kent has explained this in general, but a more specific
rationale might help.

Generally, the initialization mechanism and INIT!, taken together,
provide an abstraction over a very common pattern of record
construction.  Here's an example:

(define (make-foo a b c)
  (let ((the-foo (really-make-foo a #f (+ b c) c)))
    (register! the-foo)
    the-foo))

... where REALLY-MAKE-FOO is the underlying "primitive" constructor
(typically the one returned by RECORD-CONSTRUCTOR).  So far, nothing
new.

My personal experience suggests that this pattern---making use of
non-standard field initialization or "registering" the record
somewhere---occurs in a large percentage (somewhere betweeen 30%-40%,
I'd say) of record definitions, which, IMHO, justifies encoding the
pattern in the abstraction.

Moreover, to use this together with a DEFINE-TYPE-like facility
without the INIT! clause, you need to do this:

(define-type (foo really-make-foo foo?) (a b c)
  ...)

(Likewise if you don't have the initialization mechanism.)

This means that the name of the "actual constructor" MAKE-FOO that
programs are supposed to use is no longer part of the DEFINE-TYPE
form---whether implicit or explicit.  The programmer needs to invent
an intermediate throwaway name.  Moreover, conservative extensions to
DEFINE-TYPE that do something with the names ("co-export," but also
extensions to support keyword arguments and so on) don't have access
to the actual constructor.

Arguably, the same holds true for accessors and mutators, where one
might have to perform synchronization or some other form of
computation.  But, in my experience, it is much rarer there.  (And
even rarer for the predicate.)

Does this help motivate INIT! ?

We probably need to add a Design Rationale explaining stuff like this,
and possibly add one or two issue bulletts.  I'll see what I can
figure out later today.

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