Re: Interesting Behavior of 'append!' In Local Context

[Eric McDonald <mcdonald@phy.cmich.edu>]

Stephen Compall wrote:

>     ;; and "your code"
>     (clcase (+ 21 21)
>       ((42) 'its-42)
>       ((84) 'its-84))

[snip]

>> Fair enough. I certainly wouldn't mind seeing "detect and inform"
>> implemented for this case. As a comparison: if I'm writing C or C++
>> code, and I try to modify a const value, the compiler is generally going
>> to let me know.
> 
> A better comparison would be whether the C compiler prevents you from
> mutating a literal through a pointer whose constness has been cast away,
> in a separate compilation unit.

Well, I think that you generally have one C compiler invocation per
compilation unit, and so you lose track of some information between
compilation units. In the cases that we're talking about, everything is
taking place in the same Scheme interpreter session, and so you
shouldn't have to cope with that kind of loss of information...?

Admittedly, it might be difficult to ascertain constness of the list
containing Adams Constant in the above example. But, I think for more
straightforward cases (the majority, perhaps?), such as original
example, I can't imagine that it would be such a difficult task. Andy's
reply seems to concur.

> MzScheme's making pairs immutable by default is a reflection of the
> style of the larger Scheme community, which generally eschews mutating
> list structure in favor of a more functional style.

Sure, agreed. I know that I'm working with a functional language and so
it shouldn't be surprising that functional style is encouraged. I've
actually had quite a bit of experience with Mathematica [1], and so I'm
no stranger to this style of programming. However, there are times when
sequential and iterative logic are more convenient or maintainable, and
since Scheme does provide facilities for that kind of logic, I think I
would be foolish to ignore them. And, when one does iteration, instead
of recursion, it is often more natural to mutate list structure rather
than compose it.

Thanks for the discussion,
  Eric

[1] IIRC, Mathematica provides Protect[] and Unprotect[] for constness
control, and Unevaluated[] (and other mechanisms I can't presently
recall) for evaluation suppression. The orthogonality of these sets of
mechanisms is probably what led to my confusion about how Scheme's quote
works.