This page is part of the web mail archives of SRFI 65 from before July 7th, 2015. The new archives for SRFI 65 contain all messages, not just those from before July 7th, 2015.
I recommend withdrawing SRFI 65 "define-immutable: A Syntax to Define Identifiers With Immutable Values". My opinion is that there's a good idea in here that one day will be useful when it can be developed, but it has failed to come to fruition within the discussion period. Thus I suggest backing off from this SRFI, taking another look at the idea, and coming back at a later time with another SRFI proposal if a solution can be found. One essential difficultly, as I see it, is with what the scope should be of saying the expression is evaluated "only once". Typically with DELAY, "only once" means only once within a particular run of a program. I can see two issues with having the scope of "evaluating the expression only once" to be "a particular run of a program". We'd like to allow a sufficiently clever optimizing Scheme compiler to partially evaluate expressions when it can -- perhaps even at the time a module is compiled. But the scope of "only once" being "a run of the program" means that any evaluation of the expressions must be delayed until the program actually runs, even when that is not necessary or useful. In concurrent programming in the presence of threads, "only once" most likely necessitates synchronizing access on each reference to the identifier. (See The "Double-Checked Locking is Broken" Declaration, http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html) To go off in another direction, I could see that a specification for lazy evaluation in the presence of threads would be useful, but hardly seems revelant when the goal is simply to allow identifiers to be defined in any order. However, with the scope of "only once" being "a run of the program", the evaluation of the identifier's expression is delayed until first use. Thus simply using a module that exports identifiers defined with DEFINE-IMMUTABLE in a concurrent program, without synchronizing access to the identifiers, is likely to lead to a race condition in the evaluation of FORCE and unpleasant bugs for the user. To meet the goal of allowing identifiers to be defined in any order, a more useful scope might be a particular module or lexical boundary: so that the expressions would have been evaluated by the time that they were imported into another module. My intuition is that forcing the expressions to be evaluated at such a specified boundary (for example, upon export from a module) would address both problems. This would allow DEFINE-IMMUTABLE identifiers to be safely used in a concurrent program, and for expressions to be precomputed by a sophisticated enough Scheme compiler. However there is no proposed mechanism to do do this yet, much less a reference implementation, and so I expect this would be a different SRFI proposal. Andrew Wilcox