Just following up to say thank you. I especially appreciated seeing several iterations of this to clarify things.
On Mon, Jul 30, 2018 at 6:40 AM Philip McGrath <phi...@philipmcgrath.com> wrote: > Since #t and #f can be used as contracts that recognize only themselves, > you can get a step better in terms of concision: > > #lang racket > > (module+ test (require rackunit)) > > ; Normalizes sneetches depending on belly-star demand. > (define/contract (convert-sneetches stars-upon-thars? sneetches) > (->i > ([demand boolean?] > [inputs (demand) (non-empty-listof (not demand))]) > [_ (demand inputs) > (and/c > (non-empty-listof demand) > (compose (curry = (length inputs)) length))]) > (map (lambda (s) stars-upon-thars?) sneetches)) > > (module+ test > (check-equal? (convert-sneetches #true (list #false)) (list #true)) > (check-equal? (convert-sneetches #false (list #t #t)) (list #f #f))) > > Also, using `_` instead of `result` means that "the range contract > expressions are evaluated when the function is called instead of when it > returns." My recollection is that this can be desirable for performance > reasons. > > -Philip > > On Mon, Jul 30, 2018 at 4:30 AM, Matthias Felleisen < > matth...@felleisen.org> wrote: > >> >> Here is a version that is slightly more concise than yours (due to the >> use of `curry`) and expresses a stronger property. As our introduction to >> contract illustrates (used to illustrate?) contracts can express a spectrum >> of properties, all the way from type-like ones to full-fledged correctness. >> Developers need to acquire a sense of taste to pic the right level of >> defensiveness. In the end, contracts are really about factoring out the >> defensive part of modules from the functionality ones and you need to know >> how defensive you must be in your context. — Matthias >> >> >> >> #lang racket >> >> (module+ test (require rackunit)) >> >> ; Normalizes sneetches depending on belly-star demand. >> (define/contract (convert-sneetches stars-upon-thars? sneetches) >> (->i >> ([demand boolean?] >> [inputs (demand) (non-empty-listof (and/c boolean? (curry boolean=? >> (not demand))))]) >> (result (demand inputs) >> (and/c >> (non-empty-listof (and/c boolean? (curry boolean=? demand))) >> (compose (curry = (length inputs)) length)))) >> (map (lambda (s) stars-upon-thars?) sneetches)) >> >> (module+ test >> (check-equal? (convert-sneetches #true (list #false)) (list #true)) >> (check-equal? (convert-sneetches #false (list #t #t)) (list #f #f))) >> >> >> On Jul 29, 2018, at 7:45 PM, Sage Gerard <zyrolast...@gmail.com> wrote: >> >> Continuing study of contracts, specifically ->i. >> >> I am trying to model the machine from *The Sneetches* with the most >> fleshed out contract possible. Assuming a Sneetch is reduced to a boolean >> as per the story's problem statement, we can model McBean's machine as: >> >> (define (convert-sneetches stars-upon-thars? sneetches) >> (map (lambda (s) stars-upon-thars?) sneetches)) >> >> The demand for stars upon thars or the contrary is a separate parameter >> to make the problem applicable to ->i, because in the story the machine >> is only configured to accept Sneetches of the opposite persuasion. That is, >> if the demand is for stars upon thars, only Plain-Bellies enter the >> machine. So applications like (convert-sneetches #t '(#t #t #f)) are >> violations. >> >> Here's my attempt at handling this: >> >> #lang racket >> >> ; Normalizes sneetches depending on belly-star demand. >> (define/contract (convert-sneetches stars-upon-thars? sneetches) >> (->i >> ([demand boolean?] >> [inputs (demand) >> (non-empty-listof >> (and/c >> boolean? >> (lambda (b) (equal? b (not demand)))))]) >> (result (demand inputs) >> (non-empty-listof >> (and/c boolean? (lambda (b) (equal? b demand)))))) >> (map (lambda (s) stars-upon-thars?) sneetches)) >> >> It *appears* to work, but is this correct? I'm not 100% on the binding >> rules inside a contract body. If this is correct, was there a simpler way >> to do this? >> >> Thanks, >> Sage >> >> >> -- >> 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. >> >> >> -- >> 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. >> > > -- 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.
