Re: GNU Guile branch, stable-2.0, updated. v2.0.2-101-gd851e32

[ludo@gnu.org (Ludovic Courtès)]

Hi Mark,

Mark H Weaver <mhw@netris.org> skribis:

>> commit d851e32fdc3d14804108f0389faa75a57599ced4
>> Author: Andy Wingo <wingo@pobox.com>
>> Date:   Fri Sep 23 18:02:05 2011 +0200
>>
>>     prevent propagation for memory-dependent operations like `car'
>>     
>>     * module/language/tree-il/primitives.scm (*primitive-constructors*):
>>       Record car, cdr, vector-ref, and struct-ref as "constructors".
>>       Comment to come later.
>
> If car, cdr, vector-ref and struct-ref are to be included in this set of
> operations, it seems to me that the set should be renamed to something
> other than "constructors".
>
> Note that peval should not perform (in advance) any operations that
> access _mutable_ memory, but accessing non-mutable memory should be
> fine.

These operations need special care because they return a mutable object,
which must be protected against copy propagation, as in:

  (let ((x (cons (list 1) (list 2))))
    (set-car! (car x) 0)
    (car x))

We discussed this on IRC and failed to come up with a nice name, which
is why Andy kept this one.

> Instead of moving those operations into the *primitive-constructors*
> set, perhaps we should make a new set of primitives called something
> like *primitive-mutable-accessors* ?

Yes, though it’s not the accessor that’s mutable.  :-)

‘mutable-object-returning-primitive’ would be descriptive but is hard to
read...

> If you're going to move car and cdr from one set to the other, shouldn't
> you do the same for caar, cadr, etc?

No because they get reduced to a sequence of car & cdr.

> Also, if I'm correct in guessing the reason for this change (accessing
> mutable memory), shouldn't the bytevector-*-ref operations go as well?

No because they return an immutable object.

Thanks,
Ludo’.