Newsgroups: comp.lang.scheme.c
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!howland.reston.ans.net!usc!elroy.jpl.nasa.gov!decwrl!netcomsv!netcom.com!hbaker
From: hbaker@netcom.com (Henry G. Baker)
Subject: Re: Puzzle:  persistence of parameters
Message-ID: <hbakerD0xJ0H.BzI@netcom.com>
Organization: nil
References: <blough@tigger.cs.colorado.edu> <199412131746.MAA20104@bloom-beacon.MIT.EDU>
Date: Sat, 17 Dec 1994 00:36:17 GMT
Lines: 28

In article <199412131746.MAA20104@bloom-beacon.MIT.EDU> cph@martigny.ai.mit.EDU (Chris Hanson) writes:
>What is happening is that the program is performing a side-effect on
>the constant list '(0).  According to the R4RS and the IEEE Scheme
>standard, this is illegal.  Because the initial value is written as a
>quoted constant rather than as a freshly constructed list, i.e. by
>specifying (LIST 0) instead, the MIT Scheme implementation saves the
>constant in the compiled-code image, and passes that particular
>constant to the procedure SUMS*.  It is arguable that it would have
>been better for the implementation to copy the list before passing it
>along, but there is no good reason to do the extra work involved when
>the program is defined to be ill-formed.
>
>A better solution would have been for the implementation to detect the
>fact that the procedure is performing a side-effect on a program
>constant, and to signal an error in that case.  But unfortunately we
>haven't done this, for various reasons; maybe some day we will.

An even better solution would be to distinguish mutable and immutable
values a la ML.  This position is argued in my paper 'Equal Rights
for Functional Objects', found in my www/ftp directory.

Henry Baker
Read (192.100.81.1) ftp.netcom.com:/pub/hb/hbaker/README for ftp-able papers.
WWW archive: ftp://ftp.netcom.com/pub/hb/hbaker/home.html
************* Note change of address ^^^        ^^^^
(It _is_ accessible, but Netcom is loaded; keep trying.)


