Interesting Behavior of 'append!' In Local Context

Interesting Behavior of 'append!' In Local Context

[Eric McDonald]

Hi,

Earlier today I ran into an interesting problem, involving the 'append!'
statement modifying a local variable in Guile. I'm tempted to call it a
bug, but I'm definitely not a Scheme expert and so am hoping someone can
provide some enlightenment....

Suppose that I have two function definitions:

guile> (define foo (lambda (p1) (let ((v1 '(-1))) (begin (append! v1 p1)))))
guile> (define bar (lambda (p1) (let ((v1 (list -1))) (begin (append! v1
p1)))))

I then use 'foo' as follows:

guile> (foo (list "abc" "def"))
(-1 "abc" "def")
guile> (foo (list "abc" "def"))
(-1 "abc" "def" "abc" "def")

Notice that 'v1' does not seem to be re-initialized in the second
invocation of 'foo'. Interestingly, if I run 'bar' with the same data,
the problem does not manifest itself:

guile> (bar (list "abc" "def"))
(-1 "abc" "def")
guile> (bar (list "abc" "def"))
(-1 "abc" "def")

Now, if I change the definitions of the functions to use 'set!' in
conjunction with an 'append' rather than just an 'append!', then both
behave as I would expect (i.e., the same as 'bar' above):

guile> (define foo (lambda (p1) (let ((v1 '(-1))) (begin (set! v1
(append v1 p1)) v1))))
guile> (define bar (lambda (p1) (let ((v1 (list -1))) (begin (set! v1
(append v1 p1)) v1))))
guile> (foo (list "abc" "def"))
(-1 "abc" "def")
guile> (foo (list "abc" "def"))
(-1 "abc" "def")
guile> (bar (list "abc" "def"))
(-1 "abc" "def")
guile> (bar (list "abc" "def"))
(-1 "abc" "def")

I tried comparing the behavior with mzScheme, but it doesn't seem to
have an 'append!' function. However, its output does match the tests
using the set!/append versions of my functions, as expected.

Any thoughts?

Thanks,
  Eric

P.S. Tested with Guile 1.8.5 and 1.8.7. Could not test with Guile from
Git repo, because the built executable had a fatal error on startup.

Re: Interesting Behavior of 'append!' In Local Context

[Stephen Compall]

On Oct 17, 2009, at 5:28 PM, Eric McDonald wrote:

> Notice that 'v1' does not seem to be re-initialized in the second
> invocation of 'foo'. Interestingly, if I run 'bar' with the same data,
> the problem does not manifest itself:

Literals are literally literal.  That is to say:

(define (itsaliteral) '(42 42))

(eqv? (itsaliteral) (itsaliteral)) => #t

It is an error to modify literals, but it is also not required by R5RS  
to detect and inform of such erroneous modification.  It is, however,  
not an error to rely on the eqv?-ness of repeated access of literals,  
as I do in the example above.

-- 
Sorry but you say Nibiru is a Hoax?  Doesnt Exist?  So maybe The
Sumerian people doesnt exist also! --Anonymous by way of SkI

Re: Interesting Behavior of 'append!' In Local Context

[Eric McDonald]

Stephen Compall wrote:

> Literals are literally literal.  That is to say:
> 
> (define (itsaliteral) '(42 42))

Thanks, Stephen. I never really looked at quote as declaring a literal.
I primarily saw its use for suppressing evaluation inside the quoted
entity, and as a convenient shorthand for making lists. I guess it's a
convenient shorthand for making _literal_ lists. (And, the Guile
documentation even uses the word literal - now that I'm looking for it. ;-)

> It is an error to modify literals, but it is also not required by R5RS
> to detect and inform of such erroneous modification.  It is, however,

Fair enough. I certainly wouldn't mind seeing "detect and inform"
implemented for this case. As a comparison: if I'm writing C or C++
code, and I try to modify a const value, the compiler is generally going
to let me know.

Anyway, sorry to trouble the list with a noobish oversight.

Regards,
  Eric

Re: Interesting Behavior of 'append!' In Local Context

[Stephen Compall]

On Sat, 2009-10-17 at 20:36 -0400, Eric McDonald wrote:
> Thanks, Stephen. I never really looked at quote as declaring a literal.
> I primarily saw its use for suppressing evaluation inside the quoted
> entity, and as a convenient shorthand for making lists. I guess it's a
> convenient shorthand for making _literal_ lists. (And, the Guile
> documentation even uses the word literal - now that I'm looking for it. ;-)

Don't take it to mean that quote is more magic than it already was.  It
really does just suppress evaluation.  The things that you quote become
literals by virtue of being in an unevaluated, value-returning context.

Consider this code:

    ;; the syntax, living dangerously by being untested
    (define-syntax clcase
      (syntax-rules ()
        ((_ expr cases ...)
         (let ((var expr))
           (%clcase var cases ...)))))

    (define-syntax %clcase
      (syntax-rules ()
        ((_ var)
         #f)
        ((_ var (matchlist then ...) cases ...)
         (if (memv var 'matchlist)
             (begin then ...)
             (%clcase var cases ...)))))

    ;; and "your code"
    (clcase (+ 21 21)
      ((42) 'its-42)
      ((84) 'its-84))

At some point, the procedure memv will be called with the literal list
(42), even though you did not prefix it with a quote in "your code".  If
you altered the syntax to call a procedure other than memv, one that
perhaps altered the structure of the second argument, it would be an
error due to modification of a literal.

> Fair enough. I certainly wouldn't mind seeing "detect and inform"
> implemented for this case. As a comparison: if I'm writing C or C++
> code, and I try to modify a const value, the compiler is generally going
> to let me know.

A better comparison would be whether the C compiler prevents you from
mutating a literal through a pointer whose constness has been cast away,
in a separate compilation unit.

MzScheme's making pairs immutable by default is a reflection of the
style of the larger Scheme community, which generally eschews mutating
list structure in favor of a more functional style.

-- 
Sorry but you say Nibiru is a Hoax?  Doesnt Exist?  So maybe The
Sumerian people doesnt exist also! --Anonymous by way of SkI

Re: Interesting Behavior of 'append!' In Local Context

[Andy Wingo]

Hello Eric,

On Sun 18 Oct 2009 02:36, Eric McDonald <mcdonald@phy.cmich.edu> writes:

> Stephen Compall wrote:
>
>> It is an error to modify literals, but it is also not required by R5RS
>> to detect and inform of such erroneous modification.  It is, however,
>
> Fair enough. I certainly wouldn't mind seeing "detect and inform"
> implemented for this case.

That would be nice, yes. It should be fairly easy to implement for
vectors, strings, and arrays, for the upcoming Guile 2.0. Pairs are a
bit trickier, due to the way they are represented in Guile, though it
would be nice as well.

> Anyway, sorry to trouble the list with a noobish oversight.

No problem. Happy hacking :)

Andy
-- 
http://wingolog.org/

Re: Interesting Behavior of 'append!' In Local Context

[Eric McDonald]

Stephen Compall wrote:

>     ;; and "your code"
>     (clcase (+ 21 21)
>       ((42) 'its-42)
>       ((84) 'its-84))

[snip]

>> Fair enough. I certainly wouldn't mind seeing "detect and inform"
>> implemented for this case. As a comparison: if I'm writing C or C++
>> code, and I try to modify a const value, the compiler is generally going
>> to let me know.
> 
> A better comparison would be whether the C compiler prevents you from
> mutating a literal through a pointer whose constness has been cast away,
> in a separate compilation unit.

Well, I think that you generally have one C compiler invocation per
compilation unit, and so you lose track of some information between
compilation units. In the cases that we're talking about, everything is
taking place in the same Scheme interpreter session, and so you
shouldn't have to cope with that kind of loss of information...?

Admittedly, it might be difficult to ascertain constness of the list
containing Adams Constant in the above example. But, I think for more
straightforward cases (the majority, perhaps?), such as original
example, I can't imagine that it would be such a difficult task. Andy's
reply seems to concur.

> MzScheme's making pairs immutable by default is a reflection of the
> style of the larger Scheme community, which generally eschews mutating
> list structure in favor of a more functional style.

Sure, agreed. I know that I'm working with a functional language and so
it shouldn't be surprising that functional style is encouraged. I've
actually had quite a bit of experience with Mathematica [1], and so I'm
no stranger to this style of programming. However, there are times when
sequential and iterative logic are more convenient or maintainable, and
since Scheme does provide facilities for that kind of logic, I think I
would be foolish to ignore them. And, when one does iteration, instead
of recursion, it is often more natural to mutate list structure rather
than compose it.

Thanks for the discussion,
  Eric

[1] IIRC, Mathematica provides Protect[] and Unprotect[] for constness
control, and Unevaluated[] (and other mechanisms I can't presently
recall) for evaluation suppression. The orthogonality of these sets of
mechanisms is probably what led to my confusion about how Scheme's quote
works.