Re: [racket-dev] Feature request - contract form that splits provide/contract into two parts
An alternate flow which I think aligns slightly better with graduated code validity vs cost (effort)? 0. Quick and dirty code spikes, snippets in R. 1. Write prototype code directly in TR. - Liberal addition via Step 0 efforts, pre and current with Step 1. - TR is very lightweight. - The single additional type line is negligible in effort and is the singular most concise, effective expression of documentation that one can put in their code. - The benefits of instant TR feedback in DR while coding, IMHO, far out weight considerations of rapid prototyping without TR. - TR in effect is/should be eliding contracts where static type checking can prove safe absence and implicitly inserting contracts contracts based on safety settings. 2. If you like your prototype and you know it will be around awhile: - Selectively transform unchecked contracts into checked contracts - Add contracts which increase code robustness value with consideration of performance overhead. *[1,2] Essentially Step 1: Write prototypes in statically typed code from the get go in TR. Step 2: Turn prototypes into high quality code by adding runtime contracts. [*1] Essentially considered effort by the programmer towards marked enhancement of production/library code validity with all the design-by-contract, pre/post assertions, IO boundary assertions, bounds assertions, etc that a static type checker cannot handle. [*2] The risk is that Step 2 is under appreciated and may not happen, therefore an emphasis in starting in CR (Contract Racket) and then later splitting contracts into orthogonal static (TR) and runtime (CR) proofing of code validity, thus guaranteeing some effort in Step 2 happened at all. Step 1 in no way absolves the programmer of Step 2. On Fri, Dec 28, 2012 at 9:42 AM, Matthias Felleisen matth...@ccs.neu.eduwrote: On Dec 27, 2012, at 8:58 PM, Harry Spier wrote: On Fri, Dec 14, 2012 at 10:44 AM, Matthias Felleisen matth...@ccs.neu.edu wrote: It is critical to inform clients of the services that a module provides. In the absence of types, contracts are the closest information we have. AND On Fri, Dec 14, 2012 at 11:43 AM, Ray Racine ray.rac...@gmail.com wrote: For the TR folks you can have your cake and eat it with a cup of coffee with `provide'. TR Rules Given the above, should you be using Typed Racket instead of contracts whenever possible? Are there cases where if you have the choice you should prefer contracts instead of using Typed Racket No for several reasons: 1. Our contracts are actually more powerful than our types: see http://www.ccs.neu.edu/home/matthias/Style/style/Units_of_Code.html#(part._.Contracts) especially contract for celsius-fahrenheit for an example. (In principle, our type system can express this idea.) 2. We see Racket as a continuum: -- write a script, throw it away -- or grow the script/create prototype with informal contracts and data descriptions -- if you like your prototype and you know it'll be around for a while, turn informal contracts into checked contracts weighing performance impact against importance of checks. -- if you ever maintain any of these modules, split contracts into types and residual contracts. Problem: we still don't have contract-out for TR So you will need to turn contracts into types and throw away residual contracts. One day SAM will get around to this gap. 3. Of course, you should know which entry point is best for you and choose for yourself at which level you wish to enter. The point is with Racket, you have this choice (and with other languages, you don't.) -- Matthias _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Feature request - contract form that splits provide/contract into two parts
I have clarified the interface specification part of the Style guide. The original draft was written before contract-out existed. I have rewritten all provide/contracts into provide plus contract-out. Having said that, I absolutely, definitely think that a tool chain should also support a tool that extract the implemented service interface of a module. As a PL person, my preference is to express all elements of programming with linguistic mechanisms -- because the ultimate information processor is a programmer and I claim that a programmer uses language to think. If we cannot or do not wish to enforce a particular style via a linguistic mechanism, it is due to all kinds of reasons but we should not fall back on tools as our sole way to understand programs. Tools should complement our thinking; we should not substitutes tool for thinking. On Dec 16, 2012, at 9:46 AM, Harry Spier wrote: On Fri, Dec 14, 2012 at 10:44 AM, Matthias Felleisen matth...@ccs.neu.edu wrote: So, if you want to be good, put provide contract-out at the top of your module. How about having a link on the Racket webpage to the Style Guide for this and other style issues? Harry Spier _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Feature request - contract form that splits provide/contract into two parts
On Fri, Dec 14, 2012 at 10:44 AM, Matthias Felleisen matth...@ccs.neu.edu wrote: So, if you want to be good, put provide contract-out at the top of your module. How about having a link on the Racket webpage to the Style Guide for this and other style issues? Harry Spier _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Feature request - contract form that splits provide/contract into two parts
It is critical to inform clients of the services that a module provides. In the absence of types, contracts are the closest information we have. Reading the implementation is against all good SE ideas. IF we could assume that people always programmed in DrRacket, we could compromise and add a tool that synthesizes the interface of a module in some way. Since some contributors break this guideline all the time anyway, we should have such a tool available anyway. BUT there are also people who use Emacs and the other editor. So, if you want to be good, put provide contract-out at the top of your module. On Dec 14, 2012, at 1:02 AM, Harry Spier wrote: If you place provide/contract at the beginning of a module it makes the interface clear but it is separated from its function. If you place it right before its function and not at the top of the module, it makes the function clearer but the module interface is not so clear. Is it possible (would it be a good idea?) to provide a new form that splits the provide/contract form into two parts. One part the contract definition which you could place immediately before the function definition and the second part a provide spec for inclusion in a provide statement that included the function name but not the contract spec.) . That way the contract definition can be by the function definition and the function name can be in a provide statement at the beginning of the module. Harry Spier _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Feature request - contract form that splits provide/contract into two parts
Matthias has vastly more experience and perspective in matters like this; you would be wise to prefer his advice. But if I understand correctly what you want, I think you could do this yourself with a simple macro: (define-syntax define/contract/provide (syntax-rules () [(_ (id . args) contract body ...) (begin (define/contract (id . args) contract body ...) (provide id))] [(_ id contract expr) (begin (define/contract id contract expr) (provide id))])) That's the version I've used in some past projects. However: It uses define/contract promiscuously, which is (a) not universally beloved and (b) much slower than provide/contract in the current version of Racket. Instead I think you could flip it around to use provide/contract, instead: (define-syntax define/provide/contract (syntax-rules () [(_ (id . args) contract body ...) (begin (provide/contract (id . args) contract body ...) (define id))] [(_ id contract expr) (begin (provide/contract id contract expr) (define id))])) I _think_ that's essentially what you're asking for? (Of course this means the function won't be protected by a contract when called from inside the module, which could be considered bad, good, or N/A. Just be aware.) Any approach not using a single provide/contract list has the disadvantage that Matthias explained: The module no longer has a contiguous description of its interface in the source. That's a serious disadvantage. Some might consider it mitigated if the module has Scribble documentation. Also someone reading the source might collapse in Emacs (or whatever) to quickly see all the top-level definitions (although that would include any non-provided items, so it's not perfect (unless the stock collapse is customized)). You could also put a list in comments, I suppose. On Fri, Dec 14, 2012 at 10:44 AM, Matthias Felleisen matth...@ccs.neu.edu wrote: It is critical to inform clients of the services that a module provides. In the absence of types, contracts are the closest information we have. Reading the implementation is against all good SE ideas. IF we could assume that people always programmed in DrRacket, we could compromise and add a tool that synthesizes the interface of a module in some way. Since some contributors break this guideline all the time anyway, we should have such a tool available anyway. BUT there are also people who use Emacs and the other editor. So, if you want to be good, put provide contract-out at the top of your module. On Dec 14, 2012, at 1:02 AM, Harry Spier wrote: If you place provide/contract at the beginning of a module it makes the interface clear but it is separated from its function. If you place it right before its function and not at the top of the module, it makes the function clearer but the module interface is not so clear. Is it possible (would it be a good idea?) to provide a new form that splits the provide/contract form into two parts. One part the contract definition which you could place immediately before the function definition and the second part a provide spec for inclusion in a provide statement that included the function name but not the contract spec.) . That way the contract definition can be by the function definition and the function name can be in a provide statement at the beginning of the module. Harry Spier _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Feature request - contract form that splits provide/contract into two parts
For the TR folks you can have your cake and eat it with a cup of coffee with `provide'. TR Rules #lang typed/racket/base ;;public interface/w specifications (provide: [inc (Integer - Integer)]) ... (: inc (Integer - Integer)) (define (inc x) (add1 x)) ... On Fri, Dec 14, 2012 at 10:44 AM, Matthias Felleisen matth...@ccs.neu.eduwrote: It is critical to inform clients of the services that a module provides. In the absence of types, contracts are the closest information we have. Reading the implementation is against all good SE ideas. IF we could assume that people always programmed in DrRacket, we could compromise and add a tool that synthesizes the interface of a module in some way. Since some contributors break this guideline all the time anyway, we should have such a tool available anyway. BUT there are also people who use Emacs and the other editor. So, if you want to be good, put provide contract-out at the top of your module. On Dec 14, 2012, at 1:02 AM, Harry Spier wrote: If you place provide/contract at the beginning of a module it makes the interface clear but it is separated from its function. If you place it right before its function and not at the top of the module, it makes the function clearer but the module interface is not so clear. Is it possible (would it be a good idea?) to provide a new form that splits the provide/contract form into two parts. One part the contract definition which you could place immediately before the function definition and the second part a provide spec for inclusion in a provide statement that included the function name but not the contract spec.) . That way the contract definition can be by the function definition and the function name can be in a provide statement at the beginning of the module. Harry Spier _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Feature request - contract form that splits provide/contract into two parts
I understood the feature request differently. I take it as wanting to write a module like the following: #lang racket (provide (with-declared-contracts-out f g)) (declare-contract f ) (define f ) (declare-contract g ) (define g ) That is, the contracts themselves are near the functions, so it's easy to keep them in sync. And one can find the names provided by just looking at the top of the module---but you only get the names, not the contracts, so the interface is incomplete. This should be easily doable with some compile-time state. Ryan On 12/14/2012 11:41 AM, Greg Hendershott wrote: Matthias has vastly more experience and perspective in matters like this; you would be wise to prefer his advice. But if I understand correctly what you want, I think you could do this yourself with a simple macro: (define-syntax define/contract/provide (syntax-rules () [(_ (id . args) contract body ...) (begin (define/contract (id . args) contract body ...) (provide id))] [(_ id contract expr) (begin (define/contract id contract expr) (provide id))])) That's the version I've used in some past projects. However: It uses define/contract promiscuously, which is (a) not universally beloved and (b) much slower than provide/contract in the current version of Racket. Instead I think you could flip it around to use provide/contract, instead: (define-syntax define/provide/contract (syntax-rules () [(_ (id . args) contract body ...) (begin (provide/contract (id . args) contract body ...) (define id))] [(_ id contract expr) (begin (provide/contract id contract expr) (define id))])) I _think_ that's essentially what you're asking for? (Of course this means the function won't be protected by a contract when called from inside the module, which could be considered bad, good, or N/A. Just be aware.) Any approach not using a single provide/contract list has the disadvantage that Matthias explained: The module no longer has a contiguous description of its interface in the source. That's a serious disadvantage. Some might consider it mitigated if the module has Scribble documentation. Also someone reading the source might collapse in Emacs (or whatever) to quickly see all the top-level definitions (although that would include any non-provided items, so it's not perfect (unless the stock collapse is customized)). You could also put a list in comments, I suppose. On Fri, Dec 14, 2012 at 10:44 AM, Matthias Felleisen matth...@ccs.neu.edu wrote: It is critical to inform clients of the services that a module provides. In the absence of types, contracts are the closest information we have. Reading the implementation is against all good SE ideas. IF we could assume that people always programmed in DrRacket, we could compromise and add a tool that synthesizes the interface of a module in some way. Since some contributors break this guideline all the time anyway, we should have such a tool available anyway. BUT there are also people who use Emacs and the other editor. So, if you want to be good, put provide contract-out at the top of your module. On Dec 14, 2012, at 1:02 AM, Harry Spier wrote: If you place provide/contract at the beginning of a module it makes the interface clear but it is separated from its function. If you place it right before its function and not at the top of the module, it makes the function clearer but the module interface is not so clear. Is it possible (would it be a good idea?) to provide a new form that splits the provide/contract form into two parts. One part the contract definition which you could place immediately before the function definition and the second part a provide spec for inclusion in a provide statement that included the function name but not the contract spec.) . That way the contract definition can be by the function definition and the function name can be in a provide statement at the beginning of the module. Harry Spier _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Feature request - contract form that splits provide/contract into two parts
That is precisely how I understood the contract. And that is precisely why I wrote down why I object. On Dec 14, 2012, at 11:55 AM, Ryan Culpepper wrote: I understood the feature request differently. I take it as wanting to write a module like the following: #lang racket (provide (with-declared-contracts-out f g)) (declare-contract f ) (define f ) (declare-contract g ) (define g ) That is, the contracts themselves are near the functions, so it's easy to keep them in sync. And one can find the names provided by just looking at the top of the module---but you only get the names, not the contracts, so the interface is incomplete. This should be easily doable with some compile-time state. Ryan On 12/14/2012 11:41 AM, Greg Hendershott wrote: Matthias has vastly more experience and perspective in matters like this; you would be wise to prefer his advice. But if I understand correctly what you want, I think you could do this yourself with a simple macro: (define-syntax define/contract/provide (syntax-rules () [(_ (id . args) contract body ...) (begin (define/contract (id . args) contract body ...) (provide id))] [(_ id contract expr) (begin (define/contract id contract expr) (provide id))])) That's the version I've used in some past projects. However: It uses define/contract promiscuously, which is (a) not universally beloved and (b) much slower than provide/contract in the current version of Racket. Instead I think you could flip it around to use provide/contract, instead: (define-syntax define/provide/contract (syntax-rules () [(_ (id . args) contract body ...) (begin (provide/contract (id . args) contract body ...) (define id))] [(_ id contract expr) (begin (provide/contract id contract expr) (define id))])) I _think_ that's essentially what you're asking for? (Of course this means the function won't be protected by a contract when called from inside the module, which could be considered bad, good, or N/A. Just be aware.) Any approach not using a single provide/contract list has the disadvantage that Matthias explained: The module no longer has a contiguous description of its interface in the source. That's a serious disadvantage. Some might consider it mitigated if the module has Scribble documentation. Also someone reading the source might collapse in Emacs (or whatever) to quickly see all the top-level definitions (although that would include any non-provided items, so it's not perfect (unless the stock collapse is customized)). You could also put a list in comments, I suppose. On Fri, Dec 14, 2012 at 10:44 AM, Matthias Felleisen matth...@ccs.neu.edu wrote: It is critical to inform clients of the services that a module provides. In the absence of types, contracts are the closest information we have. Reading the implementation is against all good SE ideas. IF we could assume that people always programmed in DrRacket, we could compromise and add a tool that synthesizes the interface of a module in some way. Since some contributors break this guideline all the time anyway, we should have such a tool available anyway. BUT there are also people who use Emacs and the other editor. So, if you want to be good, put provide contract-out at the top of your module. On Dec 14, 2012, at 1:02 AM, Harry Spier wrote: If you place provide/contract at the beginning of a module it makes the interface clear but it is separated from its function. If you place it right before its function and not at the top of the module, it makes the function clearer but the module interface is not so clear. Is it possible (would it be a good idea?) to provide a new form that splits the provide/contract form into two parts. One part the contract definition which you could place immediately before the function definition and the second part a provide spec for inclusion in a provide statement that included the function name but not the contract spec.) . That way the contract definition can be by the function definition and the function name can be in a provide statement at the beginning of the module. Harry Spier _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Feature request - contract form that splits provide/contract into two parts
Thou shall not copy code. You should (define-type i2i (Integer - Integer)) so that you don't have to repeat the type. On Dec 14, 2012, at 11:43 AM, Ray Racine wrote: For the TR folks you can have your cake and eat it with a cup of coffee with `provide'. TR Rules #lang typed/racket/base ;;public interface/w specifications (provide: [inc (Integer - Integer)]) ... (: inc (Integer - Integer)) (define (inc x) (add1 x)) ... On Fri, Dec 14, 2012 at 10:44 AM, Matthias Felleisen matth...@ccs.neu.edu wrote: It is critical to inform clients of the services that a module provides. In the absence of types, contracts are the closest information we have. Reading the implementation is against all good SE ideas. IF we could assume that people always programmed in DrRacket, we could compromise and add a tool that synthesizes the interface of a module in some way. Since some contributors break this guideline all the time anyway, we should have such a tool available anyway. BUT there are also people who use Emacs and the other editor. So, if you want to be good, put provide contract-out at the top of your module. On Dec 14, 2012, at 1:02 AM, Harry Spier wrote: If you place provide/contract at the beginning of a module it makes the interface clear but it is separated from its function. If you place it right before its function and not at the top of the module, it makes the function clearer but the module interface is not so clear. Is it possible (would it be a good idea?) to provide a new form that splits the provide/contract form into two parts. One part the contract definition which you could place immediately before the function definition and the second part a provide spec for inclusion in a provide statement that included the function name but not the contract spec.) . That way the contract definition can be by the function definition and the function name can be in a provide statement at the beginning of the module. Harry Spier _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Feature request - contract form that splits provide/contract into two parts
The `plot' library uses `unstable/latent-contract' to do exactly that.
Example: the identity function restricted to `integer?' values:
#lang racket
(module internal-provider racket
(require unstable/latent-contract/defthing)
(provide int-id int-id:doc) ; export doc generator too
(defproc (int-id [x integer?]) integer?
x))
(module external-provider racket
(require (submod .. internal-provider)
unstable/latent-contract)
(provide (activate-contract-out int-id)))
(require (prefix-in internal: 'internal-provider))
(internal:int-id 'x) ; no error
(require 'external-provider)
(int-id 'x) ; contract error blaming 'external-provider
The `activate-contract-out' provide transformer expands to a
`contract-out'. IIRC, `int-id' is an applicable struct whose instances
carry contract information.
Pros:
1. Easily allows using either contracted or uncontracted values
2. Puts contracts near function definition
3. Keeps documented contracts in sync with actual contracts:
#lang scribble/manual
@(require unstable/latent-contract/defthing
(submod ../private/int-id.rkt internal-provider))
@doc-apply[int-id]{Returns @racket[x].}
Cons:
A. Often gets awkward with higher-order functions
B. Keeps contracts away from the tops of modules
C. Function argument names become part of the documented interface
There are also forms for defining parameters and regular values.
I think having a `declare-contract' form would possibly solve (2) (you
could move them to the top of the file when the library is stable) and
possibly help with (A). But it would make it hard, if not impossible, to
generate documentation.
Also, I'd want to call it `:' instead of `declare-contract' to make it
more obvious how to convert untyped programs to Typed Racket.
I hadn't documented `unstable/latent-contract' yet because I considered
it too experimental. It's worked really well in `plot', though. In
particular, automatically generating documentation has been great
because so many documented functions have such large contracts.
Neil ⊥
On 12/14/2012 09:55 AM, Ryan Culpepper wrote:
I understood the feature request differently. I take it as wanting to
write a module like the following:
#lang racket
(provide
(with-declared-contracts-out
f
g))
(declare-contract f )
(define f )
(declare-contract g )
(define g )
That is, the contracts themselves are near the functions, so it's easy
to keep them in sync. And one can find the names provided by just
looking at the top of the module---but you only get the names, not the
contracts, so the interface is incomplete.
This should be easily doable with some compile-time state.
Ryan
On 12/14/2012 11:41 AM, Greg Hendershott wrote:
Matthias has vastly more experience and perspective in matters like
this; you would be wise to prefer his advice.
But if I understand correctly what you want, I think you could do this
yourself with a simple macro:
(define-syntax define/contract/provide
(syntax-rules ()
[(_ (id . args) contract body ...)
(begin
(define/contract (id . args) contract body ...)
(provide id))]
[(_ id contract expr)
(begin
(define/contract id contract expr)
(provide id))]))
That's the version I've used in some past projects. However: It uses
define/contract promiscuously, which is (a) not universally beloved
and (b) much slower than provide/contract in the current version of
Racket.
Instead I think you could flip it around to use provide/contract,
instead:
(define-syntax define/provide/contract
(syntax-rules ()
[(_ (id . args) contract body ...)
(begin
(provide/contract (id . args) contract body ...)
(define id))]
[(_ id contract expr)
(begin
(provide/contract id contract expr)
(define id))]))
I _think_ that's essentially what you're asking for?
(Of course this means the function won't be protected by a contract
when called from inside the module, which could be considered bad,
good, or N/A. Just be aware.)
Any approach not using a single provide/contract list has the
disadvantage that Matthias explained: The module no longer has a
contiguous description of its interface in the source.
That's a serious disadvantage. Some might consider it mitigated if the
module has Scribble documentation. Also someone reading the source
might collapse in Emacs (or whatever) to quickly see all the
top-level definitions (although that would include any non-provided
items, so it's not perfect (unless the stock collapse is customized)).
You could also put a list in comments, I suppose.
On Fri, Dec 14, 2012 at 10:44 AM, Matthias Felleisen
matth...@ccs.neu.edu wrote:
It is critical to inform clients of the services that a module
provides. In the absence of types, contracts are the closest
information we have. Reading the implementation is against
all good SE ideas.
IF we could assume that people always
Re: [racket-dev] Feature request - contract form that splits provide/contract into two parts
What Ryan describes is what I was asking for but I now see what Matthias's saying, that the contract information belongs in the interface at the top of the module. The Racket Guide section on contracts starts out with provide (contract/out . . . at the start of the module but from section 7.3.2 onwards a lot of the examples have(provide (contract/out ... after the function definition. Thanks, Harry Spier On Fri, Dec 14, 2012 at 11:55 AM, Ryan Culpepper r...@cs.utah.edu wrote: I understood the feature request differently. I take it as wanting to write a module like the following: #lang racket (provide (with-declared-contracts-out f g)) (declare-contract f ) (define f ) (declare-contract g ) (define g ) That is, the contracts themselves are near the functions, so it's easy to keep them in sync. And one can find the names provided by just looking at the top of the module---but you only get the names, not the contracts, so the interface is incomplete. This should be easily doable with some compile-time state. Ryan On 12/14/2012 11:41 AM, Greg Hendershott wrote: Matthias has vastly more experience and perspective in matters like this; you would be wise to prefer his advice. But if I understand correctly what you want, I think you could do this yourself with a simple macro: (define-syntax define/contract/provide (syntax-rules () [(_ (id . args) contract body ...) (begin (define/contract (id . args) contract body ...) (provide id))] [(_ id contract expr) (begin (define/contract id contract expr) (provide id))])) That's the version I've used in some past projects. However: It uses define/contract promiscuously, which is (a) not universally beloved and (b) much slower than provide/contract in the current version of Racket. Instead I think you could flip it around to use provide/contract, instead: (define-syntax define/provide/contract (syntax-rules () [(_ (id . args) contract body ...) (begin (provide/contract (id . args) contract body ...) (define id))] [(_ id contract expr) (begin (provide/contract id contract expr) (define id))])) I _think_ that's essentially what you're asking for? (Of course this means the function won't be protected by a contract when called from inside the module, which could be considered bad, good, or N/A. Just be aware.) Any approach not using a single provide/contract list has the disadvantage that Matthias explained: The module no longer has a contiguous description of its interface in the source. That's a serious disadvantage. Some might consider it mitigated if the module has Scribble documentation. Also someone reading the source might collapse in Emacs (or whatever) to quickly see all the top-level definitions (although that would include any non-provided items, so it's not perfect (unless the stock collapse is customized)). You could also put a list in comments, I suppose. On Fri, Dec 14, 2012 at 10:44 AM, Matthias Felleisen matth...@ccs.neu.edu wrote: It is critical to inform clients of the services that a module provides. In the absence of types, contracts are the closest information we have. Reading the implementation is against all good SE ideas. IF we could assume that people always programmed in DrRacket, we could compromise and add a tool that synthesizes the interface of a module in some way. Since some contributors break this guideline all the time anyway, we should have such a tool available anyway. BUT there are also people who use Emacs and the other editor. So, if you want to be good, put provide contract-out at the top of your module. On Dec 14, 2012, at 1:02 AM, Harry Spier wrote: If you place provide/contract at the beginning of a module it makes the interface clear but it is separated from its function. If you place it right before its function and not at the top of the module, it makes the function clearer but the module interface is not so clear. Is it possible (would it be a good idea?) to provide a new form that splits the provide/contract form into two parts. One part the contract definition which you could place immediately before the function definition and the second part a provide spec for inclusion in a provide statement that included the function name but not the contract spec.) . That way the contract definition can be by the function definition and the function name can be in a provide statement at the beginning of the module. Harry Spier _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list:
[racket-dev] Feature request - contract form that splits provide/contract into two parts
If you place provide/contract at the beginning of a module it makes the interface clear but it is separated from its function. If you place it right before its function and not at the top of the module, it makes the function clearer but the module interface is not so clear. Is it possible (would it be a good idea?) to provide a new form that splits the provide/contract form into two parts. One part the contract definition which you could place immediately before the function definition and the second part a provide spec for inclusion in a provide statement that included the function name but not the contract spec.) . That way the contract definition can be by the function definition and the function name can be in a provide statement at the beginning of the module. Harry Spier _ Racket Developers list: http://lists.racket-lang.org/dev
