On Wed, Sep 05, 2012 at 08:24:58PM +0100, Ian Price wrote:
> I, of course, meant vector literals, but a quick test shows this is not
> the case.
Literals are always immutable, and trying to modify them is nasal demon
stuff. Of course, R6RS says implementations "should" raise an exception
when an
Hi,
Stefan Israelsson Tampe skribis:
> If I put,
>
> (define a #(1))
> (define b #(1))
>
> , load the file. Then
>
>> (eq? a b)
> #t
The R5RS reads (info "(r5rs) Equivalence predicates"):
Since it is an error to modify constant objects (those returned by
literal expressions), impleme
Ian Price skribis:
> Ian Price writes:
>
>> anyway. Anyway if vectors are immutable, as I believe they are, it
>
> I, of course, meant vector literals, but a quick test shows this is not
> the case.
It could be the case, though. Literal strings are already immutable,
for instance.
Ludo’.
Yes, I can agree om that.
But this should be very stated clearly and perhaps added to a pitfall's
section.
/Stefan
On Wed, Sep 5, 2012 at 9:13 PM, Ian Price wrote:
> Stefan Israelsson Tampe writes:
>
> > Is this an optimization we need. I can figure out applications where you
> do
> > not wan
Ian Price writes:
> anyway. Anyway if vectors are immutable, as I believe they are, it
I, of course, meant vector literals, but a quick test shows this is not
the case.
(define v #(1 2 3))
(pk v)
(vector-set! v 0 #f)
(pk v)
~ $ guile -s /tmp/test.scm
;;; (#(1 2 3))
;;; (#(#f 2 3))
Hmm, the
Stefan Israelsson Tampe writes:
> Is this an optimization we need. I can figure out applications where you do
> not want this behavior e.g. I wan't to make distinct objects
> and add metadata by making a vector of it. Now different objects might have
> the same metadata and now go against my intu
Hi,
I found that this optimization can lead to dangerous bugs.
If I put,
(define a #(1))
(define b #(1))
, load the file. Then
> (eq? a b)
#t
Is this an optimization we need. I can figure out applications where you do
not want this behavior e.g. I wan't to make distinct objects
and add metada
