[plt-scheme] immutable vector and box literals

Paul, there are whole hosts of data structures, algorithms, and
programming languages that operate solely on immutable data.  Consider
reading "Purely Functional Data Structures" by Chris Okasaki, a book
about all the data structures and efficient implementations of them
that can be done without any mutation.  It's quite comprehensive.
Mutation does not mean no computation or new information, it just
means that new information comes by constructing new data structures
rather than by mutating old ones.

As a personal anecdote, I worked at Sun on the Fortress interpreter.
The first prototype was in OCaml and we didn't use a single mutable
data structure or variable beyond the mutable values in the Fortress
language itself.  Even large, complex programs can be written without
mutation.

And in a mostly-immutable context, it's not that hard to write "mcons"
when you need the occasional mutable value.  Immutability by default
does not mean we've thrown it all out, nor will we ever.

I hope you reconsider the new changes to PLT Scheme, it'd be a shame
for the community to lose a programmer who's obviously so passionate
about the art of programming and our language in specific.

--Carl

On Jan 29, 2008 11:44 PM, Paul Schlie <schlie at comcast.net> wrote:
> (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.