On 1/13/07, Eli Barzilay <eli at barzilay.org> wrote:
> On Jan 13, Robby Findler wrote:
> > Note that replacing cons in that manner is also less than optimal,
> > since it means that every cons has to have that contract.
>> I'm not sure I'm following you. Are you saying that every cons cell
> (whether generated by the `cons' function or not) must be following
> the same contract? If this is correct, then this is what I meant when
> I said that it uses the fact that this
>> (define (list? x)
> (or (null? x) (pair? x)))
>> is a valid definition of `list?' (uses the same global cons
> restriction).
>>> > It is possible to do better (but you have to take over the
> > define-struct that generated cons).
>> Are you suggesting a bit that tells you whether this cons is a proper
> list or not? If so, wouldn't that bit be the same as adding a second
> kind of cons?
Not exactly. If you take over the define-struct you can make the
selectors recognize all the different cons's and still have different
contracts on them all. That's the gist of the idea.
Check out define-contract-struct in the contract library. That's what
I'm talking about. It a way to get the contract on list-based cons in
some contexts but other contracts in other contexts.
Robby