Two complaints in one day about the wording of these clauses. Let's do something about the English.
I have another one, unrelated: I don't like the 'self-blame'. I have encountered this now a couple of times, and I think we should use the Eiffel terminology of promised required ensured etc. This may just appeal to non-Racketeers when they see the contract violation reports. On Jan 14, 2011, at 5:24 PM, Casey Klein wrote: > On Fri, Jan 14, 2011 at 3:28 PM, Stevie Strickland <sstri...@ccs.neu.edu> > wrote: >> On Jan 14, 2011, at 4:22 PM, Robby Findler wrote: >>> No, actually in this case the user message is also wrong. If you trace >>> thru the module dag, you'll see it. >> >> Just to check, are you talking about the second series of modules, or the >> first? The problem in the first is likely a variation of PR11084, as Ryan >> said. In the second, I get: >> >> contract violation: expected <integer?>, given: 3.5 >> contract on f from (file /Users/sstrickl/c.rkt) via (file >> /Users/sstrickl/a.rkt), blaming (file /Users/sstrickl/b.rkt) >> contract: (-> integer? integer?) >> at: /Users/sstrickl/c.rkt:4.1 >> >> and if I'm breaking that text down correctly, that's: >> >> positive: c >> user: a >> negative: b >> >> Which seems right to me, according to what I said. That is, b entered into >> a contract with c about value f. b reprovided f (with no contract) to a, >> who actually used the value via the expression `(f 3.5)'. >> >> So a misused the value, but b was responsible for its misuse (since it gave >> it to a without any additional protection). This is, of course, going by >> the interpretation of uncontracted reprovides being equivalent to >> reproviding with the contract any/c. >> > > FWIW, I had no idea what the message's "via" clause meant. > > I recognize that "blaming x" has a particular technical meaning, but > the emphasis in the phrasing seems backwards -- the "via" module > sounds like an innocent bystander to the "blaming" module's mistake, > but it's precisely the other way around. > > Regardless, though, I still think we need some way to re-export a > contracted value that makes the re-importer the negative party on the > contract. > _________________________________________________ > For list-related administrative tasks: > http://lists.racket-lang.org/listinfo/dev _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
