[r6rs-discuss] What does the "new" procedure in the procedural records library do?

From: Abdulaziz Ghuloum <aghuloum>
Date: Sat, 12 May 2007 01:42:52 -0400

Greetings,

In page 14 of R5.92 (standard libraries), there is a
description of the "protocol" that determines how to compute
the contents of the parent field. It says:

   A simple /protocol/ in this case might be written as follows:
   (lambda (p)
     (lambda (x1 ... v1 ...)
       (let ([new (p x1 ...)]) ;;; minor typo there
         (new v1 ...))))

It is not clear what *exactly* this "new" procedure does.
When exactly is the record constructed? Is it before the
chain of parent constructors is called, or after? Does "new"
return a value, multiple values, or does it side effect the
already made record? What happens if you call "new" more than
once?

Also, is there any specific order in which the values returned
by the "protocol" procedures are called? Or is each rtd in an
inheritance hierarchy responsible for its own fields
regardless of its parents and children? Also, is that (lambda
(p) ---) called once, when make-record-constructor-descriptor
is called, is it called afresh every time a new record object
is constructed?

Up in that page: ``The procedure returned by /protocol/ may
take any number of arguments but must call /new/ with the
number of arguments it expects and return the resulting record
instance.'' This seems to suggest that the record is already
constructed before the values of its fields are computed (this
is not good: play with call/cc a bit and you can mutate
immutable fields; or solve it by making record construction
much more expensive). It also does not match very well with
how the rest of the objects (pairs, strings, vectors,
procedures, ...) are constructed; e.g. by initialization, not
mutation.

Thank you.

Aziz,,,

PS. I realize this is coming very late in the game. Oh well.
PS2. I would take ``this is all unspecified, do as you want''
for an answer. In that case, the "return the resulting record
instance" bit should probably go away.
Received on Sat May 12 2007 - 01:42:52 UTC