unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
* let-values, and-let* no variables
@ 2004-08-20  1:27 Kevin Ryde
  2004-08-20 10:28 ` Marius Vollmer
  0 siblings, 1 reply; 4+ messages in thread
From: Kevin Ryde @ 2004-08-20  1:27 UTC (permalink / raw)


I'm contemplating the way "begin" is used for the body of let-values
and and-let* with no bindings.  It has the unhappy effect of allowing
what is visually an internal define to go out into the containing
environment, eg.

	(use-modules (srfi srfi-11))
	(let-values ()
	  (define x 123)
	  456)
	(display x)
	;; prints 123

The reference implementation of srfi-11 seems pretty clear that
"begin" is intended for let-values, and the formal semantics part of
srfi-2 suggests the same for and-let*.  Dunno if that's only an
oversight regarding begin versus internal defines though.

I guess nobody would write an empty and-let* or let-values
deliberately, but it could arise out of a macro.  I'm thinking to put
some words of caution in the manual, to make it clear the body isn't
the same as a plain "let" or "let*".


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: let-values, and-let* no variables
  2004-08-20  1:27 let-values, and-let* no variables Kevin Ryde
@ 2004-08-20 10:28 ` Marius Vollmer
  2004-09-07  0:12   ` Kevin Ryde
  0 siblings, 1 reply; 4+ messages in thread
From: Marius Vollmer @ 2004-08-20 10:28 UTC (permalink / raw)


Kevin Ryde <user42@zip.com.au> writes:

> I'm contemplating the way "begin" is used for the body of let-values
> and and-let* with no bindings.  It has the unhappy effect of allowing
> what is visually an internal define to go out into the containing
> environment, eg.

Uhh, intuitively I'd say that this is wrong behavior.  Maybe you
should ask on comp.lang.scheme.

> I guess nobody would write an empty and-let* or let-values
> deliberately, but it could arise out of a macro.  I'm thinking to put
> some words of caution in the manual, to make it clear the body isn't
> the same as a plain "let" or "let*".

That would be good, even if we 'fix' our implementation to behave
differently.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: let-values, and-let* no variables
  2004-08-20 10:28 ` Marius Vollmer
@ 2004-09-07  0:12   ` Kevin Ryde
  2004-09-21 22:09     ` Marius Vollmer
  0 siblings, 1 reply; 4+ messages in thread
From: Kevin Ryde @ 2004-09-07  0:12 UTC (permalink / raw)
  Cc: guile-devel

[-- Attachment #1: Type: text/plain, Size: 593 bytes --]

Marius Vollmer <marius.vollmer@uni-dortmund.de> writes:
>
> Uhh, intuitively I'd say that this is wrong behavior.

One that's guile specific is let-optional and let-keywords, eg.

	(use-modules (ice-9 optargs))
	(let ()
	  (let-keywords '() #f ()
	    (define localvar 123))
	  localvar)

	=> 123

which could be fixed fairly easily,

        * optargs.scm (let-optional-template, let-keywords-template): Change
        "(begin body)" to "(let () body)" for empty bindings, since the former
        lets syntactically internal defines in body leak out to the
        surrounding environment.


[-- Attachment #2: optargs.scm.begin.diff --]
[-- Type: text/plain, Size: 1013 bytes --]

--- optargs.scm.~1.20.~	2003-04-07 08:04:58.000000000 +1000
+++ optargs.scm	2004-09-07 09:16:29.000000000 +1000
@@ -1,6 +1,6 @@
 ;;;; optargs.scm -- support for optional arguments
 ;;;;
-;;;; 	Copyright (C) 1997, 1998, 1999, 2001, 2002 Free Software Foundation, Inc.
+;;;; 	Copyright (C) 1997, 1998, 1999, 2001, 2002, 2004 Free Software Foundation, Inc.
 ;;;;
 ;;;; This library is free software; you can redistribute it and/or
 ;;;; modify it under the terms of the GNU Lesser General Public
@@ -125,7 +125,7 @@
 
 (define (let-optional-template REST-ARG BINDINGS BODY let-type)
     (if (null? BINDINGS)
-	`(begin ,@BODY)
+	`(let () ,@BODY)
 	(let-o-k-template REST-ARG BINDINGS BODY let-type
 			  (lambda (optional)
 			    `(,(car optional)
@@ -140,7 +140,7 @@
 
 (define (let-keywords-template REST-ARG ALLOW-OTHER-KEYS? BINDINGS BODY let-type)
     (if (null? BINDINGS)
-	`(begin ,@BODY)
+	`(let () ,@BODY)
 	(let* ((kb-list-gensym (gensym "kb:G"))
 	       (bindfilter (lambda (key)
 			     `(,(car key)

[-- Attachment #3: Type: text/plain, Size: 143 bytes --]

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: let-values, and-let* no variables
  2004-09-07  0:12   ` Kevin Ryde
@ 2004-09-21 22:09     ` Marius Vollmer
  0 siblings, 0 replies; 4+ messages in thread
From: Marius Vollmer @ 2004-09-21 22:09 UTC (permalink / raw)


Kevin Ryde <user42@zip.com.au> writes:

> Marius Vollmer <marius.vollmer@uni-dortmund.de> writes:
>>
>> Uhh, intuitively I'd say that this is wrong behavior.
>
> One that's guile specific is let-optional and let-keywords, eg.
>
> 	(use-modules (ice-9 optargs))
> 	(let ()
> 	  (let-keywords '() #f ()
> 	    (define localvar 123))
> 	  localvar)
>
> 	=> 123
>
> which could be fixed fairly easily,

Yes, please do.  Thanks!

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2004-09-21 22:09 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-08-20  1:27 let-values, and-let* no variables Kevin Ryde
2004-08-20 10:28 ` Marius Vollmer
2004-09-07  0:12   ` Kevin Ryde
2004-09-21 22:09     ` Marius Vollmer

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).