[plt-scheme] Higher-order contracts for variable-arity functions

From: Robby Findler (robby at cs.uchicago.edu)
Date: Thu May 25 15:41:18 EDT 2006

At Thu, 25 May 2006 12:35:27 -0700 (PDT), Ryan Culpepper wrote:
> --- Carl Eastlund <carl.eastlund at gmail.com> wrote:
> 
> > On 5/25/06, Robby Findler <robby at cs.uchicago.edu> wrote:
> > > listof cannot accept higher-order contracts, due to the presence
> > of
> > > mutation. The tricky case is that someone hands you the list and,
> > at
> > > that point, the contract is check and the functions inside the
> > list are
> > > wrapped. Now, imagine that someone mutates the list -- what
> > happens?
> > > How do the contracts get onto the new functions in the list? (We
> > could
> > > change mutation operator, but we haven't taken that step ... yet)
> > >
> > > Note that if you could use immutable lists, that would work fine.
> > >
> > > Maybe time to petition any nearby R6RS committee members? ;)
> > 
> > My point is that I don't care about the list.  I care about the
> > function arguments.  I want to apply a function contract to each
> > argument to my function.  If they get taken out of the list, or
> > other
> > values get put into the list, I don't care, because the list itself
> > was only a convenient delivery mechanism for my many arguments.

It is unsound in general to do that and in this specific case, the
contract system can't tell that the list won't be mutated (if you
follow the N negatives there) and so is being conservative.

> You can apply a contract to the rest args of a function using the ->*
> contract constructor.
> 
> For the rest args, since you presumably don't plan to mutate the
> list, how about using list-immutableof to construct the contract for
> it? 

> Does list-immutableof applied to a mutable list return an
> immutable copy?

It does not. That would be unsound (since removing the contract
checking from a program that doesn't signal a contract violation might
cause the program's result to change).

Robby



Posted on the users mailing list.