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

[Mark H Weaver]

Hi Andy,

> commit d851e32fdc3d14804108f0389faa75a57599ced4
> Author: Andy Wingo <address@hidden>
> 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.

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* ?

>  (define *primitive-constructors*
>    ;; Primitives that return a fresh object.
> -  '(acons cons cons* list vector make-struct make-struct/no-tail))
> +  '(acons cons cons* list vector make-struct make-struct/no-tail
> +          car cdr vector-ref struct-ref))
>  
>  (define *effect-free-primitives*
>    `(values
> @@ -118,13 +119,11 @@
>      + * - / 1- 1+ quotient remainder modulo
>      not
>      pair? null? list? symbol? vector?
> -    car cdr
>      caar cadr cdar cddr
>      caaar caadr cadar caddr cdaar cdadr cddar cdddr
>      caaaar caaadr caadar caaddr cadaar cadadr caddar cadddr
>      cdaaar cdaadr cdadar cdaddr cddaar cddadr cdddar cddddr
> -    vector-ref
> -    struct? struct-vtable struct-ref
> +    struct? struct-vtable
>      bytevector-u8-ref bytevector-s8-ref
>      bytevector-u16-ref bytevector-u16-native-ref
>      bytevector-s16-ref bytevector-s16-native-ref

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

    Thanks,
      Mark