guile-devel
[Top][All Lists]
Advanced

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

Re: Guile: What's wrong with this?


From: Ludovic Courtès
Subject: Re: Guile: What's wrong with this?
Date: Tue, 03 Jan 2012 23:24:54 +0100
User-agent: Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.90 (gnu/linux)

Hi Bruce,

And happy new year!

Bruce Korb <address@hidden> skribis:

> Thank you for the explanation.  However:
>
> On 01/03/12 07:03, Mike Gran wrote:
>>> It worked until I "upgraded" to openSuSE 12.1.
>>>
>>>>   $ guile --version
>>>>   guile (GNU Guile) 2.0.2
>>>>   .....
>
>>>>   (set! tmp-text (get "act-text"))
>>>>          (set! TMP-text (string-upcase tmp-text))
>
>>>> ERROR: In procedure string-upcase:
>>>> ERROR: string is read-only: ""

[...]

>> On Guile 2.0.3, if you create a string the same way, it
>> is read-only for some reason.
>>
>> scheme@(guile-user)>  (define y "hello")
>> scheme@(guile-user)>  (string-set! y 0 #\x)
>> ERROR: In procedure string-set!:
>> ERROR: string is read-only: "hello"
>>
>> %string-dump can be used to confirm this
>
> There are a couple of issues:
>
> 1.  "string-upcase" should only read the string
>     (as opposed to "string-upcase!", which rewrites it).

Yes, that’s weird.  I can’t get string-upcase to raise a read-only
exception with 2.0.3, though.  Could you try with 2.0.3, or come up with
a reduced case?

> 2.  it is completely, utterly wrong to mutilate the
>     Guile library into such a contortion that it
>     interprets this:
>         (define y "hello")
>     to be a request to create an immutable string anyway.
>     It very, very plainly says, "make 'y' and fill it with
>     the string "hello".  Making it read only is crazy.

It stems from the fact that string literals are read-only, per R5RS
(info "(r5rs) Storage model"):

  In many systems it is desirable for constants (i.e. the values of literal
  expressions) to reside in read-only-memory.  To express this, it is
  convenient to imagine that every object that denotes locations is
  associated with a flag telling whether that object is mutable or immutable.
  In such systems literal constants and the strings returned by
  `symbol->string' are immutable objects, while all objects created by
  the other procedures listed in this report are mutable.  It is an error
  to attempt to store a new value into a location that is denoted by an
  immutable object.

In Guile this has been the case since commit
190d4b0d93599e5b58e773dc6375054c3a6e3dbf.

The reason for this is that Guile’s compiler tries hard to avoid
duplicating constants in the output bytecode.  Thus, modifying a
constant would actually change all other occurrences of that constant in
the code, making it a non-constant.  ;-)

> Furthermore, I do not even have an obvious way to deal
> with the problem,

You can use:

  (define y (string-copy "hello"))

> short of a massive rewrite.
> I define variables this way all over the place.
> rewriting the code to
>    (define y (string-append "hell" "o"))
> everywhere is stupid, laborious, time consuming for me,
> and time consuming at execution time.

I agree that this is laborious, and I’m sorry about that.  I can only
say that Guile < 2.0 being more permissive than the standard turns out
to be a mistake, in hindsight.

Thanks,
Ludo’.




reply via email to

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