Summary

set! returns its value when compiled

Metadata

Description

I guess this has been true for a while (it is in 4.5.5 and 4.6.4). It causes some light breakage, like if you use (display ...) on a TCP port, display will sometimes return the empty string instead of void, since there is a (set!) as the final statement in the output port lambda. So, I assume this is unintentional.

 echo "(print (set! a 3))" > set.scm
 
 csc set.scm
 ./set
 3
 
 csi -script set.scm
 #<unspecified>

Changes and comments

[2011-02-09 10:47:16 UTC] felix wrote:

Both `display` and `set` have no specified return value. Are you concerned about the inconsistency?

[2011-02-09 17:47:05 UTC] zbigniew wrote:

The inconsistency. It seems the core relies on a (void) return in at least one place (tcp). Once in a while display will return the empty string instead of void. This is disconcerting, because if you are at the REPL making TCP connections, 1 out of every 10 displays might return a value, which makes the user wonder what happened. Therefore I consider this to violate the principle of least surprise. Placing a (void) at the end of the output-port writing procedure is a quick way to quiet this behavior.

[2011-02-25 08:59:05 UTC] felix wrote:

Replying to zbigniew: > The inconsistency. It seems the core relies on a (void) return in at least one place (tcp). Once in a while display will return the empty string instead of void. This is disconcerting, because if you are at the REPL making TCP connections, 1 out of every 10 displays might return a value, which makes the user wonder what happened. Therefore I consider this to violate the principle of least surprise. Placing a (void) at the end of the output-port writing procedure is a quick way to quiet this behavior.

Then this is about `display`, not `set!`?

[2011-02-27 20:45:06 UTC] zbigniew changed status from new to closed

[2011-02-27 20:45:06 UTC] zbigniew set resolution to invalid

[2011-02-27 20:45:06 UTC] zbigniew wrote:

Since you indicated this is not a problem with set! or display, and since I implemented a workaround in tcp6, I am closing this ticket as invalid.

[2011-06-01 09:00:41 UTC] felix changed milestone from 4.7.0 to 4.8.0

[2011-06-01 09:00:41 UTC] felix wrote:

Milestone 4.7.0 deleted

[2012-09-24 21:47:48 UTC] felix changed milestone from 4.8.0 to 4.9.0

[2012-09-24 21:47:48 UTC] felix wrote:

Milestone 4.8.0 deleted