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 _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev