This page is part of the web mail archives of SRFI 100 from before July 7th, 2015. The new archives for SRFI 100 contain all messages, not just those from before July 7th, 2015.
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).
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 ornon-generative features of this proposal. (I am still confused about how this issue).
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.
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.The use of define-macro in the reference implementation detracts from the portability and will likely limit the adoption of this SRFI.