Opened 9 years ago

Last modified 7 years ago

#1235 new defect

Issue with parameters

Reported by: Mario Domenech Goulart Owned by:
Priority: major Milestone: someday
Component: core libraries Version: 4.10.x
Keywords: parameters, make-parameter Cc: initerm@…
Estimated difficulty: medium

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"

Change History (4)

comment:1 Changed 9 years ago by 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.

comment:2 Changed 8 years ago by sjamaan

Estimated difficulty: medium

comment:3 Changed 7 years ago by 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?

comment:4 Changed 7 years ago by 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.

Note: See TracTickets for help on using tickets.