> > > As for backwards compatibility issues, I don't know how much people rely >> on side-condition taking something not-#f/#t... Probably too much :) >> (also, there could be a `side-condition-soft' variant that is not strict >> in the boolean-ness, or vice-versa) >> >> > Well, if we're willing to force clients to change their code, then it > isn't hard for them to write their own metafunctions that turn non-#f > things into #ts. > > But I think you're right that just changing this is a good idea and > backwards compatibility be damned. I'll put it on my list. >
There's at least one situation in which non-booleans in side conditions are important: debugging. Much of my Redex debugging involves adding code along the lines of "(side-condition (displayln (term <something>)))". Forcing booleans there would make that line even more verbose, and when it's being written a lot, that pain adds up. I'd be in favor of something like side-condition-soft as described above. Or alternatively, it might make sense to have a "debug" clause that acts like printf, or even a "racket-expression" clause that evaluates the given racket expression, but does not affect the result of a metafunction the way side-condition does.
____________________ Racket Users list: http://lists.racket-lang.org/users
