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