FWIW, I agree that this organization is great, but this: (define world/c (flat-named-contract 'world (lambda (x) (world? x))))
is unfortunate. The contract error messages (in the case that you also export world? which I hope you'd do here so that you clients can use dynamic checks to determine if they are going to use your functions) will also be slightly worse since they won't use the predicate name. If you wanted to be friendly to the, you'd really have to write this instead: (define world/c (let ([world? (lambda (x) (world? x))]) world?)) and you'd be relying on a kind of dirty trick to get the contract error messages right. I don't have a good solution to this either and I have also, like Doug, experimented with putting all this stuff at the end of the file. How did this come up in Modula 2 (or how was it avoided is maybe the right question)? Robby On Thu, Sep 22, 2011 at 11:14 AM, Matthias Felleisen <matth...@ccs.neu.edu> wrote: > > > When struct defs are short and sweet, I put them at the top. > > If I want to stick strictly to the suggestion, I act like this: > > #lang racket > > ;; here are the data i work with > (define world/c > (flat-named-contract 'world (lambda (x) (world? x)))) > > (define prime/c > (and/c number? (lambda (x) #true))) > > ;; here are the services I provide > (provide/contract > [world/c contract?] > [change-world (-> world/c prime/c world/c)]) > > ;; here is how the services are implemented > (struct world (dot)) > > (define (change-world w p) > (world p)) > > ;; --- > > Note that this guideline reflects a personal preference. There are probably > Racketeers who consider it stupid or something like that. I find it important > to list first what data I deal with and what services I provide (formulated > in terms of data/contracts). The implementation is something I shouldn't have > to read. > > Personally, I'd love to see even more of a separation between the header > (data + provide) and the implementation. Perhaps I read too much Modula 2 > code, perhaps I liked units too much. > > -- Matthias > > > > > > On Sep 22, 2011, at 12:00 PM, Doug Williams wrote: > >> Matthias, >> >> In the style guide it suggests requires, auxiliary concepts related to the >> contracts, provide/contract, and then the body of the module. One problem I >> have is that I often use structs to define new data types and use the >> resulting structure type predicate - <type name>? - in many contracts. This >> forces the provide/contract to be at (or near) the bottom of the module. So, >> I had just started putting it there all the time. [The provide/contract >> seems to require the 'auxiliary concepts' to already be defined.] >> >> Would it be better for me to define a <type name>/c flat-named contract for >> the struct and move it back to the top? I assume I can use a forward >> reference to a module variable - i.e., <type name>? - in the >> named-flat-contract. >> >> Doug >> >> On Wed, Sep 14, 2011 at 6:47 PM, Matthias Felleisen <matth...@ccs.neu.edu> >> wrote: >> >> >> For the past few months, I have been writing a style guide for new Racket >> PLTers. The current draft is available at >> >> http://www.ccs.neu.edu/home/matthias/Style/style/ >> >> I had hoped to complete it a bit more and polish it a bit more, but this >> discussion suggests that people might be interested in reading it and >> commenting on it. >> >> -- Matthias >> >> >> _________________________________________________ >> For list-related administrative tasks: >> http://lists.racket-lang.org/listinfo/users >> > > > _________________________________________________ > For list-related administrative tasks: > http://lists.racket-lang.org/listinfo/users > _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/users
