On 10/08/2011 10:12 AM, Matthias Felleisen wrote:
(1) I do not understand Neil's problem. Say I have module A and
want to protect its exports from abuses by clients, say module B,
why do you use define/contract at all? The define/contract form
is for splitting modules into module-lets -- in case your module
is too large and you can't manage invariants in your head.
Which now I see that you can *infer* from the docs, if you already sort
of know this. They're kinda jagony. But now I understand, so thank you.
The thing is, define/contract has a huge advantage that contract-out
doesn't have: it puts all the invariants at the function definition,
right before the code that relies on them. I suppose I could get the
same effect with a contract-out right before the function definition (or
write a define/provide macro). But I think the style guidelines say this
is bad, and I don't like scattering provides throughout code.
If you
believe that this is true for even small modules, I urge you to
use Typed Racket. That's the better solution and real soon now
TR will allow you to add contracts on top of types at provides.
I would love to, if not for all the keyword arguments. :( That is
seriously the only thing keeping me from making PLoT into a typed library.
(2) I object to
provide-with-whatever-contract-you-already-have
because I think programmers should explicitly state what
they want (if they want something logical).
I can't explicitly say what I want right now, and I think it's logical.
Would the following be explicit enough?
(provide (contract-out real-id))
; ... more code ...
(define/contract (real-id x) (real? . -> . real?)
x)
Or (provide (lift-contract real-id)) might be even better.
Thanks,
Neil T
_________________________________________________
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/users
