On Sun, Sep 6, 2009 at 3:14 PM, Robby Findler<ro...@eecs.northwestern.edu> wrote: > Right. That wouldn't be parametric.
I think it's the contracts-don't-change-programs condition, not the parametricity condition, that would be violated here. -jacob > > Robby > > On Sat, Sep 5, 2009 at 7:58 PM, Matthias Felleisen<matth...@ccs.neu.edu> > wrote: >> >> On Sep 5, 2009, at 6:04 PM, Robby Findler wrote: >> >>> No. As we discussed, there can't be with this meaning of #:exists. If >>> there were, you'd run into the same problem as with number? (for those >>> that don't know what I'm talking about, see the new second gotcha >>> section in the contracts documentation in the guide). >>> >>> But, if you want to protect yourself by shifting blame, you can still >>> do that. You need to use the 'stack' contract in your own code to do >>> so instead of using a predicate test. >> >> So the client can write additional contracts involving stacks, e.g., >> >> [stack-append (-> stack stack stack)] >> >> but it is impossible to write data definitions such as >> >> A collection is one of: >> -- stack >> -- queue >> >> and then use it because you can't distinguish a stack from a queue. (Of >> course, if both stacks and queues support the same operations, you can do >> this.) >> >> -- Matthias >> >> >> >> >>> Robby >>> >>> On Sat, Sep 5, 2009 at 10:02 AM, Matthias Felleisen<matth...@ccs.neu.edu> >>> wrote: >>>> >>>> Is there a stack? predicate afterwards? >>>> >>>> On Sep 4, 2009, at 2:00 PM, Robby Findler wrote: >>>> >>>>> I've added #:exists to provide/contract, as a way to hide information >>>>> ala "type t" declarations on ML signatures. >>>>> >>>>> See the contracts section in the Guide for a worked example and a >>>>> discussion of a gotcha. The short version is that you can now write >>>>> things like this: >>>>> >>>>> (provide/contract >>>>> #:exists stack >>>>> [new stack] >>>>> [push (-> int stack stack)] >>>>> [pop (-> (and/c stack non-empty?) int)] >>>>> [non-empty? (-> stack boolean?)]) >>>>> >>>>> and have the contract system enforce data abstraction, even if your >>>>> stack operations are simply these: >>>>> >>>>> (define new '()) >>>>> (define push cons) >>>>> (define pop car) >>>>> (define non-empty? pair?) >>>>> >>>>> That is, clients of your module will not be able to treat your stacks >>>>> as if they were lists, even though they really are lists. >>>>> >>>>> Robby >>>>> _________________________________________________ >>>>> For list-related administrative tasks: >>>>> http://list.cs.brown.edu/mailman/listinfo/plt-dev >>>> >>>> >> >> > _________________________________________________ > For list-related administrative tasks: > http://list.cs.brown.edu/mailman/listinfo/plt-dev > > _________________________________________________ For list-related administrative tasks: http://list.cs.brown.edu/mailman/listinfo/plt-dev
