On Aug 26, 2014, at 10:02 PM, Kevin Forchione <[email protected]> wrote:
>
> On Aug 26, 2014, at 2:53 PM, Matthias Felleisen <[email protected]> wrote:
>
>>
>>
>> We should probably document this little trick somewhere. -- Matthias
>
> Yes please. It would be useful in the Contract documentation, perhaps as a
> link pointing to the illustration in the Modules documentation. So by
> requiring the enclosing module as a submodule the bindings are redefined (or
> reinitialized) as specified by the module’s provide? So if the enclosing
> module didn’t provide certain bindings would the module+ still have access to
> those bindings from the enclosing module?
>
> Also, this seems like such a useful construct that it might be nice to have a
> shorthand. e.g. (module++ …)?
>
> -Kevin
I’ve played around a bit with (module+ …) and can rule out the idea that
requiring the enclosing module would limit access to bindings not in the
enclosing module’s provide form. But the provide does affect the innings of
available within the (module+ …) form. For example:
#lang racket
(provide (rename-out [foo bar]))
(define (foo n) n)
(module+ test
(require (submod ".."))
(foo 3)
(bar 3))
This will return 3 from the foo function and 3 from the bar rename. So it seems
logical that the contracts are imported into the module. The question then
remains how… The following is interesting:
#lang racket
(provide (contract-out [foo
(-> string? list?)])
(rename-out (foo bar)))
(define (foo n) (list n))
(module+ test
(require (submod ".."))
(foo 3)
(bar "3”))
Here foo violates the contract. Changing the argument to foo to “3” and the
argument to bar to 3 shows that bar does not violate the contract. So the
contract is bound to foo and not to the rename. Quite interesting!
-Kevin____________________
Racket Users list:
http://lists.racket-lang.org/users
