The idea is that a contract violation is not merely telling you "oh, someone said that you should get an integer? here and you didn't." That is what an assert macro might do. But contracts offer more.
Contracts are also giving you information to help you hone in on where the error actually is in your code. The rough idea is that you think of your program as partitioned into a bunch of pieces. And then contracts "stand guard" between those pieces, attempting to stop bogus stuff from crossing over from one piece to another piece. (Simplest form of "piece" for Racket: a file (containing a module).) So when you put a boundary between `f` and its containing module, you station guards there -- they tell you "something bogus came out of f" or "something bogus went into f". For the former/first one of those errors, it is clear: f is wrong. For the second, however, we have to decide -- who is this guard standing between? In this code, when we use define/contract, the other side of the boundary is the rest of the module containing f. But then, you say -- what happened with b.rkt?! Well, there was no guard on that boundary! So a.rkt didn't put anything to guard that boundary, so no checks happened and off the value went -- but now, hiding inside that value is the guard, and that guard knows only that boundary it started on, so when that bad input comes in, it blames a.rkt. a.rkt _could_ have protected itself (using contract-out to station a guard on the boundary between a.rkt and b.rkt, but it didn't --coulda shoulda woulda). Anyway, that's the original idea, dating back to about 2002. More recently, Christos Dimoulas together with Lukas Lazarek has started an ambitious research program to try to actually verify that this way of erecting boundaries actually helps the programmer. Here's a paper on the topic if you're interested: https://dl.acm.org/doi/10.1145/3371133 Robby On Wed, Apr 7, 2021 at 6:28 PM Raoul Duke <rao...@gmail.com> wrote: > Clueless newb here. Wait, why can't we have both? As a joe programmer > on the street I would want the blame to be on b.rkt, and also on any > function calling f() incorrectly from inside a.rkt. Reading this > thread it sounds to me like that's not easily available? > > On Wed, Apr 7, 2021 at 4:22 PM Robby Findler <ro...@cs.northwestern.edu> > wrote: > > > > No, I don't think it is a bad move if that's your goal! (I usually work > at the file-level granularity but different code calls for different > things.) I inferred from epi's message that that wasn't what was going on > (perhaps incorrectly). > > > > Robby > > > > On Wed, Apr 7, 2021 at 4:37 PM David Storrs <david.sto...@gmail.com> > wrote: > >> > >> I've always liked define/contract because it guarantees the safety of > >> the function from erroneous calls by other functions in the module, > >> which helps with debugging and testing. It sounds like you think > >> that's a bad move? > >> > >> On Wed, Apr 7, 2021 at 4:35 PM Robby Findler <ro...@cs.northwestern.edu> > wrote: > >> > > >> > The short answer: you probably should use (provide > (contract-out....)) instead of define/contract. > >> > > >> > The slightly longer answer: when you write a contract, you are not > just describing what the legal inputs and outputs are, you are also > establishing a *boundary* between two regions of code. In the case of > define/contract, you are establishing a boundary between the function > (here: f) and the module that it contains (here the file "a.rkt"). In the > case of (provide (contract-out ...)) the boundary is between a.rkt and > b.rkt. > >> > > >> > The slightly uncomfortable answer: it is my (not completely solid > yet) opinion that the boundary that is drawn for define/contract is perhaps > not the right / best one. In a theoretical/mathematical sense it is a > completely fine and completely defensible one. But it trips people up > sometimes. (There are examples others have posted in the past that are > perhaps even stranger than yours but boil down to the same specific design > choice for define/contract.) > >> > > >> > Robby > >> > > >> > > >> > > >> > On Wed, Apr 7, 2021 at 2:10 PM epi via Racket Users < > racket-users@googlegroups.com> wrote: > >> >> > >> >> Hello Racket users, > >> >> > >> >> I am trying to understand a contract violation message that I am > getting. > >> >> Here is the file a.rkt: > >> >> > >> >> #lang racket > >> >> (provide f) > >> >> (define/contract (f a) > >> >> (-> boolean? any/c) > >> >> '()) > >> >> > >> >> and this is b.rkt: > >> >> > >> >> #lang racket > >> >> (require "a.rkt") > >> >> (f 3) > >> >> > >> >> > >> >> I would expect that the caller is blamed for the contract violation, > but the error message that I get is as follows: > >> >> > >> >> > >> >> f: contract violation > >> >> expected: boolean? > >> >> given: 3 > >> >> in: the 1st argument of > >> >> (-> boolean? any/c) > >> >> contract from: (function f) > >> >> blaming: /home/epi/snippets/a.rkt > >> >> (assuming the contract is correct) > >> >> at: /home/epi/snippets/a.rkt:3.18 > >> >> context...: > >> >> > /usr/share/racket/collects/racket/contract/private/blame.rkt:347:0: > raise-blame-error > >> >> > /usr/share/racket/collects/racket/contract/private/arrow-higher-order.rkt:379:33 > >> >> body of "/home/dan/snippets/blameme.rkt" > >> >> > >> >> So, I am a bit surprised that the error message blames the file > a.rkt. > >> >> What am I missing here? > >> >> > >> >> -- > >> >> You received this message because you are subscribed to the Google > Groups "Racket Users" group. > >> >> To unsubscribe from this group and stop receiving emails from it, > send an email to racket-users+unsubscr...@googlegroups.com. > >> >> To view this discussion on the web visit > https://groups.google.com/d/msgid/racket-users/149cfc632cd666ff1a92177dce90296b%40disroot.org > . > >> > > >> > -- > >> > You received this message because you are subscribed to the Google > Groups "Racket Users" group. > >> > To unsubscribe from this group and stop receiving emails from it, > send an email to racket-users+unsubscr...@googlegroups.com. > >> > To view this discussion on the web visit > https://groups.google.com/d/msgid/racket-users/CAL3TdONLMx%3Dy_cgfDsY_k9L9yaX_touO52phiK9scziW_jGrOA%40mail.gmail.com > . > >> > >> -- > >> You received this message because you are subscribed to the Google > Groups "Racket Users" group. > >> To unsubscribe from this group and stop receiving emails from it, send > an email to racket-users+unsubscr...@googlegroups.com. > >> To view this discussion on the web visit > https://groups.google.com/d/msgid/racket-users/CAE8gKofSq%3DvzFV3jt3fkMbzMqV%3Dt9%2BHtj1y02Nsku_ZXF6%2BB5A%40mail.gmail.com > . > > > > -- > > You received this message because you are subscribed to the Google > Groups "Racket Users" group. > > To unsubscribe from this group and stop receiving emails from it, send > an email to racket-users+unsubscr...@googlegroups.com. > > To view this discussion on the web visit > https://groups.google.com/d/msgid/racket-users/CAL3TdOO3P5eYn_GW8jmKO82haXvXNbKWJodeRh1%2BZ58y3SH%3DsQ%40mail.gmail.com > . > > -- > You received this message because you are subscribed to the Google Groups > "Racket Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to racket-users+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/racket-users/CAJ7XQb7a_x0yK755rJbrEXM2OvV_oWVQ-ar8tqdqEShbDeUEvw%40mail.gmail.com > . > -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/CAL3TdOPndR8M769D_nneDmfcpgnJrKwBOzDH8czFmf%2BphbhkaA%40mail.gmail.com.
