suzanne.soy/racket
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

fewer quotes

Browse Source
This commit is contained in:
Robby Findler 2015-05-19 11:17:17 -05:00
parent d30b90cba3
commit 78ecccc2b1
1 changed files with 10 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

20
pkgs/racket-doc/scribblings/guide/contracts/new-combinators.scrbl
View File

@ -67,13 +67,13 @@ The new argument specifies who is to be blamed for
positive and negative contract violations. positive and negative contract violations.
Contracts, in this system, are always Contracts, in this system, are always
established between two parties. One party, the "server," provides some established between two parties. One party, called the server, provides some
value according to the contract, and the other, the "client," consumes the value according to the contract, and the other, the client, consumes the
value, also according to the contract. The "server" is called value, also according to the contract. The server is called
the ``positive'' person and the "client" the ``negative''. So, the positive position and the client the negative position. So,
in the case of just the integer contract, the only thing in the case of just the integer contract, the only thing
that can go wrong is that the value provided is not an that can go wrong is that the value provided is not an
integer. Thus, only the positive party (the "server") can ever accrue integer. Thus, only the positive party (the server) can ever accrue
blame. The @racket[raise-blame-error] function always blames blame. The @racket[raise-blame-error] function always blames
the positive party. the positive party.
@ -114,18 +114,18 @@ This technique is not merely a cheap trick to get the example to work,
however. The reversal of the positive and the negative is a however. The reversal of the positive and the negative is a
natural consequence of the way functions behave. That is, natural consequence of the way functions behave. That is,
imagine the flow of values in a program between two imagine the flow of values in a program between two
modules. First, one module (the "server") defines a function, and then that modules. First, one module (the server) defines a function, and then that
module is required by another (the "client"). So far, the function itself module is required by another (the client). So far, the function itself
has to go from the original, providing module to the has to go from the original, providing module to the
requiring module. Now, imagine that the providing module requiring module. Now, imagine that the providing module
invokes the function, supplying it an argument. At this invokes the function, supplying it an argument. At this
point, the flow of values reverses. The argument is point, the flow of values reverses. The argument is
traveling back from the requiring module to the providing traveling back from the requiring module to the providing
module! The "client" is "serving" the argument to the "server," module! The client is ``serving'' the argument to the server,
and the "server" is recieving that value as a "client." and the server is receiving that value as a client.
And finally, when the function produces a result, And finally, when the function produces a result,
that result flows back in the original that result flows back in the original
direction from "server" to "client." direction from server to client.
Accordingly, the contract on the domain reverses Accordingly, the contract on the domain reverses
the positive and the negative blame parties, just like the flow the positive and the negative blame parties, just like the flow
of values reverses. of values reverses.