+1 for the debug annotation! it would be really helpful! -- Éric
On Sep 4, 2013, at 3:04 PM, Robby Findler <ro...@eecs.northwestern.edu> wrote: > 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. > > But adding some kind of "debug" annotation that meant "if you get here, print > something out" sounds actually quite useful. > > Robby > > > On Wed, Sep 4, 2013 at 1:50 PM, Jonathan Schuster <schus...@ccs.neu.edu> > wrote: > > 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
