I was also surprised by the-unsupplied-arg ( http://docs.racket-lang.org/reference/function-contracts.html#%28def._%28%28lib._racket%2Fcontract%2Fbase..rkt%29._the-unsupplied-arg%29%29) when I first encountered it: perhaps it should not be the very last thing in the documentation for ->i?
If there are optional arguments that are not supplied, then the > corresponding variables will be bound to a special value called > the-unsupplied-arg value. For example, in this contract: > (->i ([x (y) (if (unsupplied-arg? y) > real? > (>=/c y))]) > ([y real?]) > any) > the contract on x depends on y, but y might not be supplied at the call > site. In that case, the value of y in the contract on x is > the-unsupplied-arg and the ->i contract must check for it and tailor the > contract on x to account for y not being supplied. > When the contract expressions for unsupplied arguments are dependent, and > the argument is not supplied at the call site, the contract expressions are > not evaluated at all. For example, in this contract, y’s contract > expression is evaluated only when y is supplied: > (->i () > ([x real?] > [y (x) (>=/c x)]) > any) > In contrast, x’s expression is always evaluated (indeed, it is evaluated > when the ->i expression is evaluated because it does not have any > dependencies). Aside from Dupéron's point that "the contract can be specified separately from the function, and the function itself knows the default argument's value", I have found cases when it's actually useful to know explicitly whether an argument was supplied or not. For example, make-id-cookie <http://docs.racket-lang.org/web-server/http.html#%28def._%28%28lib._web-server%2Fhttp%2Fid-cookie..rkt%29._make-id-cookie%29%29> uses a single ->i contract to check that it was called with either three by-position arguments or two by-position arguments and a #:key argument (but not three by-position arguments and a #:key argument). Then the actual implementation can use a default value of #f (which wouldn't satisfy any of the relevant contracts) for these supposedly-optional arguments, and normalizing the arguments becomes just a matter of using or. -Philip On Sun, May 7, 2017 at 4:13 PM, Daniel Prager <daniel.a.pra...@gmail.com> wrote: > Hi Georges > > Thanks for the explanation on 2. Pragmatically, it's just another > contributor to the cost of contract checking. > > On 1, I'm (naïvely) baffled as to why the contract should regard an > optional argument as unsupplied when it comes from the default rather than > an explicit passing. > > GIven that Racket obliges you to supply a default when declaring an > optional argument, in what sort of situations does the unsupplied case > arise? > > Dan > > > > On Sun, May 7, 2017 at 10:36 PM, Dupéron Georges < > jahvascriptman...@gmail.com> wrote: > >> Le dimanche 7 mai 2017 07:27:08 UTC+2, Daniel Prager a écrit : >> > 1. Default argument goes missing from post-condition, leading to an >> > unexpected error ... >> >> You should use unsupplied-arg? . But I couldn't find a way to get the >> default value from the contract. I would guess that the problem is that the >> contract can be specified separately from the function, and the function >> itself knows the default argument's value. In the general case, extracting >> the default argument's value (without running the default expression >> multiple times) might be tricky. >> >> -- > You received this message because you are subscribed to the Google Groups > "Racket Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to racket-users+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
