Newsgroups: comp.lang.scheme
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!oitnews.harvard.edu!yale!yale.edu!spool.mu.edu!howland.reston.ans.net!vixen.cso.uiuc.edu!sdd.hp.com!hpscit.sc.hp.com!hplntx!hplntx.hpl.hp.com!gjr
From: gjr@hplgr2.hpl.hp.com (Guillermo (Bill) J. Rozas)
Subject: Re: R4RS noncompliance on loading files
Sender: news@hpl.hp.com (HPLabs Usenet Login)
Message-ID: <GJR.95Sep10175423@hplgr2.hpl.hp.com>
In-Reply-To: blume@dynamic.cs.princeton.edu's message of 08 Sep 1995 13:53:33 GMT
Date: Mon, 11 Sep 1995 01:54:23 GMT
Reply-To: gjr@hplabs.hpl.hp.com
References: <423vhv$4al@mozo.cc.purdue.edu> <427e96$1qre@kaa.heidelbg.ibm.com>
	<BLUME.95Sep7092319@dynamic.cs.princeton.edu>
	<42p26v$2i37@kaa.heidelbg.ibm.com>
	<BLUME.95Sep8095333@dynamic.cs.princeton.edu>
Nntp-Posting-Host: hplgr2.hpl.hp.com
Organization: /users/gjr/.organization
Lines: 47

In article <BLUME.95Sep8095333@dynamic.cs.princeton.edu> blume@dynamic.cs.princeton.edu (Matthias Blume) writes:

   Xref: hplntx comp.lang.scheme:11870
   Path: hplntx!hpscit.sc.hp.com!news.dtc.hp.com!col.hp.com!sdd.hp.com!usc!howland.reston.ans.net!newsfeed.internetmci.com!delmarva.com!udel!princeton!cnn.Princeton.EDU!news.princeton.edu!blume
   From: blume@dynamic.cs.princeton.edu (Matthias Blume)
   Newsgroups: comp.lang.scheme
   Subject: Re: R4RS noncompliance on loading files
   Date: 08 Sep 1995 13:53:33 GMT
   Organization: Princeton University
   Lines: 29
   Distribution: world
   Message-ID: <BLUME.95Sep8095333@dynamic.cs.princeton.edu>
   References: <423vhv$4al@mozo.cc.purdue.edu> <427e96$1qre@kaa.heidelbg.ibm.com>
	   <BLUME.95Sep7092319@dynamic.cs.princeton.edu>
	   <42p26v$2i37@kaa.heidelbg.ibm.com>
   NNTP-Posting-Host: dynamic.cs.princeton.edu
   In-reply-to: lux@idse.heidelbg.ibm.com's message of 8 Sep 1995 09:25:51 GMT

   In article <42p26v$2i37@kaa.heidelbg.ibm.com> lux@idse.heidelbg.ibm.com (Wolfgang Lux) writes:

      Hmmm, interesting article. But I do not see how this solutions covers
      all those problems you listed. Even in the SML-like approach a
      definition which has been overlaid by an buggy definition will not
      come back into existence, when I reload the file again, where this
      definition has been removed. If this definition has been removed, it
      will simply stay there and possibly be called again (if I forgot to
      remove it at some point).

   Indeed.  I was not claiming that the SML approach solves this problem.
   The main reason why I favor it is that it is consistent.  Macro
   definitions, inlining-directives _and_ variable definitions (as well
   as every other conceivable definition) have effects on the future
   only.  Everything else I said was only said to diffuse the often-heard
   arguments in favor of the current Scheme semantics, which, IMO, are
   broken.

      And the problem with open-coded car, cdr etc., could be better solved
      using a module system, which did not allow those variables to be
      modified.

   Do you want to have to define all your macros, inlinable functions,
   constants, etc. strictly within modules?!  The problems with current
   Scheme semantics arise as soon as there are _at least two_ different
   possible denotations for top-level identifiers.

   --
   -Matthias
