Variable capture in stepper's substitution

samth / test-bugs

2 stars 0 forks source link

Variable capture in stepper's substitution #73

Open racket-bug-submit opened 12 years ago

racket-bug-submit commented 12 years ago

Originally submitted on: Wed Oct 31 14:20:02 -0400 2007

When substituting a lambda term M into the body of another lambda term N, the stepper doesn't alpha-rename to avoid capturing free variables in M.

This bug was converted from Gnats bug 9030.

racket-bug-submit commented 12 years ago

On Wed, 31 Oct 2007 14:27:27 -0400, matthias@ccs.neu.edu wrote:

It's just the illusion of capturing, it isn't real as this program
demonstrates:

(define x 42)

(define f
  (lambda (g)
    (lambda (x)
      (g 21))))

((f (lambda (y) x)) 0)

Of course, now it looks like the Stepper doesn't know what it is doing.

On Oct 31, 2007, at 2:20 PM, clklein@cs.uchicago.edu wrote:

A new problem report is waiting at http://bugs.plt-scheme.org/query/?cmd=view&pr=9030

Reported by Casey Klein for release: 371.3-svn31oct2007

*\ Description: When substituting a lambda term M into the body of another lambda
term N, the stepper doesn't alpha-rename to avoid capturing free
variables in M.

*\ How to repeat: Stepping the program

(define x 42)

(define f (lambda (g) (lambda (x) (g x))))

((f (lambda (y) x)) 0)

reaches the term

(((lambda (g) (lambda (x) (g x))) (lambda (y) x)) 0)

which the stepper reduces to

((lambda (x) ((lambda (y) x) x)) 0)

capturing the free occurence of x.

*\ Environment: unix "Linux radius.cs.uchicago.edu 2.6.18-5-686-bigmem #1 SMP Sun
Aug 12 23:05:22 UTC 2007 i686 GNU/Linux" (i386-linux/3m) (get- display-depth) = 16 Docs Installed: (("/var/tmp/plt/share/plt/doc" "r5rs" "mzscheme" "mred" "help"
"tour" "drscheme" "srfi" "mzlib" "misclib" "mrlib" "framework"
"foreign" "mzc" "tools" "insidemz" "web-server" "swindle" "plot"
"gui" "guide" "quick" "reference" "release-notes" "scribble" "t-y- scheme" "tex2page" "beginning" "beginning-abbr" "intermediate"
"intermediate-lambda" "advanced" "teachpack" "teachpack-htdc"
"profj-beginner" "profj-intermediate" "profj-intermediate-access"
"profj-advanced")) Human Language: english (current-memory-use) 95969284

