[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Initial comments

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.

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). 

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). 

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. 

David