Summary
Issue with parameters
Metadata
- Id: 45e965a911950a550667752576b488406121b4f5
- Trac id: 1235
- Type: defect
- Reporter: mario
- Owner:
- Cc: initerm@gmail.com
- Status: new
- Component: core libraries
- Estimated difficulty: medium
- Resolution:
- Priority: major
- Milestone: someday
- Version: 4.10.x
- Changetime: 2018-04-27 20:59:51 UTC
- Created: 2015-12-15 11:36:17 UTC
- Keywords: parameters, make-parameter
Description
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"
Changes and comments
[2015-12-15 11:53:53 UTC] sjamaan wrote:
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.
[2016-08-25 20:23:44 UTC] sjamaan set difficulty to medium
[2018-04-27 17:41:24 UTC] evhan wrote:
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?
[2018-04-27 20:59:51 UTC] sjamaan wrote:
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.