@samth @mflatt i know it might sound like too much work but I would like to start porting parts of my work to racket-cs so it’s future proof. I wonder if we could have a dev-cs where breaking changes to cs are done and each time dev-cs builds, then it’s merged into master. Just a thought.

@greg After looking over the documentation and trying a few different things, it seems to me that multi-in prefers to work with files. I’ll make a feature request and maybe if I’ve missed something someone can point that out there.

@pocmatos I’m unsure what you’re suggesting. Is the issue that racketcs has too many breaking changes? Or that the build breaks?

That the build breaks. It would be great to have a version of racketcs that builds and we can test the latest version. I can of course have a script to track that on my side if necessary, but if comes from upstream all the better.

@pocmatos the build from source works consistently for me. If the issue is that the snapshot build breaks, then I don’t think that’s something that can easily be avoided except by Matthew continuing to work on it, which he’s doing. In particular, the thing that breaks is making the snapshot itself, so there’s not a way to only build a working version

@samth oh… I had understood that it was the build that was breaking, not the snapshot creation process. OK, that’s easy to solve then. I can build it myself on a regular basis. Thanks.

When we build custom contract combinators, we use blame-add-context to report potential violations in terms of a specific part of the contract. That “context” tracking doesn’t seem to be precisely the same thing as tracking the positive and negative parties. For example, (list/c string? number?) doesn’t deal with parties, but does use context. The papers I’ve read about contracts and blame (far from comprehensively) seem to mostly talk about getting the positive and negative parties right. Are there papers that talk about the sort of “context” I have in mind? Am I right to think of this as part of blame? (I ask because I think this ability to drill down into deeply nested structures is the part of the contract system we’ve found most useful for Digital Ricoeur.)

I think this isn’t discussed in any paper I know of