[plt-scheme] immutable vector and box literals

(sorry, my last post on the subject, I promise)

Although I can see the logic to disallowing the mutation of literal data
(mostly as no mechanism exists to subsequently reference it, as -set! is not
specified to return the mutated value), I can't see disallowing the mutation
of initializing literal data assigned to a symbol/variable; as to disallow
something as basic as the following to enable the mutation of a shared
variable data.

 (define x #(1 2 3))

 (if <something> (vector-set! x 0 4))

 => vector-set!: expects type <mutable vector> as 1st argument, given:
    #(1 2 3); other arguments were: 0 4

seems just as unproductive (IMHO) as specifying lists as being immutable and
incompatibly distinct from their previously default mutable counterparts,
and further turns scheme into something less of a programming language, and
into something more like a specification language (which I guess is fine if
one believes that all information can be specified functionally apriority as
required, but in my obviously less than perfect experience, it is generally
not reasonable in practice to specify programs based entirely on single
static assignments/references as seemingly implied).

by making lists, vectors, etc immutable, they have in effect become merely
syntactic conventions not true data types; and thereby forcing the use of
user defined structs/hashtables to be the real data types, and thereby
necessitating a whole slue of functions to be redundantly defined to operate
on the real data, as the use of lists and vectors as variable data have been
lost; thereby not only as no problem been solved, the language as a whole is
less useful and more cumbersome in general.

as exemplified by most all other programming languages, constant/immutable
data tends to be explicitly specified by exception not by default for good
reason as it seems to make imminently more sense for a programming language,
as if nothing is presumed necessary to be mutated by default, then it
seemingly implies that all necessary information is available at compilation
to produce the sought after result (which isn't true in general) and thereby
execution need never literally occur (and likely why truly pure functional
languages tend not be embraced for general purpose programming tasks; and by
hardware analogy, why CPU's are generally a more cost effective solution
than a literal functional hardwired network equivalent to that which may be
executed serially/iteratively by a CPU).

thereby personally, if the primary value of immutable data is one of being
able to segregate read-only immutable data for the purposes of improving
execution/storage efficiency, I'd strongly tend to prefer all data be
presumed mutable by default, and specified immutable by exception when of
known or speculative value to do so; but unfortunately (IMHO) scheme has
already seemingly begun it's transformation into a more purely functional
language at the expense of programmatic flexibility, and don't suspect
there's much to be done about it at this relatively late date in the
process.

I apologize voicing a likely unpopular opinion, but felt compelled to voice
concern for the loss of what was once my favorite language, if for no other
reason as it allowed a multitude of programming styles without attempting to
enforce one over another, and allowed there flexible combination as desired
without unnecessary pain.

> Matthew wrote:
> As of 3.99.0.10, vector and box literals are immutable:
> 
>  > (vector-set! '#(1 2 3) 0 0)
>  vector-set!: expects type <mutable vector> as 1st argument....
> 
> Along the same lines, `syntax->datum' produces immutable vectors and
> boxes instead of mutable ones.
> 
> I doubt that this change will be controversial, but it may be
> interesting to check whether anyone is using mutable literals as a back
> door to share across instantiations of a module.
> 
> Matthew