[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Stephen Compall
Subject: Re: Interesting Behavior of 'append!' In Local Context
Date: Sat, 17 Oct 2009 20:45:56 -0500

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)
        ((_ 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]