Dropping equal? expressions?

[jpolitz]

Somehow it looks like one of hte two equal expressions at the end of this file are being dropped by lexical desugaring:

$ cat ../examples/scope/nonlocal-function-vardef-shadow.py 
def f():
    x = 0
    def inc():
        nonlocal x
        x += 1
        return x
    def dec(x):
        x -= 1
        return x
    return inc, dec

inc, dec = f()
___assertEqual(inc(), 1)
___assertEqual(inc(), 2)
___assertEqual(dec(1), 0)
___assertEqual(dec(1), 0)

$ ./show-scope.sh < ../examples/scope/nonlocal-function-vardef-shadow.py 
# assigned to (global) f
def f(    ):
  {
    defvar (local)  x = UNDEF in {
      defvar (local)  inc = UNDEF in {
        defvar (local)  dec = UNDEF in {
          (local) x = 0
          # assigned to (local) inc
          def inc(    ):
            {
              nonlocal x
              (local) x+=1
              return (local) x
            }
          # assigned to (local) dec
          def dec((local) x    ):
            {
              nonlocal x
              (local) x-=1
              return (local) x
            }
          return [(local) inc, (local) dec]
        }
      }
    }
  }
[(global) inc, (global) dec] = (global) f()
(global) ___assertEqual((global) inc(), 1)
(global) ___assertEqual((global) inc(), 2)
(global) ___assertEqual((global) dec(1), 0)

My guess is that an equal? comparison is causing the problem.

[mpmilano]

I'll take a look tomorrow morning.

~matthew

On Wed, Nov 13, 2013 at 5:26 PM, Joe Politz notifications@github.comwrote:

Somehow it looks like one of hte two equal expressions at the end of this file are being dropped by lexical desugaring:

$ cat ../examples/scope/nonlocal-function-vardef-shadow.py def f(): x = 0 def inc(): nonlocal x x += 1 return x def dec(x): x -= 1 return x return inc, dec

inc, dec = f() assertEqual(inc(), 1) assertEqual(inc(), 2) assertEqual(dec(1), 0) assertEqual(dec(1), 0)

$ ./show-scope.sh < ../examples/scope/nonlocal-function-vardef-shadow.py

assigned to (global) f

def f( ): { defvar (local) x = UNDEF in { defvar (local) inc = UNDEF in { defvar (local) dec = UNDEF in { (local) x = 0

assigned to (local) inc

      def inc(    ):
        {
          nonlocal x
          (local) x+=1
          return (local) x
        }
      # assigned to (local) dec
      def dec((local) x    ):
        {
          nonlocal x
          (local) x-=1
          return (local) x
        }
      return [(local) inc, (local) dec]
    }
  }
}

} [(global) inc, (global) dec] = (global) f() (global) assertEqual((global) inc(), 1) (global) assertEqual((global) inc(), 2) (global) ___assertEqual((global) dec(1), 0)

My guess is that an equal? comparison is causing the problem.

— Reply to this email directly or view it on GitHubhttps://github.com/brownplt/lambda-py/issues/66 .

[mpmilano]

Well that took way too long to track down. It's actually not the fault of any of the racket code, it's an over-aggressive filter in the shell script. If you bypass the shell script and run python-main with the --get-phase1-syntax you'll see that it appears as it should. Unfortunately that output also contains way too many newlines, which is what the shell script was trying to eliminate in the first place. I'll tighten up the filter to actually target just the newlines.

[jpolitz]

I probably led you astray with my armchair speculation about the source of the problem. I should just report bugs, not suggest fixes to the person that knows and owns that code.

On Thu, Nov 14, 2013 at 4:13 PM, Matthew Milano notifications@github.comwrote:

Well that took way too long to track down. It's actually not the fault of any of the racket code, it's an over-aggressive filter in the shell script. If you bypass the shell script and run python-main with the --get-phase1-syntax you'll see that it appears as it should. Unfortunately that output also contains way too many newlines, which is what the shell script was trying to eliminate in the first place. I'll tighten up the filter to actually target just the newlines.

— Reply to this email directly or view it on GitHubhttps://github.com/brownplt/lambda-py/issues/66#issuecomment-28523331 .

[mpmilano]

Eh, I'd probably have started by looking there anyway. It's been a while since I've actually paid attention to the internals of that shell script. I think the important takeaway from this is that this isn't a bug in our interpreter and is orthogonal to its correctness.

[mpmilano]

fixed with 3351f2a245c529a9ef818f02ea81ab9360b82fc0