From: Stephen Compall <s11@member.fsf.org>
To: Eric McDonald <mcdonald@phy.cmich.edu>
Cc: guile-user@gnu.org
Subject: Re: Interesting Behavior of 'append!' In Local Context
Date: Sat, 17 Oct 2009 20:45:56 -0500 [thread overview]
Message-ID: <1255830356.5591.51.camel@nocandy.dyndns.org> (raw)
In-Reply-To: <4ADA6319.1030004@phy.cmich.edu>
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
next prev parent reply other threads:[~2009-10-18 1:45 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-17 22:28 Interesting Behavior of 'append!' In Local Context Eric McDonald
2009-10-17 23:09 ` Stephen Compall
2009-10-18 0:36 ` Eric McDonald
2009-10-18 1:45 ` Stephen Compall [this message]
2009-10-18 13:53 ` Eric McDonald
2009-10-18 10:25 ` Andy Wingo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1255830356.5591.51.camel@nocandy.dyndns.org \
--to=s11@member.fsf.org \
--cc=guile-user@gnu.org \
--cc=mcdonald@phy.cmich.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).