From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eric McDonald Newsgroups: gmane.lisp.guile.user Subject: Re: Interesting Behavior of 'append!' In Local Context Date: Sun, 18 Oct 2009 09:53:12 -0400 Message-ID: <4ADB1DC8.4050309@phy.cmich.edu> References: <4ADA4506.4090804@phy.cmich.edu> <2F77A419-E28E-4936-854C-5FAE76D85815@member.fsf.org> <4ADA6319.1030004@phy.cmich.edu> <1255830356.5591.51.camel@nocandy.dyndns.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1255874102 30401 80.91.229.12 (18 Oct 2009 13:55:02 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 18 Oct 2009 13:55:02 +0000 (UTC) To: guile-user@gnu.org Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Sun Oct 18 15:54:52 2009 Return-path: Envelope-to: guile-user@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1MzWCI-0006Jz-M2 for guile-user@m.gmane.org; Sun, 18 Oct 2009 15:53:22 +0200 Original-Received: from localhost ([127.0.0.1]:36606 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MzWCI-0000hU-2b for guile-user@m.gmane.org; Sun, 18 Oct 2009 09:53:22 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MzWCF-0000hP-01 for guile-user@gnu.org; Sun, 18 Oct 2009 09:53:19 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MzWCA-0000go-D9 for guile-user@gnu.org; Sun, 18 Oct 2009 09:53:18 -0400 Original-Received: from [199.232.76.173] (port=42676 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MzWCA-0000gl-AJ for guile-user@gnu.org; Sun, 18 Oct 2009 09:53:14 -0400 Original-Received: from mta11.charter.net ([216.33.127.80]:42657) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MzWC9-0003E4-RE for guile-user@gnu.org; Sun, 18 Oct 2009 09:53:14 -0400 Original-Received: from imp09 ([10.20.200.9]) by mta11.charter.net (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20091018135313.VUNC27604.mta11.charter.net@imp09> for ; Sun, 18 Oct 2009 09:53:13 -0400 Original-Received: from [24.247.173.2] ([24.247.173.2]) by imp09 with smtp.charter.net id uDtC1c00A03U7cw05DtCZ7; Sun, 18 Oct 2009 09:53:13 -0400 X-Authority-Analysis: v=1.0 c=1 a=aNOD7mxu7FEA:10 a=2o6zPvFxPCZUc6zIKG4A:9 a=gJHa3nZe3kkP5HbodqFeCpl5NQIA:4 User-Agent: Thunderbird 2.0.0.23 (X11/20091003) In-Reply-To: <1255830356.5591.51.camel@nocandy.dyndns.org> X-Enigmail-Version: 0.95.7 X-detected-operating-system: by monty-python.gnu.org: Solaris 10 (1203?) X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.user:7454 Archived-At: 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.