Re: Guile: What's wrong with this?

[Ian Price <ianprice90@googlemail.com>]

Bruce Korb <bruce.korb@gmail.com> writes:

> On 01/04/12 08:47, Andy Wingo wrote:
>> I was going to propose a workaround with an option to change
>> vm-i-loader.c:43 and vm-i-loader.c:115 to use a
>> scm_i_mutable_string_literals_p instead of 1, but that really seems like
>> the path to perdition: previously compiled modules would start creating
>> mutable strings where they really shouldn't.
>
> Instead, long-standing, previously written code was invalidated with 1.9,
long-standing, previously written _buggy_ code.

> even if we were not smacked down until 2.0.1.
>
> Just because an obscure-to-those-not-living-and-breathing-Scheme-daily
> document said it was okay doesn't make it okay to those whacked by it.
There's an old saying, "Ignorance of the law is no excuse". If I wrote C
code that doesn't conform to the C standard and depended on
implementation specific behaviour, I have no recourse if it breaks on a
different compiler. Guile explicitly claims to conform to the r5rs (and
partially to the r6rs), both of which make this behaviour undefined, and
srfi 13 explicitly makes this an error. (And FWIW I would not consider
the R5RS obscure to people who have used scheme for even a short while,
nor is it a terrific burden to read at 50 pages)

Now, if you want to argue your position, it'd be better to argue that
guile goes beyond r[56]rs in making these promises with regards to strings.

For instance, substring-fill! as found at
https://www.gnu.org/software/guile/manual/html_node/String-Modification.html
implies that string literals are mutable

— Scheme Procedure: substring-fill! str start end fill
— C Function: scm_substring_fill_x (str, start, end, fill)

    Change every character in str between start and end to fill.

              (define y "abcdefg")
              (substring-fill! y 1 3 #\r)
              y
              ⇒ "arrdefg"

So too does string-upcase!
(https://www.gnu.org/software/guile/manual/html_node/Alphabetic-Case-Mapping.html),
if we assume y is the same binding in both functions

— Scheme Procedure: string-upcase! str [start [end]]
— C Function: scm_substring_upcase_x (str, start, end)
— C Function: scm_string_upcase_x (str)

    Destructively upcase every character in str.

              (string-upcase! y)
              ⇒ "ARRDEFG"
              y
              ⇒ "ARRDEFG"

The same goes for string-downcase! and string-capitalize!

I think it would be fair to say that someone could surmise that literal
strings are meant to be mutable from these examples, and, if we do go
down the immutable string literal route these examples would need to be
addressed.

On the other hand, you can argue that string literal immutability is
implied by

— Scheme Procedure: string-for-each-index proc s [start [end]]
— C Function: scm_string_for_each_index (proc, s, start, end)

    Call (proc i) for each index i in s, from left to right.

    For example, to change characters to alternately upper and lower case,
p
              (define str (string-copy "studly"))
              (string-for-each-index
                  (lambda (i)
                    (string-set! str i
                      ((if (even? i) char-upcase char-downcase)
                       (string-ref str i))))
                  str)
              str ⇒ "StUdLy"

but on a purely numerical basis, mutability 4 - 0 immutability

> I would think recompiling should not be a great burden, *ESPECIALLY*
At this stage, I think that argument is fair enough, other people's
mileage may vary.

-- 
Ian Price

"Programming is like pinball. The reward for doing it well is
the opportunity to do it again" - from "The Wizardy Compiled"