Collections: (("/home/clklein/.plt-scheme/371.3/collects" non-existent-path) ("/ var/tmp/plt/lib/plt/collects" "afm" "big" "ffi" "net" "sgl" "xml"
"eopl" "help" "htdp" "html" "lang" "lazy" "make" "r5rs" "mred"
"plot" "srfi" "wxme" "framework" "teachpack" "handin-client"
"mzscheme" "games" "icons" "htdch" "mrlib" "mzcom" "mzlib"
"graphics" "profj" "setup" "tests" "trace" "xelda" "combinator- parser" "waterworld" "preprocessor" "sirmail" "test-box-recovery"
"skipper" "handin-server" "tex2page" "texpict" "scribblings"
"profjWizard" "stepper" "scribble" "web-server" "config" "compiler"
"swindle" "dynext" "hierlist" "macro-debugger" "frtime" "defaults"
"guibuilder" "drscheme" "syntax-color" "mrflow" "srpersist"
"mztake" "planet" "mysterx" "errortrace" "slatex" "syntax"
"version" "algol60" "honu-module" "parser-tools" "openssl"
"embedded-gui" "slideshow" "repos-time-stamp" "info-domain"
"readline" "launcher" "string-constants" "browser")) Computer Language: (("Teaching Languages" "How to Design Programs"
"Intermediate Student with lambda") (#6(#t quasiquote repeating- decimal #f #t none) #f ()))

racket-bug-submit commented 12 years ago

On Wed, 31 Oct 2007 13:37:23 -0500, robby@cs.uchicago.edu wrote:

Yes, just the illusion. Yes, the stepper looks bad. :)

Robby

On 10/31/07, Matthias Felleisen matthias@ccs.neu.edu wrote:

It's just the illusion of capturing, it isn't real as this program demonstrates:

(define x 42)
(define f
  (lambda (g)
    (lambda (x)
      (g 21))))

((f (lambda (y) x)) 0)
Of course, now it looks like the Stepper doesn't know what it is doing.

On Oct 31, 2007, at 2:20 PM, clklein@cs.uchicago.edu wrote:

A new problem report is waiting at http://bugs.plt-scheme.org/query/?cmd=view&pr=9030

Reported by Casey Klein for release: 371.3-svn31oct2007

*\ Description: When substituting a lambda term M into the body of another lambda term N, the stepper doesn't alpha-rename to avoid capturing free variables in M.

*\ How to repeat: Stepping the program

(define x 42)

(define f (lambda (g) (lambda (x) (g x))))

((f (lambda (y) x)) 0)

reaches the term

(((lambda (g) (lambda (x) (g x))) (lambda (y) x)) 0)

which the stepper reduces to

((lambda (x) ((lambda (y) x) x)) 0)

capturing the free occurence of x.

*\ Environment: unix "Linux radius.cs.uchicago.edu 2.6.18-5-686-bigmem #1 SMP Sun Aug 12 23:05:22 UTC 2007 i686 GNU/Linux" (i386-linux/3m) (get- display-depth) = 16 Docs Installed: (("/var/tmp/plt/share/plt/doc" "r5rs" "mzscheme" "mred" "help" "tour" "drscheme" "srfi" "mzlib" "misclib" "mrlib" "framework" "foreign" "mzc" "tools" "insidemz" "web-server" "swindle" "plot" "gui" "guide" "quick" "reference" "release-notes" "scribble" "t-y- scheme" "tex2page" "beginning" "beginning-abbr" "intermediate" "intermediate-lambda" "advanced" "teachpack" "teachpack-htdc" "profj-beginner" "profj-intermediate" "profj-intermediate-access" "profj-advanced")) Human Language: english (current-memory-use) 95969284

Collections: (("/home/clklein/.plt-scheme/371.3/collects" non-existent-path) ("/ var/tmp/plt/lib/plt/collects" "afm" "big" "ffi" "net" "sgl" "xml" "eopl" "help" "htdp" "html" "lang" "lazy" "make" "r5rs" "mred" "plot" "srfi" "wxme" "framework" "teachpack" "handin-client" "mzscheme" "games" "icons" "htdch" "mrlib" "mzcom" "mzlib" "graphics" "profj" "setup" "tests" "trace" "xelda" "combinator- parser" "waterworld" "preprocessor" "sirmail" "test-box-recovery" "skipper" "handin-server" "tex2page" "texpict" "scribblings" "profjWizard" "stepper" "scribble" "web-server" "config" "compiler" "swindle" "dynext" "hierlist" "macro-debugger" "frtime" "defaults" "guibuilder" "drscheme" "syntax-color" "mrflow" "srpersist" "mztake" "planet" "mysterx" "errortrace" "slatex" "syntax" "version" "algol60" "honu-module" "parser-tools" "openssl" "embedded-gui" "slideshow" "repos-time-stamp" "info-domain" "readline" "launcher" "string-constants" "browser")) Computer Language: (("Teaching Languages" "How to Design Programs" "Intermediate Student with lambda") (#6(#t quasiquote repeating- decimal #f #t none) #f ()))

racket-bug-submit commented 12 years ago

On Wed, 31 Oct 2007 12:59:48 -0700, clements@brinckerhoff.org wrote:

--Apple-Mail-7-805226706 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed

On Oct 31, 2007, at 11:20 AM, clklein@cs.uchicago.edu wrote:

A new problem report is waiting at http://bugs.plt-scheme.org/query/?cmd=view&pr=9030

Reported by Casey Klein for release: 371.3-svn31oct2007

*\ Description: When substituting a lambda term M into the body of another lambda
term N, the stepper doesn't alpha-rename to avoid capturing free
variables in M.

Yep.

Okay if I file this as a change-request?

John

--Apple-Mail-7-805226706 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIF4jCCApsw ggIEoAMCAQICECrxHj7xTe6SpIhCjvYe48cwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDQxMjIzMjQzNFoXDTA4MDQxMTIzMjQz NFowfjERMA8GA1UEBBMIQ2xlbWVudHMxGjAYBgNVBCoTEUpvaG4gQnJpbmNrZXJob2ZmMSMwIQYD VQQDExpKb2huIEJyaW5ja2VyaG9mZiBDbGVtZW50czEoMCYGCSqGSIb3DQEJARYZY2xlbWVudHNA YnJpbmNrZXJob2ZmLm9yZzCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAs/Lht6S+RcCb6gyF MAddibx+w9YI6Cn06p1cY8w+vxOHfL6bZTsMuHmPcdWvu0OY2JLOvPYRPZEVMSs33bg9mG9XsIqF smEk3iSuCNQwJVdCBHfYC2LHYFDLfe6l9lWoQe3oUqsA+fPTpWAuKSkophu1sEyZ+wkhDKFI9JCo zC0CAwEAAaM2MDQwJAYDVR0RBB0wG4EZY2xlbWVudHNAYnJpbmNrZXJob2ZmLm9yZzAMBgNVHRMB Af8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAHafJPfjtPhrdMY9bSP+mO/zHHDkEr1thzvH7zuGZ3rB DWBfScBVrv7BSxN/rQjJ2HaLIe0ANkWIQxdAMaW4qmAdFRwFyO3hnQkiCYBoLrXZ1S6hvqX5+Nfa D9HiDDd5Wf1HA4UJJYokTXSWPX2Z0pPEVaK9oqsgRrojkdZgxuZVMIIDPzCCAqigAwIBAgIBDTAN BgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAG A1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2Vy dGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZy ZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4X DTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoe aMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwL B+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3 +wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDov L2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEG MCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUF AAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD 2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfj ViF4gtwhGTXeJLHTHUb/XV9lTzGCAo8wggKLAgEBMHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBJc3N1aW5nIENBAhAq8R4+8U3ukqSIQo72HuPHMAkGBSsOAwIaBQCgggFvMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA3MTAzMTE5NTk0OFowIwYJKoZI hvcNAQkEMRYEFDaUM+w4r0v+sCDl2fOfKtTEQNtAMIGFBgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNV BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQKvEePvFN7pKkiEKO9h7jxzCBhwYL KoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQKvEePvFN7pKkiEKO9h7jxzANBgkqhkiG9w0BAQEFAASBgAm6z3u+tDXAavk8MY9qBDlkgsNK BSB7anGzqsDt9uepRAqng8/NIdelVBsm4CRUi01uGfxWIeriht/f6lPyA/bQ/7xqp/RxNuX/YjIv 8HyAEwD5VUhtxxIYKbUtTyfGB7aOnCsuCNV4vTwgBhV4GWs/TxEC8novkUtxo9onsoYJAAAAAAAA

--Apple-Mail-7-805226706--

racket-bug-submit commented 12 years ago

On Wed, 31 Oct 2007 15:45:12 -0500, clklein@cs.uchicago.edu wrote:

On Wed, Oct 31, 2007 at 12:59:48PM -0700, John Clements wrote:

On Oct 31, 2007, at 11:20 AM, clklein@cs.uchicago.edu wrote:

A new problem report is waiting at http://bugs.plt-scheme.org/query/?cmd=view&pr=9030

Reported by Casey Klein for release: 371.3-svn31oct2007

*\ Description: When substituting a lambda term M into the body of another lambda
term N, the stepper doesn't alpha-rename to avoid capturing free
variables in M.

Yep.

Okay if I file this as a change-request?

John

Sure.

racket-bug-submit commented 12 years ago

On Wed, 31 Oct 2007 16:57:21 -0400, clements classified this bug as change-request

change to the way the stepper currently operates

racket-bug-submit commented 12 years ago

On Wed, 31 Oct 2007 16:57:21 -0400, clements assigned this bug to clements

stepper issue

racket-bug-submit commented 12 years ago

On Wed, 31 Oct 2007 16:57:21 -0400, clements wrote:

analyzed

racket-bug-submit commented 12 years ago

On Wed, 31 Oct 2007 16:07:37 -0500, robby@cs.uchicago.edu wrote:

This seems like a bug to me, too.

Robby

On 10/31/07, Matthias Felleisen matthias@ccs.neu.edu wrote:

Eh? It violates the specification! Your paper is not broken because you used closed lambda terms.

On Oct 31, 2007, at 4:57 PM, clements@plt-scheme.org wrote:

Class changed from "sw-bug" to "change-request" by clements at Wed, 31 Oct 2007 16:57:21 -0400 Reason>>> change to the way the stepper currently operates

Responsible changed from "nobody" to "clements" by clements at Wed, 31 Oct 2007 16:57:21 -0400 Reason>>> stepper issue

State changed from "open" to "analyzed" by clements at Wed, 31 Oct 2007 16:57:21 -0400 Reason>>> analyzed

View: http://bugs.plt-scheme.org/query/?cmd=view&pr=9030

racket-bug-submit commented 12 years ago

On Wed, 31 Oct 2007 17:03:48 -0400, matthias@ccs.neu.edu wrote:

Eh? It violates the specification! Your paper is not broken because
you used closed lambda terms.

On Oct 31, 2007, at 4:57 PM, clements@plt-scheme.org wrote:

Class changed from "sw-bug" to "change-request" by clements at Wed,
31 Oct 2007 16:57:21 -0400 Reason>>> change to the way the stepper currently operates

Responsible changed from "nobody" to "clements" by clements at Wed,
31 Oct 2007 16:57:21 -0400 Reason>>> stepper issue

State changed from "open" to "analyzed" by clements at Wed, 31 Oct
2007 16:57:21 -0400 Reason>>> analyzed

View: http://bugs.plt-scheme.org/query/?cmd=view&pr=9030

racket-bug-submit commented 12 years ago

On Wed, 31 Oct 2007 14:25:19 -0700, clements@brinckerhoff.org wrote:

--Apple-Mail-10-810360496 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed

On Oct 31, 2007, at 2:03 PM, Matthias Felleisen wrote:

Eh? It violates the specification! Your paper is not broken because
you used closed lambda terms.

Okay, okay...

The basic problem here is the top-level variables. That is, if the
"x" bound in the (lambda (y) x) term were a non-top-level variable,
it would be shown as (lambda (y) 42), rather than (lambda (y) x).

So, the apparent fix would be to perform renaming on all top-level
variables, not just those bound by a "local". Naturally, this would
only be necessary in languages where lambdas are displayed as inline
lambdas. That is, intermediate-with-lambda and up.

Sound good?

John Clements

--Apple-Mail-10-810360496 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIF4jCCApsw ggIEoAMCAQICECrxHj7xTe6SpIhCjvYe48cwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDQxMjIzMjQzNFoXDTA4MDQxMTIzMjQz NFowfjERMA8GA1UEBBMIQ2xlbWVudHMxGjAYBgNVBCoTEUpvaG4gQnJpbmNrZXJob2ZmMSMwIQYD VQQDExpKb2huIEJyaW5ja2VyaG9mZiBDbGVtZW50czEoMCYGCSqGSIb3DQEJARYZY2xlbWVudHNA YnJpbmNrZXJob2ZmLm9yZzCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAs/Lht6S+RcCb6gyF MAddibx+w9YI6Cn06p1cY8w+vxOHfL6bZTsMuHmPcdWvu0OY2JLOvPYRPZEVMSs33bg9mG9XsIqF smEk3iSuCNQwJVdCBHfYC2LHYFDLfe6l9lWoQe3oUqsA+fPTpWAuKSkophu1sEyZ+wkhDKFI9JCo zC0CAwEAAaM2MDQwJAYDVR0RBB0wG4EZY2xlbWVudHNAYnJpbmNrZXJob2ZmLm9yZzAMBgNVHRMB Af8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAHafJPfjtPhrdMY9bSP+mO/zHHDkEr1thzvH7zuGZ3rB DWBfScBVrv7BSxN/rQjJ2HaLIe0ANkWIQxdAMaW4qmAdFRwFyO3hnQkiCYBoLrXZ1S6hvqX5+Nfa D9HiDDd5Wf1HA4UJJYokTXSWPX2Z0pPEVaK9oqsgRrojkdZgxuZVMIIDPzCCAqigAwIBAgIBDTAN BgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAG A1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2Vy dGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZy ZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4X DTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoe aMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwL B+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3 +wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDov L2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEG MCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUF AAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD 2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfj ViF4gtwhGTXeJLHTHUb/XV9lTzGCAo8wggKLAgEBMHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBJc3N1aW5nIENBAhAq8R4+8U3ukqSIQo72HuPHMAkGBSsOAwIaBQCgggFvMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA3MTAzMTIxMjUyMFowIwYJKoZI hvcNAQkEMRYEFP6XNXoMhTaCTRm1OY+33DTdyMh8MIGFBgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNV BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQKvEePvFN7pKkiEKO9h7jxzCBhwYL KoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQKvEePvFN7pKkiEKO9h7jxzANBgkqhkiG9w0BAQEFAASBgGcBoNQl44ZTk4kethBOr1c9UlzH LOBE+/HUatSZghhWhIUfZ9zFKuMjAa15ORYZ1jax+bEklhbb/OacwEHJPEFIzmIfRATYn73VAfsi gWtBcNNNYTlmUub4oe8zKvAVuoowkg0MH178L9ZWa7kyzeOpO8RK4MAYUtFIHh0cveL3AAAAAAAA

--Apple-Mail-10-810360496--

racket-bug-submit commented 12 years ago

On Wed, 31 Oct 2007 16:33:53 -0500, robby@cs.uchicago.edu wrote:

Usually one renames bound identifiers to work around this (since free identifiers can't be freely renamed).

Robby

On 10/31/07, John Clements clements@brinckerhoff.org wrote:

On Oct 31, 2007, at 2:03 PM, Matthias Felleisen wrote:

Eh? It violates the specification! Your paper is not broken because you used closed lambda terms.

Okay, okay...

The basic problem here is the top-level variables. That is, if the "x" bound in the (lambda (y) x) term were a non-top-level variable, it would be shown as (lambda (y) 42), rather than (lambda (y) x).

So, the apparent fix would be to perform renaming on all top-level variables, not just those bound by a "local". Naturally, this would only be necessary in languages where lambdas are displayed as inline lambdas. That is, intermediate-with-lambda and up.

Sound good?

John Clements

racket-bug-submit commented 12 years ago

On Wed, 31 Oct 2007 17:51:07 -0400, matthias@ccs.neu.edu wrote:

I prefer John's solution. Works like a charm and is intuitive.
Except: how do you scale this to the set! language?

On Oct 31, 2007, at 5:33 PM, Robby Findler wrote:

Usually one renames bound identifiers to work around this (since free identifiers can't be freely renamed).

Robby

On 10/31/07, John Clements clements@brinckerhoff.org wrote:

On Oct 31, 2007, at 2:03 PM, Matthias Felleisen wrote:

Eh? It violates the specification! Your paper is not broken because you used closed lambda terms.

Okay, okay...

The basic problem here is the top-level variables. That is, if the "x" bound in the (lambda (y) x) term were a non-top-level variable, it would be shown as (lambda (y) 42), rather than (lambda (y) x).

So, the apparent fix would be to perform renaming on all top-level variables, not just those bound by a "local". Naturally, this would only be necessary in languages where lambdas are displayed as inline lambdas. That is, intermediate-with-lambda and up.

Sound good?

John Clements

racket-bug-submit commented 12 years ago

On Wed, 31 Oct 2007 16:55:47 -0500, robby@cs.uchicago.edu wrote:

You can rename the set!s too, no?

I actually think that the other is more intuitive, at least once you take a slightly deeper look. (At first glance, no, I agree with that.)

Robby

On 10/31/07, Matthias Felleisen matthias@ccs.neu.edu wrote:

I prefer John's solution. Works like a charm and is intuitive. Except: how do you scale this to the set! language?

On Oct 31, 2007, at 5:33 PM, Robby Findler wrote:

Usually one renames bound identifiers to work around this (since free identifiers can't be freely renamed).

Robby

On 10/31/07, John Clements clements@brinckerhoff.org wrote:

On Oct 31, 2007, at 2:03 PM, Matthias Felleisen wrote:

Eh? It violates the specification! Your paper is not broken because you used closed lambda terms.

Okay, okay...

The basic problem here is the top-level variables. That is, if the "x" bound in the (lambda (y) x) term were a non-top-level variable, it would be shown as (lambda (y) 42), rather than (lambda (y) x).

So, the apparent fix would be to perform renaming on all top-level variables, not just those bound by a "local". Naturally, this would only be necessary in languages where lambdas are displayed as inline lambdas. That is, intermediate-with-lambda and up.

Sound good?

John Clements

racket-bug-submit commented 12 years ago

On Wed, 31 Oct 2007 15:03:09 -0700, jacobm@cs.uchicago.edu wrote:

On Oct 31, 2007 2:51 PM, Matthias Felleisen matthias@ccs.neu.edu wrote:

I prefer John's solution. Works like a charm and is intuitive.

Unless I'm missing something it won't work for toplevel names that are introduced by imports, such as bindings from teachpacks or builtins. Consider

(define (g f) (lambda (cons) (f cons empty)))

(g cons)

This is exactly the free-variable capture problem (treating variables that aren't bound in the source code of the program as free). IMHO it's probably not worthwhile to try for a `simpler' solution than the standard one.

-jacob

On Oct 31, 2007, at 5:33 PM, Robby Findler wrote:

Usually one renames bound identifiers to work around this (since free identifiers can't be freely renamed).

Robby

On 10/31/07, John Clements clements@brinckerhoff.org wrote:

On Oct 31, 2007, at 2:03 PM, Matthias Felleisen wrote:

Eh? It violates the specification! Your paper is not broken because you used closed lambda terms.

Okay, okay...

The basic problem here is the top-level variables. That is, if the "x" bound in the (lambda (y) x) term were a non-top-level variable, it would be shown as (lambda (y) 42), rather than (lambda (y) x).

So, the apparent fix would be to perform renaming on all top-level variables, not just those bound by a "local". Naturally, this would only be necessary in languages where lambdas are displayed as inline lambdas. That is, intermediate-with-lambda and up.

Sound good?

John Clements

racket-bug-submit commented 12 years ago

On Wed, 31 Oct 2007 17:07:59 -0500, robby@cs.uchicago.edu wrote:

I just meant that if you think for a moment, renaming bound variables makes sense. If you don't think much, renaming the globals is fine. If you think harder yet again, you realize that the globals are in fact bound too, but that's 2 levels in, from what I can tell.

Anways, I think Jacob's point trumps all this.

Robby

On 10/31/07, John Clements clements@brinckerhoff.org wrote:

On Oct 31, 2007, at 2:55 PM, Robby Findler wrote:

You can rename the set!s too, no?

I actually think that the other is more intuitive, at least once you take a slightly deeper look. (At first glance, no, I agree with that.)

This last sentence is surely one of the most fascinating last sentences of any e-mail I've ever receieved... :).

I agree with Robby on his first point; I don't see the problem example with set! and renaming of top-level variables. I do see a problem with set! of non-top-level variables, but fortunately none of the teaching languages (incl. Advanced) make this possible (at least, not the last time I checked).

WRT the intuitiveness of the solution: I think that my proposal is more consistent with the treatment of local in intermediate. From a pragmatic standpoint, it's definitely a smaller change to the code. I think this also lends credence to my prior sentence.

(Followups trimmed.)

John

racket-bug-submit commented 12 years ago

On Wed, 31 Oct 2007 15:06:47 -0700, clements@brinckerhoff.org wrote:

--Apple-Mail-12-812842837 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed

On Oct 31, 2007, at 3:03 PM, Jacob Matthews wrote:

On Oct 31, 2007 2:51 PM, Matthias Felleisen matthias@ccs.neu.edu
wrote:

I prefer John's solution. Works like a charm and is intuitive.

Unless I'm missing something it won't work for toplevel names that are introduced by imports, such as bindings from teachpacks or builtins. Consider

(define (g f) (lambda (cons) (f cons empty)))

(g cons)

This is exactly the free-variable capture problem (treating variables that aren't bound in the source code of the program as free). IMHO it's probably not worthwhile to try for a `simpler' solution than the standard one.

I was hoping to be able to report that this was illegal, but it's not.

John

--Apple-Mail-12-812842837 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIF4jCCApsw ggIEoAMCAQICECrxHj7xTe6SpIhCjvYe48cwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDQxMjIzMjQzNFoXDTA4MDQxMTIzMjQz NFowfjERMA8GA1UEBBMIQ2xlbWVudHMxGjAYBgNVBCoTEUpvaG4gQnJpbmNrZXJob2ZmMSMwIQYD VQQDExpKb2huIEJyaW5ja2VyaG9mZiBDbGVtZW50czEoMCYGCSqGSIb3DQEJARYZY2xlbWVudHNA YnJpbmNrZXJob2ZmLm9yZzCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAs/Lht6S+RcCb6gyF MAddibx+w9YI6Cn06p1cY8w+vxOHfL6bZTsMuHmPcdWvu0OY2JLOvPYRPZEVMSs33bg9mG9XsIqF smEk3iSuCNQwJVdCBHfYC2LHYFDLfe6l9lWoQe3oUqsA+fPTpWAuKSkophu1sEyZ+wkhDKFI9JCo zC0CAwEAAaM2MDQwJAYDVR0RBB0wG4EZY2xlbWVudHNAYnJpbmNrZXJob2ZmLm9yZzAMBgNVHRMB Af8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAHafJPfjtPhrdMY9bSP+mO/zHHDkEr1thzvH7zuGZ3rB DWBfScBVrv7BSxN/rQjJ2HaLIe0ANkWIQxdAMaW4qmAdFRwFyO3hnQkiCYBoLrXZ1S6hvqX5+Nfa D9HiDDd5Wf1HA4UJJYokTXSWPX2Z0pPEVaK9oqsgRrojkdZgxuZVMIIDPzCCAqigAwIBAgIBDTAN BgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAG A1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2Vy dGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZy ZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4X DTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoe aMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwL B+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3 +wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDov L2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEG MCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUF AAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD 2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfj ViF4gtwhGTXeJLHTHUb/XV9lTzGCAo8wggKLAgEBMHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBJc3N1aW5nIENBAhAq8R4+8U3ukqSIQo72HuPHMAkGBSsOAwIaBQCgggFvMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA3MTAzMTIyMDY0OFowIwYJKoZI hvcNAQkEMRYEFHx4Zuefyaa+KL1DuXQiyzSYOukDMIGFBgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNV BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQKvEePvFN7pKkiEKO9h7jxzCBhwYL KoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQKvEePvFN7pKkiEKO9h7jxzANBgkqhkiG9w0BAQEFAASBgJryz+iEer8HHGLE9Xqqq7ffhYA1 Nw09G+qYUygxEmx6hXvLKFbprvflehId1q76SxDA/kXXmB2XoV4RfuGaDcaqHTw1c4cQS5RFp7Sz YPEqcbjl90JVHlyVsRFXhHGhor1aN4mtujAXYv51Y7RpAKW4oqM8MbhQBxQczQjfPNgXAAAAAAAA

--Apple-Mail-12-812842837--

racket-bug-submit commented 12 years ago

On Wed, 31 Oct 2007 15:05:28 -0700, clements@brinckerhoff.org wrote:

--Apple-Mail-11-812767144 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed

On Oct 31, 2007, at 2:55 PM, Robby Findler wrote:

You can rename the set!s too, no?

I actually think that the other is more intuitive, at least once you take a slightly deeper look. (At first glance, no, I agree with that.)

This last sentence is surely one of the most fascinating last
sentences of any e-mail I've ever receieved... :).

I agree with Robby on his first point; I don't see the problem
example with set! and renaming of top-level variables. I do see a
problem with set! of non-top-level variables, but fortunately none of
the teaching languages (incl. Advanced) make this possible (at least,
not the last time I checked).

WRT the intuitiveness of the solution: I think that my proposal is
more consistent with the treatment of local in intermediate. From a
pragmatic standpoint, it's definitely a smaller change to the code. I
think this also lends credence to my prior sentence.

(Followups trimmed.)

John

--Apple-Mail-11-812767144 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIF4jCCApsw ggIEoAMCAQICECrxHj7xTe6SpIhCjvYe48cwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDQxMjIzMjQzNFoXDTA4MDQxMTIzMjQz NFowfjERMA8GA1UEBBMIQ2xlbWVudHMxGjAYBgNVBCoTEUpvaG4gQnJpbmNrZXJob2ZmMSMwIQYD VQQDExpKb2huIEJyaW5ja2VyaG9mZiBDbGVtZW50czEoMCYGCSqGSIb3DQEJARYZY2xlbWVudHNA YnJpbmNrZXJob2ZmLm9yZzCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAs/Lht6S+RcCb6gyF MAddibx+w9YI6Cn06p1cY8w+vxOHfL6bZTsMuHmPcdWvu0OY2JLOvPYRPZEVMSs33bg9mG9XsIqF smEk3iSuCNQwJVdCBHfYC2LHYFDLfe6l9lWoQe3oUqsA+fPTpWAuKSkophu1sEyZ+wkhDKFI9JCo zC0CAwEAAaM2MDQwJAYDVR0RBB0wG4EZY2xlbWVudHNAYnJpbmNrZXJob2ZmLm9yZzAMBgNVHRMB Af8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAHafJPfjtPhrdMY9bSP+mO/zHHDkEr1thzvH7zuGZ3rB DWBfScBVrv7BSxN/rQjJ2HaLIe0ANkWIQxdAMaW4qmAdFRwFyO3hnQkiCYBoLrXZ1S6hvqX5+Nfa D9HiDDd5Wf1HA4UJJYokTXSWPX2Z0pPEVaK9oqsgRrojkdZgxuZVMIIDPzCCAqigAwIBAgIBDTAN BgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAG A1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2Vy dGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZy ZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4X DTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoe aMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwL B+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3 +wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDov L2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEG MCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUF AAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD 2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfj ViF4gtwhGTXeJLHTHUb/XV9lTzGCAo8wggKLAgEBMHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBJc3N1aW5nIENBAhAq8R4+8U3ukqSIQo72HuPHMAkGBSsOAwIaBQCgggFvMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA3MTAzMTIyMDUyOVowIwYJKoZI hvcNAQkEMRYEFKEuuj3wXEroi+YgLeogyuuCrOc7MIGFBgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNV BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQKvEePvFN7pKkiEKO9h7jxzCBhwYL KoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQKvEePvFN7pKkiEKO9h7jxzANBgkqhkiG9w0BAQEFAASBgERBzOkFsFwpApVaz4tqDTx+sgu0 iCzP3a2KZOOIGzEErHQd4AOm1fa3F4/cq+q7TD8wQNbvkkGYdQmlQ5deJvmy9iDGgWr50ppQiywN HBaYVq/FK/vyPCJrlPY2uKj815nALK+7mP4ekv3FJ6AOcbZedKQcDNQMlrooSBsA556tAAAAAAAA

--Apple-Mail-11-812767144--

racket-bug-submit commented 12 years ago

On Wed, 31 Oct 2007 17:06:16 -0500, robby@cs.uchicago.edu wrote:

Oh! I had just assumed that shadowing top-level names would be an error in the teaching languages, but I see that it isn't.

Perhaps we should make it be?

Robby

On 10/31/07, Jacob Matthews jacobm@cs.uchicago.edu wrote:

On Oct 31, 2007 2:51 PM, Matthias Felleisen matthias@ccs.neu.edu wrote:

I prefer John's solution. Works like a charm and is intuitive.

Unless I'm missing something it won't work for toplevel names that are introduced by imports, such as bindings from teachpacks or builtins. Consider

(define (g f) (lambda (cons) (f cons empty)))

(g cons)

This is exactly the free-variable capture problem (treating variables that aren't bound in the source code of the program as free). IMHO it's probably not worthwhile to try for a `simpler' solution than the standard one.

-jacob

On Oct 31, 2007, at 5:33 PM, Robby Findler wrote:

Usually one renames bound identifiers to work around this (since free identifiers can't be freely renamed).

Robby

On 10/31/07, John Clements clements@brinckerhoff.org wrote:

On Oct 31, 2007, at 2:03 PM, Matthias Felleisen wrote:

Eh? It violates the specification! Your paper is not broken because you used closed lambda terms.

Okay, okay...

The basic problem here is the top-level variables. That is, if the "x" bound in the (lambda (y) x) term were a non-top-level variable, it would be shown as (lambda (y) 42), rather than (lambda (y) x).

So, the apparent fix would be to perform renaming on all top-level variables, not just those bound by a "local". Naturally, this would only be necessary in languages where lambdas are displayed as inline lambdas. That is, intermediate-with-lambda and up.

Sound good?

John Clements

racket-bug-submit commented 12 years ago

On Wed, 31 Oct 2007 18:08:06 -0400, matthias@ccs.neu.edu wrote:

Same here. How silly I am.

On Oct 31, 2007, at 6:06 PM, Robby Findler wrote:

Oh! I had just assumed that shadowing top-level names would be an error in the teaching languages, but I see that it isn't.

Perhaps we should make it be?

Robby

On 10/31/07, Jacob Matthews jacobm@cs.uchicago.edu wrote:

On Oct 31, 2007 2:51 PM, Matthias Felleisen matthias@ccs.neu.edu
wrote:

I prefer John's solution. Works like a charm and is intuitive.

Unless I'm missing something it won't work for toplevel names that
are introduced by imports, such as bindings from teachpacks or builtins. Consider

(define (g f) (lambda (cons) (f cons empty)))

(g cons)

This is exactly the free-variable capture problem (treating variables that aren't bound in the source code of the program as free). IMHO it's probably not worthwhile to try for a `simpler' solution than the standard one.

-jacob

On Oct 31, 2007, at 5:33 PM, Robby Findler wrote:

Usually one renames bound identifiers to work around this (since
free identifiers can't be freely renamed).

Robby

On 10/31/07, John Clements clements@brinckerhoff.org wrote:

On Oct 31, 2007, at 2:03 PM, Matthias Felleisen wrote:

Eh? It violates the specification! Your paper is not broken
because you used closed lambda terms.

Okay, okay...

The basic problem here is the top-level variables. That is, if
the "x" bound in the (lambda (y) x) term were a non-top-level
variable, it would be shown as (lambda (y) 42), rather than (lambda (y) x).

So, the apparent fix would be to perform renaming on all top-level variables, not just those bound by a "local". Naturally, this
would only be necessary in languages where lambdas are displayed as
inline lambdas. That is, intermediate-with-lambda and up.

Sound good?

John Clements