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
Does this do what you need?
(define/contract (foo bar)
(-> (or/c 1 #t "bar" (listof string?) (listof (or/c 'a 'b))) boolean?)
#t)
(foo 1)
(foo #t)
(foo "bar")
(foo '("should work"))
(foo '(a))
(foo '(b))
(foo '(b a b a a a))
(foo "should fail")
Output:
#t
#t
#t
#t
#t
#t
#t
foo: contract
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,
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
I think that Scott investigated adding support to chaperones that
would make something like this work.
Robby
On Tue, Nov 22, 2016 at 10:16 PM, Alexis King wrote:
> I have a function that requires a parameter be set to a value satisfying
> a particular contract, but I
I have a function that requires a parameter be set to a value satisfying
a particular contract, but I don’t see any direct way to specify that
constraint using the contract system. It seems possible to emulate using
#:pre from ->* and ->i, but this has two problems: it doesn’t produce
very good
6 matches
Mail list logo