<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra">

<br><div class="gmail_quote"><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
As for backwards compatibility issues, I don&#39;t know how much people rely on side-condition taking something not-#f/#t... Probably too much :)<br>
(also, there could be a `side-condition-soft&#39; variant that is not strict in the boolean-ness, or vice-versa)<br>
<br></blockquote><div><br></div></div><div>Well, if we&#39;re willing to force clients to change their code, then it isn&#39;t hard for them to write their own metafunctions that turn non-#f things into #ts.</div><div><br>


</div>
<div><div>But I think you&#39;re right that just changing this is a good idea and backwards compatibility be damned. I&#39;ll put it on my list.</div></div><span></span></div></div></div></blockquote><div><br>There&#39;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 &quot;(side-condition (displayln (term 
&lt;something&gt;)))&quot;. Forcing booleans there would make that line even 
more verbose, and when it&#39;s being written a lot, that pain adds up.<br>
<br>I&#39;d be in favor of something like side-condition-soft as described 
above. Or alternatively, it might make sense to have a &quot;debug&quot; clause 
that acts like printf, or even a &quot;racket-expression&quot; clause that 
evaluates the given racket expression, but does not affect the result of
 a metafunction the way side-condition does.<br></div></div></div></div>