Allow structs to be mutable

[dbp]

I thought this was just a matter of adding #:mutable, but this is causing a test failure (good!), so obviously there is something going on. I get why this could cause problems (mutability certainly changes how equality can work!), but not sure how to fix it :)

[camoy]

There's any easy fix for this (which I've pushed). But there's a bigger question about the meaning of struct contracts when they're mutable. At the moment I've assumed structs are immutable and are flat. However, once they're mutable then they become higher-order and need to be impersonated/chaperoned like procedures are to enforce the contract when a client calls set-struct-field!.

[dbp]

Well, I guess the answer to that relates to the answer to how we are going to deal with mutation (Week 9 on the schedule, currently). I was thinking we would do that with structs, but we could just provide (mutable) vectors (and say structs are immutable)... Though we'd need vector contracts, which would need the same thing, so...

(separately, I think we really need at least set! to get interesting temporal stuff... pure functions are atemporal, so the only aspect we can talk about is how the client uses them, which feels artificial. I've been trying to use random as a stand-in, but there's only so much we can do with that...)

[camoy]

Turns out that the traditional implementation strategy of using impersonators for structs doesn't work because of Rosette. Instead I'm simulating the same kind of behavior with a special kind of proxy struct that respects equality and contains contracts for fields. Somewhat messy, but should work.