[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Guile: What's wrong with this?

From: Mark H Weaver
Subject: Re: Guile: What's wrong with this?
Date: Fri, 06 Jan 2012 13:13:47 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux)

Mike Gran <address@hidden> writes:
> The word 'string' in Scheme is overloaded to mean both string
> immutables and string mutables.   Since a string immutable
> can't be modified to be a mutable, they really are different
> object types.  String mutables appear to still exist in the 
> latest draft of R7RS. 
> Many of the procedures that operate on strings will are overloaded
> to take both immutables and mutables, but some, like string-set!
> take only mutables.

This is the wrong way to think about it.  In Scheme, mutable and
immutable strings are _not_ different types.

The way to think about it is that in Scheme, the program text itself is
immutable, including any literals contained in it.  This is true of
_all_ literals, including '(literal lists), '#(literal vectors),
"literal strings", #'(literal syntax) and any other types that might be
added in the future that would otherwise be mutable.

Imagine that you were evaluating Scheme by hand on paper.  You have your
program written on one page, and you have another scratch page used for
the data structures that your program creates during evaluation.
Suppose your program contains a very large lookup table, written as a
literal list.  This lookup table is on your program page.

Now, suppose you are asked to evaluate (lookup key big-lookup-table).

The way Scheme works is that `big-lookup-table' is _not_ copied.  As
`lookup' traverses the table, it contains pointers within the program
page itself.  However, Scheme prohibits you from modifying _anything_
that happens to be on the program page.  It's not a question of type.
It's a question of which page the data happens to be on.

Now, we _could_ force you to copy big-lookup-table from the program page
onto the scratch page before doing `lookup', just in case `lookup' might
try to mutate its structure.  But that would be a lot of wasted effort.

Alternatively, we could allow you to modify the program itself.  This
is what Guile 1.8 did.  You _could_ make an argument that this is
desirable, on the grounds that we should trust that the programmer knows
what he's doing.

However, it's clear that Bruce did _not_ understood what he was doing.
I don't think that he (or you) realized that the following procedure was
buggy in Guile 1.8:

  (define (ten-spaces-with-one-star-at i)
    (define s "          ")
    (string-set! s i #\*)

Guile 1.8's permissivity allowed Bruce to unwittingly create a large
body of code that was inherently buggy.  IMHO, it would have been much
better to nip that in the bud and alert him to the fact that he was
doing something that was almost certainly unwise.

> There is a need for a constructor function to create string mutables,
> because a literal string in the source code indicates a string immutable.
> There are such constructors: (string <char> ...) and (make-string k <char>)
> which is fine.
> But there is no constructor for a string mutable that initializes
> it with a string in Guile 2.0.

Yes there is: (string-copy "string-literal")

If you don't like the name, then rename it:

  (define mutable-string string-copy)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]