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 call to "foo" does not:
#lang racket
(define-syntax (define/provide/contract stx)
(syntax-case stx ()
((_ (name args ...)
contract
body ...)
#'(begin
(provide (contract-out (name contract)))
(define (name args ...)
body ...)))))
(define/provide/contract (foo a)
(-> integer? any/c)
(printf "a = ~a~%" a))
(define/contract (bar a)
(-> integer? any/c)
(printf "a = ~a~%" a))
(foo "Hello")
(bar "Hello")
On Thursday, April 8, 2021 at 4:47:39 AM UTC+8 [email protected]
wrote:
> 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:
>
> (define-syntax (define/provide/contract stx)
> (syntax-case stx ()
> ((_ (name args ...)
> contract
> body ...)
> #'(begin
> (provide (contract-out (name contract)))
> (define (name args ...)
> body ...)))))
>
> Of course, this is not the best approach for all situations (and I do
> not use it everywhere), but it covers many common use-cases well.
>
>
> Dominik
>
> On 07. 04. 21 22:34, Robby Findler 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
> > <[email protected] <mailto:[email protected]>>
> > 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 [email protected]
> > <mailto:racket-users%[email protected]>.
> > To view this discussion on the web visit
> >
> https://groups.google.com/d/msgid/racket-users/149cfc632cd666ff1a92177dce90296b%40disroot.org
> > <
> 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 [email protected]
> > <mailto:[email protected]>.
> > 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
> > <
> https://groups.google.com/d/msgid/racket-users/CAL3TdONLMx%3Dy_cgfDsY_k9L9yaX_touO52phiK9scziW_jGrOA%40mail.gmail.com?utm_medium=email&utm_source=footer
> >.
>
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/racket-users/9e423bd1-3a26-4c13-a722-66b228a3eeb1n%40googlegroups.com.
