Stepping back a little, a chaperone constructor for a datatype often needs some inside information and cooperation from the dataype implementation. For example, `chaperone-hash` has the property that you want --- the filter applied to a `hash-ref` result doesn't get used if a failure thunk produces the `hash-ref` result --- and that works because `hash-ref` and `chaperone-hash` are implemented together.
I'm guessing that you don't have access to a dictionary implementation because new kinds of dictionaries can be created by implementing `gen:dict`. Maybe `dict/c` based on chaperones can only work for dictionaries that supply additional implementation hooks by also implementing `gen:dict-chaperone` (or something like that). At Thu, 21 May 2020 11:56:15 -0400, Alex Knauth wrote: > Hello, > > I'm working on a version of `dict/c` with chaperones, but I'm running into a > surprising problem that only comes up because of the `failure-result` > optional-argument to `dict-ref`. > > When the `failure-result` is used, I don't want the "value" contract to apply > to that result. But when the failure-result isn't used, and the "value" > result > happens to be exactly equal to the failure-result, I do want the "value" > contract to apply to it. How do I distinguish those though? > > I tried to take inspiration from Carl Eastlund's `dict/c` implemented in > `mischief/contract`, but it doesn't use chaperones so it is free to both add > an escape continuation, and change the `failure-result` input to always be a > new synthesized procedure. That way the new synthesized failure-result > procedure can call the escape continuation. If I'm constrained to chaperones, > I don't know how to do either of those things. > > How can I detect whether the `failure-result` is used-or-not by the dict's > implementation of `dict-ref`, while keeping the `failure-result` a chaperone > of the original failure-result? > > Alex Knauth > > -- > You received this message because you are subscribed to the Google Groups > "Racket Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to racket-users+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/racket-users/9612FD20-8FFB-420D-8BAD-8FF0F837 > 7AEC%40knauth.org. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/20200521112145.2a%40sirmail.smtp.cs.utah.edu.
