>The values R, X_0, Y_0 are meant to be constants outside the record, are they?

Yes. The record describes a set of points around some point fixed at
record creation time.

>Could you redescribe your model, e.g. withsome Scheme code and with less "imagination"? :)

Not sure I can do that with Scheme code.
But what I am talking about is essentially "protected" in C++.
When seen as an instance of the parent class A, the points X and Y
obey an invariant.
However, when class A is a parent class of some child class B, this
rule becomes:
X and Y obey an invariant, which is nevertheless different for each
value of some Z defined in B, and this Z might be mutable.
So when Z is mutated using set-Z! in the child class B, it has to
change the invariant, which is impossible using only class A's public
interface.
(And also adjust X and Y, but that is doable using A's public methods.)

On Mon, 31 Oct 2022 at 21:09, Marc Nieper-Wißkirchen
<xxxxxx@gmail.com> wrote:
>
> Am Mo., 31. Okt. 2022 um 13:54 Uhr schrieb Vladimir Nikishkin
> <xxxxxx@gmail.com>:
> >
> > >An updater of a child record type should not have to deal directly
> > >with updating the fields of its parent (because would breach an
> > >abstraction barrier); instead, an updater of a child record type
> > >should call a corresponding updater for a parent record type.
> >
> > I think this might not be possible in the general case. Or, rather,
> > it might depend on whether we want "non-virtual" or "virtual"
> > inheritance in r7rs-large.
> > (Not sure "virtual" is the correct term.)
>
> We must be careful with these terms coming from a classical OOP model
> like C++ or Java.  As I explained in [1], the record system of Scheme
> is much simpler and does not implement OOP (but can be used to
> implement an OOP layer).
>
> > A (very contrived) counterexample would be a struct which describes a
> > point on a plane
> > which has coordinates X and Y, but cannot leave a disc of radius R
> > with the center in some point X_0, Y_0.
> > There might be some algorithms which work with such a point.
> > R, X_0, Y_0 are set at construction only, X and Y have set-X! and set-Y!
> > Imagine drawing the bottom of a cup standing on a table.
>
> The values R, X_0, Y_0 are meant to be constants outside the record, are they?
>
> >
> > Now we want to extend this point to work on a certain Z(X,Y) curve,
> > parameterised by the length of the segment ɑ.
> > Imagine lifting a cup off the table and placing it at some other point
> > on the table,
> > the bottom of the cup is the original struct.
> >
> > We want the algorithms to keep working for the "bottom of the cup",
> > and the X²+Y² <R²  to be
> > preserved. But in order to describe this case, the method set-ɑ! of
> > the child object would
> > necessarily have to mutate X_0, Y_0, X, Y (but not R).
> >
> > I understand that this example is very contrived, but I really suspect
> > that restricting a child's access to
> > parent's protected fields is unnecessarily limited.
>
> I fear I don't understand your example in detail so that I could give
> a satisfactory answer.  Could you redescribe your model, e.g. with
> some Scheme code and with less "imagination"? :)
>
> --
>
> [1] https://srfi-email.schemers.org/srfi-237/msg/20934836/

--
Yours sincerely, Vladimir Nikishkin
(Sent from GMail web interface.)