<div dir="ltr">Just to be clear, the proposed change would affect only define-judgment-form, since that's the only place where side-condition is not implicitly unquoted.<div><br></div><div>But adding some kind of "debug" annotation that meant "if you get here, print something out" sounds actually quite useful.</div>
<div><br></div><div>Robby</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Sep 4, 2013 at 1:50 PM, Jonathan Schuster <span dir="ltr"><<a href="mailto:schuster@ccs.neu.edu" target="_blank">schuster@ccs.neu.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class="im"><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'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' variant that is not strict in the boolean-ness, or vice-versa)<br>
<br></blockquote><div><br></div></div><div>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.</div><div><br>
</div>
<div><div>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.</div></div><span></span></div></div></div></blockquote></div><div><br>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.<br>
<br>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.<br></div></div></div></div>
</blockquote></div><br></div>