On Mon, Jan 17, 2011 at 10:10 AM, Matthias Felleisen <matth...@ccs.neu.edu> wrote: > > 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/contracts.rkt?) > redex/private/ : gui reduction-semantics > redex/gui > redex/reduction-semantics > > > The problem is that the last two are thin 'generatable' modules > over the ones in private. Yes. That is the problem. We're forcing people to write roughly 3 lines for each provided variable (when they are in this multiple interfaces situation) in order to have a default that is, in practice, never the right thing. I have a hard time getting behind this design point. It feels like a lot of make-work. > 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.) That's also possible but, as you say, I'm not sure we'd abstract their either. And, in any case, we are talking about the module world. I think we agree that the right answer to the design choice we're debating is not to say "use units", right? > (ignoring that gr2 will make the logical separation superfluous). This is incorrect. The documentation libraries, for example, are not allowed to depend on racket/gui/base but redex/gui necessarily depends on racket/gui/base, so the separation is still important. (Maybe this will change more in the future, of course, but it won't change for 5.1, I'm pretty sure.) And maybe if you missed that, you might have (or maybe not, but this seems like a reasonable place to mention it -- no offense intended if you already got this bit) missed that racket/draw and racket/snip now exist one can use drawing libraries and snip libraries without depending on racket/gui/base (neither of those depend on racket/gui/base, that is). Robby _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
