A generic immutable property interface is described here: ImmutableData.
Do we add an optional way to copy data to immutable one (and back) ?
Replying to [comment:1 arcfide]:
Is this something that any Schemes have right now?
Hello Aaron,
The rationale is instead to have immutable and mutable versions for each kind of data (like cons / mcons) to have orthogonal recursive copy functions to "toggle the mutability flag" (See R5RS "Storage Model" section) or any other mean implementation may choose.
A predicate for mutability checking is associated with these functions. Racket already has an 'immutable?' generic function and one could write recursive conversion functions easily with the help of immutable and mutable version of each kind of data, but IMHO it helps to view mutability as an orthogonal property and not to have 2 constructors versions for each kind of data.
I agree that this has some appeal, but I do not see any justification for this in the standard since I do not see any implementations taking this approach already. It feels far too uncharted for me to be fairly comfortable about this in WG1.
You are right and I agree with you, though the WG is a good place for debate. I am lacking good discussions about having an immutability concept orthogonal to datatype to see more clearly benefits/drawbacks of this idea. There is the SRFI-65 which is alike but it is not popular and has been withdrawn.
WG1 voted to take no action.
Is this something that any Schemes have right now?