| Here are some initial comments. Earlier, I sent most of these to Joo ChurlSoo, but I wanted to resend them to the discussion list.
| Immutability typically means the meaning of a variable (or in the case,
| the field of a record object) cannot be changed (mutated) once
| constructed, but you show examples where precisely this happens:
| ;; The `color' and `coordinate' are immutable automatic fields.
| (define-lambda-object (cpoint ppoint)
(x) y
(,color 'blue)
(,coordinate (lambda (i j) (set! x (+ i x)) (set! y (+ j y)))))
| Notice y is immutable, yet set! by the coordinate method.
| Joo ChurlSoo writes in response:
| I think personally it would be better for a method that cannot be
| accessed by others to have such a function irrespective of
| immutability.
| I'm not sure I know what that sentence means. If the value of a field can
| be mutated after construction, it is not immutable. Either the language
| should change (don't describe this as mutable vs. immutable) or the
| behavior should change (don't allow immutable fields to be mutated).

1.
The old specification for mutability was replaced in revised draft with new
one as follows:
The mutable fields can be modified, whereas any attempt to modify the values
of the immutable fields via mutators signals an error.
2.
A method of this macro is quite different from that of CLOS. The former is
defined within a define-lambda-object form and only the lambda-objects of the
group can access the method. On the contrary, the latter is defined outside
of defclass form and the method can be applied to every instance of all the
classes. I think the restrictiveness deserves that the methods should mutate
the values of the immutable fields and this gives flexibility to the macro.
3.
If you change the value of the coordinate field outside of the macro form
(suppose it is mutable), is it possible to mutate the value of the immutable
field y as before? Never. There must be its mutator. This also provides
another important restrictiveness.

| I am not able to reconcile the text about accessors and mutators being
| non-generative with the text saying "Each time define-lambda-object
| expression is evaluated, a new group is created with distinct <group>,
| <constructor>, and <predicate> procedures."
| Joo ChurlSoo writes in response:
| I mean the accessor and mutator are nongenerative, that is,
| even though the same define-lambda-object expression is evaluated twice,
| new accessor and mutator are not generated.
| You should include examples that demonstrate the generative or
| non-generative features of this proposal. (I am still confused about how this issue).

I'd like to know why DEFINE-RECORD-TYPE of R6RS must need the concept of
'nongenerative', and whether the concept is only for the predicate procedure
as a puzzle-like example in R6RS-standard-libraries, or practically for use of
the accessor and mutator of the same name, or for any others.
In this macro, the 'generativeness' is also applied to <group>, <constructor>,
and <predicate> procedures, but is concept does not apply to accessors and
mutators.

| Where are define-lambda-object forms allowed to appear in programs? In
| any context which allows definitions? Or any expression context? The
| name suggests only in definition context, but you also frequently refer
| to define-lambda-object forms as "expressions."
| Joo ChurlSoo writes in response:
| The lambda-object-defining form `DEFINE-LAMBDA-OBJECT' is a definition
| and can appear anywhere any other <definition can appear.
| I suggest the above be added to the document. I also suggest not referring to these definition forms as expressions.

In next revised draft, I will add the following:
The define-lambda-object form is a definition and can appear anywhere any
other <definition> can appear.

| I strongly dislike the use of parenthesis and the keyword UNQUOTE to
| disambiguate the field specs in this proposal. It makes it very
| difficult to look at a definition and infer what it means. I would
| suggest using informative keywords like MUTABLE, IMMUTABLE, REQUIRED,
| AUTOMATIC, etc.

Let's take an example.
1.
(define-lambda-object area
((width) 0)
((length) 0)
(,@rectangle (* width length))
(,@inner-circle (let ((radius (/ (if (< width length) width length) 2)))
(* 3.14 radius radius)))
(,@outer-circle (let ((radius (/ (if (< width length) length width) 2)))
(* 3.14 radius radius)))
(,set/add (lambda (x y) (set! width (+ width x)) (set! length (+ length y)))))

2.
(define-lambda-object area
((width mutable optional) 0)
((length optional mutable) 0)
((rectangle virtual) (* width length))
((inner-circle virtual) (let ((radius (/ (if (< width length) width length) 2)))
(* 3.14 radius radius)))
((outer-circle virtual) (let ((radius (/ (if (< width length) length width) 2)))
(* 3.14 radius radius)))
((set/add automatic) (lambda (x y) (set! width (+ width x)) (set! length (+ length y)))))

I admit the latter form would be better than the former to leave room for
extension of this macro.
But I think it is too verbose and doen't stand out conspicuously.

| The use of define-macro in the reference implementation detracts from the portability and will likely limit the adoption of this SRFI.

The use of define-macro is for groups against R6RS, and the use of
define-syntax is for groups for R6RS.