[plt-scheme] immutable vector and box literals

Paul, Carl and Robby have given you a good answers. Let me try to  
rephrase what they are saying for someone like you:

PLT Scheme will continue to serve as the host of as many programming  
styles as you can imagine. Yes, you will have to use mcons instead of  
cons, mcar instead of car, and so on. No I am not arguing that this  
isn't inconvenient. But we imagine that is a very minor cost for the  
benefits that we are seeking from this conversion. In particular, we  
believe that the programs become clearer because they emphasize to  
the reader which programming style they are employing (as opposed to  
sneaking in something on you secretly).  In the end, you will be able  
to program imperatively, functionally, OO, or even in logic (as in  
relations).

Indeed, based on our preliminary experience, the changes are so  
minimal in such a large code base that I would be surprised to hear  
that your own experiences aren't going to be similar. In case I am  
wrong, I encourage you very much to post examples and statistics or  
perhaps to start with questions (how did you guys deal with ... set- 
car! ... set-cdr! ...).

Don't give up yet. Innovations are sometimes scary looking but turn  
out to be fascinating (think of your first encounter with Scheme). --  
Matthias


P.S. The analogy with hardware is broken. Closures already are hard- 
wired functions but as software shows, you can make as many as you  
want and it costs very little.







On Jan 29, 2008, at 11:44 PM, Paul Schlie 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.
>
>> 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
>
>
> _________________________________________________
>   For list-related administrative tasks:
>   http://list.cs.brown.edu/mailman/listinfo/plt-scheme