[plt-scheme] check-expect not allowed in expression position?

From: Jay McCarthy (jay.mccarthy at gmail.com)
Date: Wed Mar 31 09:15:22 EDT 2010

On Tue, Mar 30, 2010 at 11:41 PM, Danny Yoo <dyoo at cs.wpi.edu> wrote:
> I was trying to use test-engine's check-expect to write a test case,
> and I found myself wanting to use it in an expression position.  I
> came across the error:
>
>    check-expect: found a test that is not at the top level
>
> I understand that, as a mechanism, all the test cases are
> syntactically re-adjusted so that they're valid even if they're
> referring to definitions defined after the tests.  However, I thought
> I might try to work around the limitation with the following macro.
> The idea of my macro is to rearrange things enough to make
> check-expect happy, but it doesn't work:
>
> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
> (define-syntax (check-expect* stx)
>  (syntax-case stx ()
>    [(_ observed expected)
>     (with-syntax ([observed-thunk
>                    (syntax-local-lift-expression #'#f)]
>                   [expected-thunk
>                    (syntax-local-lift-expression #'#f)])
>       (begin
>         (syntax-local-lift-module-end-declaration
>          (syntax/loc stx
>            (check-expect (observed-thunk) (expected-thunk))))
>         (syntax/loc stx
>           (begin
>             (set! observed-thunk (lambda () observed))
>             (set! expected-thunk (lambda () expected))
>             (void)))))]))
> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
>
>
> After seeing the error, I now understand that I misused
> syntax-local-lift-module-end-declaration, which says that, in the way
> I'm using it, eventually the thing being lifted will be expanded in
> expression context.  Of course, this isn't what I want: I want to lift
> a syntax up to the module or top-level context.  I can't find the
> right primitive that does this.  Am I missing something obvious?

At a more meta level, you're never gonna get this because it has nasty
paradox problems for definitions. I've slowly come to accept this by
thinking about why I shouldn't be able to lift the top level
definitions I want to, etc.

---- Ignored what is after this, but I left it here to document my
stupidity ----

You do have to watch out for one thing with
syntax-local-lift-expresson: Lifts are defined in the opposite order
they are lifted:

If (macro) lifts A and B

"(macro)"

becomes

"(define lifted.1 B) (define lifted.0 A) (macro-expansion)"

That means that the return of syntax-local-lift-expression (the lifted
identifier) can't be used in subsequent lifts that rely on the value
of earlier lifts at definition time.......

I went to go write a broken example and found out I was wrong. Maybe
this was changed some time recently? Who knows.

Jay


> _________________________________________________
>  For list-related administrative tasks:
>  http://list.cs.brown.edu/mailman/listinfo/plt-scheme
>



-- 
Jay McCarthy <jay at cs.byu.edu>
Assistant Professor / Brigham Young University
http://teammccarthy.org/jay

"The glory of God is Intelligence" - D&C 93


Posted on the users mailing list.