assert1 and assert2 not in lir-header.rkt

[Sarah Hong]

Hi,

The LIR spec says that there should be assert1 and assert2 returned, but the lir-header.rkt does not have any definitions for these so the desugared code cannot be run with Racket.  Is there something I'm missing here?

Thanks,

Sarah

[Petey A]

It might be easiest to just implement them yourself. They should both be pretty straightforward.

- Petey

--
You received this message because you are subscribed to the Google Groups "Utah Compilers, Spring 2013" group.
To unsubscribe from this group and stop receiving emails from it, send an email to utah-compilers-spri...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Matt Might]

Just an oversight on my part:

You can use these definitions and add them to lir-header.rkt:

(define (assert1 thunk)
(if (thunk)
(error "Assertion failure!")))

(define (assert2 thunk1 thunk2)
(if (thunk1)
(error "Assertion failure!")))

Thanks for catching that!

On Tue, Apr 9, 2013 at 1:58 PM, Sarah Hong <rolling...@gmail.com> wrote:

[Colton Myers]

Am I crazy or should these lines be more like:

(define (assert1 thunk)

  (if (thunk)

    (void)

    (error "Assertion failure!")))

(define (assert2 thunk1 thunk2)

  (if (thunk1)

    (if (thunk2)

      (void)

      (error "Assertion failure!"))

    (error "Assertion failure!")))

Racket complains about no `else` clauses otherwise.  Plus, if `thunk` is true we *shouldn't* throw an error, right?

Of course, I've misread a lot of code today, so I might be missing the point entirely.

[Matt Might]

Right -- I should run the code before I post it. ;)

(define (assert1 thunk)
(when (thunk)

(error "Assertion failure!")))

(define (assert2 thunk1 thunk2)

(when (thunk1)
(error "Assertion failure!")))

You don't need to call thunk2 because it's the argument to the
AssertError. But, we don't handle that.

-Matt

[Colton Myers]

Shouldn't it be (not (thunk)), though?  This code throws an error if (thunk) is true, right?

--

Colton Myers

[Matt Might]

Gah! Of course.

Low blood sugar today...

[cam]

For this test using reference impl pycps_rkt.zo:

var = 1
assert var != 0, 'zero'
assert var >= 0

I get this error:

arity mismatch;
 the expected number of arguments does not match the given number
  expected: 1
  given: 0

when using these suggested asserts in {lir,cps}-header.rkt:

(define (assert1 thunk) 
  (when (not (thunk)) 
    

(error "Assertion failure!"))) 

(define (assert2 thunk1 thunk2)

 
  (when (not (thunk1)) 
    (error "Assertion failure!")))

[Sarah Hong]

I also get this error except I wanted to generate some expected output using Matt's pycps, etc. Is the assert function supposed to be different in the cps-header.rkt than it is in the lir-header.rkt?

On Tuesday, April 9, 2013 1:58:48 PM UTC-6, Sarah Hong wrote:

[Matt Might]

The definitions I supplied should should work as is, since assert1 and
assert2 get wrapped:

For instance:

(program (assert1 1))

=>

(program ((cps assert1) 1 $halt))

The (cps ...) wrapper converts any function to expect a continuation
for its last argument.

-Matt

[cam]

There is a missing parameter somewhere because the params to assert are wrapped in lambdas that end up taking continuations as params. 

Perhaps the missing param is when the thunk is applied inside the assert procedure at:

(when (not (thunk <missing-param?>))

reference cps output shows a required param, the continuation: 

((cps assert2) (lambda (k1) ((cps equal?) g$var 0 k1))  (lambda (k2) (k2 "not zero"))   $halt)