Re: [racket-users] Werid contract violation blame erros

2021-04-09 Thread epi via Racket Users
Thank you, Robby, This clarifies it a little bit. So far I've avoided reading about the racket module system in details, but I think now is as good time as ever. April 7, 2021 10:40 PM, "Robby Findler" mailto:ro...@cs.northwestern.edu?to=%22Robby%20Findler%22%20)> wrote: The short answer: you

Re: [racket-users] Werid contract violation blame erros

2021-04-07 Thread Alex Harsányi
I think "define/contract" protects a function from other incorrect calls from the same module. So your "define/provide/contract" is not really "define/contract" + "provide". Here is an example illustrating the problem, where the call to "bar" correctly reports the contract violation, but the

Re: [racket-users] Werid contract violation blame erros

2021-04-07 Thread Robby Findler
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

Re: [racket-users] Werid contract violation blame erros

2021-04-07 Thread Raoul Duke
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

Re: [racket-users] Werid contract violation blame erros

2021-04-07 Thread Robby Findler
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 wrote:

Re: [racket-users] Werid contract violation blame erros

2021-04-07 Thread David Storrs
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 wrote: > > The short answer:

Re: [racket-users] Werid contract violation blame erros

2021-04-07 Thread Dominik Pantůček
It is worth noting that it is relatively easy to implement a define/provide/contract syntax without any problems. In my two most active projects I use it extensively. In one case even with scribble/srcdoc to keep the contracts, scribblings and implementation in one place. The simplest version:

Re: [racket-users] Werid contract violation blame erros

2021-04-07 Thread Robby Findler
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

[racket-users] Werid contract violation blame erros

2021-04-07 Thread epi via Racket Users
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