From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 84683 invoked by alias); 23 Nov 2017 10:52:30 -0000 Mailing-List: contact kawa-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: kawa-owner@sourceware.org Received: (qmail 84672 invoked by uid 89); 23 Nov 2017 10:52:29 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=BAYES_00,KB_WAM_FROM_NAME_SINGLEWORD,SPF_PASS,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 spammy=H*Ad:U*kawa, H*M:int, H*r:390, H*M:info X-HELO: mail.io7m.com Received: from mail.io7m.com (HELO mail.io7m.com) (45.77.76.92) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 23 Nov 2017 10:52:27 +0000 Received: from copperhead.int.arc7.info (unknown [IPv6:2a02:390:7502:2:0:2:1:0]) by mail.io7m.com (Postfix) with ESMTPSA id 4E53065A4; Thu, 23 Nov 2017 10:52:25 +0000 (UTC) Date: Thu, 23 Nov 2017 10:52:00 -0000 From: Mark Raynsford To: Per Bothner Cc: kawa@sourceware.org Subject: Re: Difference in define behaviour between kawa.jar and embedded Scheme example Message-ID: <20171123105212.0e8cbd1d@copperhead.int.arc7.info> In-Reply-To: References: <20171122223308.6b39e57d@copperhead.int.arc7.info> OpenPGP: id=8168DAE22B15D3EDC722C23D0F15B7D06FA80CB8; url=http://io7m.com/pgp/8168_DAE2_2B15_D3ED_C722_C23D_0F15_B7D0_6FA8_0CB8.key MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; boundary="Sig_/PMvrCBBRiDEFNUMj.co=p3M"; protocol="application/pgp-signature" X-IsSubscribed: yes X-SW-Source: 2017-q4/txt/msg00042.txt.bz2 --Sig_/PMvrCBBRiDEFNUMj.co=p3M Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-length: 1994 Hello! On 2017-11-23T03:26:20 +0100 Per Bothner wrote: > > On 11/22/2017 11:33 PM, Mark Raynsford wrote: > > In other words, the redefinition of + on the second line is affecting > > the existing definition of six0 so that the applications of six0 and > > six1 are both returning 9. What's going on here?=20=20 >=20 > The behavior of demo0.scm depends on whether it is evaluated line-by-line > (as in REPL) or as a "module" (or "library" in R7RS-speak). The latter > is the default, but you can force teh former using the -f options. > Compare: > $ kawa demo0.scm > vs: > $ kawa -d demo0.scm >=20 > Either implicitly imports (kawa base). In general it is invalid to > explicitly define bindings that conflict with imported bindings. > We are somewhat more lenient with (kawa base), for compatibility > with tradition, but it is still a bad idea. OK, thanks. This is something I'm going to be looking into at the source. As you know, I'm putting together a gratuitously incompatible subset of the language, so I have no need for compatibility with tradition. I'd rather get hard errors up front. To be honest, I'd rather all redefines at the top-level be errors, but I assume this is something I'm going to have to implement myself. I actually ran into this behaviour because I was informally testing my subclasses of Scheme/SchemeCompilation and was surprised that I could override existing bindings like this (because being able to affect the internals of existing definitions wasn't the behaviour I was used to from other Schemes). I assumed that I'd broken something with my subclasses, but then it turned out that the original Scheme class also did this. > Instead you can do something like: >=20 > (import (except (kawa base) +)) > (import (only (kawa base) (+ orig-+))) > (define (six0 x) (orig-+ 3 3)) > (define (+ x y) (* x y)) > (define (six1 x) (+ 3 3)) > (format #t "[~w ~w]~%~!" (six0 0) (six1 0)) Got it. --=20 Mark Raynsford | http://www.io7m.com --Sig_/PMvrCBBRiDEFNUMj.co=p3M Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature Content-length: 833 -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEgWja4isV0+3HIsI9DxW30G+oDLgFAloWqFwACgkQDxW30G+o DLiJbw//cpidrQkW3GqroLDltYgACw6RLvprKYiK4CDrYdv4UxudYBk44XL54DZn mOWgaSfP7t5vxQD1+7GuzmMI6CaIgxD4/fKOTb5YVU7NyWaB7ylrAtUK8BjnZgJ4 CYJ6Gy6V1mIehf7WWErl9KTYrsx82Q+Uua5ZrNTODtJVPre2t6eB+15/q6WCt8o5 MoAUHb8y9BshwmMzaU1+ICWX33pgm9qOBkXkvNQ+NNICbI54Hpz4HIhnZWhGHjlt TKl47oX0pf+G3C2TCPH03rwGfUvOgHmAfhZpuktj9v9Q0tOSJwLeufaSDEfTQkf/ KRZQx8iTtbRg0s4f40WRUeljEP4MZw9bTR1rvl0PBGctL64SO/SrycUocAd5WjgQ Nr1FUZd3soj9pbcgd7u7lB+FUhhHAME8mp3yJueJbdx+W3dGAqVnTAXAdyZKqpqM 91ZqUc5vxymE2GunW/NvBKFyrCE4g+NS/ucJnj3JK0/DEFkc4iwDu2p5AE2cs8ah b2S4JMhZZOIto3FvhbAVhGfMhFsgtmaBYvpJbUMCCua9Tj7nDiaWyFrKVd24P6DZ v/Gfz/LYNhiIVDbHXnsXm6WfPFd0eVEADqcxmG34El8gIdmGQ29ufMM1vcf8QNag 1qtTrQdGxEqxiEdR5Cmh1H2cRpWrKvsUMXm8vqtzjPojsEG8b4E= =195b -----END PGP SIGNATURE----- --Sig_/PMvrCBBRiDEFNUMj.co=p3M--