[racket-dev] Blame and re-provided bindings
On Jan 17, 2011, at 10:53 AM, Robby Findler wrote:
>
> Let me summarize what was important in Casey's message that relates to
> this. He has these files:
>
> redex/gui.rkt
> redex/reduction-semantics.rkt
> redex/main.rkt
>
> The first two export subsets of the Redex library (in order to make it
> easy to depend only on parts of the rest of the system). The third one
> just re-exports the things from the other two.
>
> To do what you're proposing, he'd have to add three more files: 1 with
> the contracts, and two files that are un-contracted versions of the
> first two. Then, he'd have to write a bunch of boilerplate code to put
> all this together in the right way (or write a macro).
>
> It is this example that makes me think we (the contract system
> designers) are doing it wrong.
I would expect this organization:
redex/contracts
redex/private/ : gui reduction-semantics
redex/gui
redex/reduction-semantics
(ignoring that gr2 will make the logical separation superfluous).
The problem is that the last two are thin 'generatable' modules
over the ones in private.
As far as I can see this organization isn't a problem of the
contract system but a problem of the module system. In Racket,
modules are first-order and it is difficult to abstract over the
wrapper process. (I am not sure we could abstract over this process
in the unit world.)
>>> In a sense I was hoping that this would happen if we forced deveoplers
>>> to re-state the contract if re-provide means any/c. But I guess this
>>> is not going to happen.
>
> FWIW, this smacks of an SML-ish way of thinking about this design decision. :)
(1) The word 'smacks' suggests you're escaping from logical arguments
and that you are alluding to emotional anti-SML sentiments. I'll ignore this
aspect of your response.
(2) SML isn't all wrong. Perhaps we can learn from them.
(3) And no, I wasn't thinking of SML at all. I was thinking of our 'market-place'
design forces via contracts.
-- Matthias