Although I understand why my macro does this unsafe-factorial: contract violation ... blaming: (function fn/impl) ... at: unsaved-editor:13.15
Ideally I would prefer one which blames unsafe-factorial unsafe-factorial: contract violation ... blaming: (function unsafe-factorial) ... at: unsaved-editor:13.15 i.e. it's leaking an auxillary introduced by the macro (fn/impl) into the message & Dr Racket. It seems that the line-number refers to the line that defines unsafe-factorial, though, which looks right. I could ameliorate this by having my macro give a more suggestive name e.g. "unsafe-factorial/impl", but perhaps there's a better approach. * * * Matthias wrote > The only thing that leaks is that >/c is actually an and/c contract — and I will say I am rather surprised by that. Me too! I ended up switching my contract to (and/c integer? (not not/c negative?)) to remove the inconsistency, but it does seem to point to another leak. Dan On Sun, May 7, 2017 at 12:25 AM, Matthias Felleisen <matth...@ccs.neu.edu> wrote: > > On May 5, 2017, at 11:30 PM, Daniel Prager <daniel.a.pra...@gmail.com> > wrote: > > Thank-you Matthias > > That's neat! > > And yes, I can write a basic macro. By introducing #:freevar I was able to > improve the blame situation, but the abstraction is a bit leaky ... > > (define-syntax-rule (define/tight (fn args ...) > ctc > body ...) > (begin > (define (fn args ...) (fn/impl args ...)) > (define/contract (fn/impl args ...) > ctc > #:freevar fn ctc ; Directs blame to "fn/impl" rather than the > enclosing module > body ...))) > > > > I am not sure what you mean by ‘leaky’. When I run this, > > (define/tight [unsafe-factorial n] > (-> (and/c integer? (>=/c 0)) (and/c integer? (>=/c 0))) > (if (zero? n) > 1 > (* n (unsafe-factorial (- n 10))))) > (unsafe-factorial 5) ; Does not terminate > > I get > > unsafe-factorial: contract violation > expected: (and/c real? (not/c negative?)) > given: -5 > in: an and/c case of > the 1st argument of > (-> > (and/c > integer? > (and/c real? (not/c negative?))) > (and/c > integer? > (and/c real? (not/c negative?)))) > contract from: anonymous-module > blaming: (function fn/impl) > (assuming the contract is correct) > at: unsaved-editor:13.15 > > > > The only thing that leaks is that >/c is actually an and/c contract — and > I will say I am rather surprised by that. > > -- 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. For more options, visit https://groups.google.com/d/optout.
