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,
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
Stefan Israelsson Tampe stefan.ita...@gmail.com 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
Ian Price ianpric...@googlemail.com 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))
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 ianpric...@googlemail.com wrote:
Stefan Israelsson Tampe stefan.ita...@gmail.com writes:
Is this an optimization we need. I can
Ian Price ianpric...@googlemail.com skribis:
Ian Price ianpric...@googlemail.com 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
Hi,
Stefan Israelsson Tampe stefan.ita...@gmail.com 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
