[racket-dev] Blame and re-provided bindings

From: Matthias Felleisen (matthias at ccs.neu.edu)
Date: Mon Jan 17 11:10:26 EST 2011

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




Posted on the dev mailing list.