set! returns its value when compiled

[Jim Ursetto]

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>

[felix winkelmann]

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

[Jim Ursetto]

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.

[felix winkelmann]

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!?

[Jim Ursetto]

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.

[felix winkelmann]

Milestone 4.7.0 deleted

[felix winkelmann]

Milestone 4.8.0 deleted