Issue with parameters

[Mario Domenech Goulart]

Reported by Joo ChurlSoo via e-mail:

CHICKEN
(c) 2008-2015, The CHICKEN Team
(c) 2000-2007, Felix L. Winkelmann
Version 4.10.0 (rev b259631)
windows-mingw32-x86 [ manyargs dload ptables ]
compiled 2015-08-04 on yves.more-magic.net (Linux)
#;1> (define a (make-parameter 1))
#;2> (a 10 23)
10
#;3> (a)
10
#;4> (define b (make-parameter 2 number->string))
#;5> (b 20 23)
20
#;6> (b)
20
#;7> (b 20)
"20"
#;8> (b)
"20"

[sjamaan]

This happens because parameterize expands to a call that passes #t or #f as a second argument to the parameter procedure, depending on whether the converter needs to be invoked.

We can never truly hide this, because the macro expands to code at the call site, which means whatever it expands to needs to be accessible to the user.

See also my suggestion in #1227 to make the second argument a keyword. This would make the problem less likely.

[evhan]

The most problematic bit of this ticket (that of (b) returning 20 rather than "20" in command #;6) is no longer an issue. Is this worth keeping open?

[sjamaan]

We just discussed what to do: we can change it to be non-booleans, use distinct values to indicate whether we want to convert (and reject anything else), which makes it nigh-impossible for the user to call it with that.