[racket] [redex] side-condition matching upon errors

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 <schuster at 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20130904/f4ebd4aa/attachment.html>