Re: [racket-users] Contract on a parameter’s value as a function precondition?

It turns out that the continuation mark keys and procedures for parameters aren’t really hidden away, so it ended up being pretty straight forward. Below is a minimal implementation of parameterization->. I’m happy to help integrate this into the racket/contract family once we figure out what’s the nicest interface.

#lang racket

(require '#%paramz)

(define (parameterization-> param-name param val/c)
  (make-chaperone-contract
   #:name
   `(parameterization-> ,param-name 
                        ,(contract-name val/c))
   #:first-order
   procedure?
   #:late-neg-projection
   (λ (blame)
     (λ (value party)
       (let* ([positive (blame-replace-negative blame party)]
              [negative (blame-swap positive)])
         (unless (procedure? value)
           (raise-blame-error positive value
                              '(expected: "procedure?" given: "~e")
                              value))
         (chaperone-procedure
          value
          (λ args
            (let ([new-parameterization (extend-parameterization
                                         (continuation-mark-set-first #f parameterization-key)
                                         param
                                         (((contract-projection val/c) negative) (param)))])
              (apply values 'mark parameterization-key new-parameterization args)))))))))

(require rackunit)

(define p (make-parameter #f))

(define/contract (foo)
  (parameterization-> 'p p integer?)
  (p))

(define/contract (bar)
  (parameterization-> 'p p (-> integer? integer?))
  ((p) 4))

(define/contract (baz)
  (parameterization-> 'p p (-> symbol? symbol?))
  ((p) 4))

(check-exn
 exn:fail:contract?
 (thunk (foo)))

(check-not-exn
 (thunk
  (parameterize ([p 2])
    (foo))))

(check-not-exn
 (thunk
  (parameterize ([p (λ (x) x)])
    (bar))))

(check-exn
 exn:fail:contract?
 (thunk
  (parameterize ([p (λ (x) x)])
    (baz))))
On November 28, 2016 at 11:24:29 AM, Alexis King ([email protected]) wrote:

That sounds promising, yes. Not being familiar with the guts of  
parameters, is there any way to implement this as a derived concept  
using the existing support in chaperone-procedure? As far as I can  
tell, parameters do not expose the continuation marks they use, and  
they also create thread cells, which I’m not sure that  
chaperone-procedure’s existing API would support. Would this require  
modification of procedure chaperones to support parameters directly,  
or is there some way to implement it separately?  

> On Nov 23, 2016, at 10:51 AM, Scott Moore <[email protected]> wrote:  
>  
> Yes, we worked with Matthew to implement the necessary hooks in procedure chaperones (see the 'mark options that were added to the return value of wrapper-proc). For the contracts we were writing, we ended up using these continuation marks directly.  
>  
> To implement what you're looking for, a little extra work is required to link up the implementation of parameters with this mechanism to get at the appropriate continuation marks. One question there will be whether to integrate it with either the existing  
> arrow contracts (carefully protecting access to the internals of the parameter implementation), or to just provide a standalone combinator. I would need to refresh my memory to see what exactly would need to be done for either.  
>  
> Cheers,  
> Scott  

-- 
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+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/[email protected]
For more options, visit https://groups.google.com/d/optout.