[racket] Racket style guide (was Re: Argument order conventions (was: Variable naming conventions))

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
<matthias at 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 <matthias at 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
>