The way to think about it is that there are two let forms in the REPL (or top-level):
# let a = 1 a : int = 1 # let b = 4 in b *b 16 The first one adds a to the top-level scope, and initializes it to 1. The second is a local let-binding that is not exported to the scope. PKE From: bitc-dev [mailto:[email protected]] On Behalf Of Jonathan S. Shapiro Sent: Friday, May 01, 2015 11:34 AM To: Discussions about the BitC language Subject: Re: [bitc-dev] binding syntax/semantics question On Fri, May 1, 2015 at 11:14 AM, Raoul Duke <[email protected]<mailto:[email protected]>> wrote: > x is not rebound because it has gone out of scope. Most functional languages > nonetheless diagnose this as a rebinding. wow, i never knew/noticed that. seems kind of lame to me. I'd characterize it as a discrepancy between the semantics and the requirements of usability. From a semantic perspective, there actually *is* a top-level let binding whether you use LET or DEF or some other keyword. What's odd about this case is that when LET is used at top-level it has different behavior than when it is used internal to a procedure (where a second binding of x after the first binding goes out of scope usually is NOT diagnosed. To put it another way: diagnosing the rebinding means that in a weird way a let-bound binding places it's symbol in a special scope that is just *outside* the scope of the let and just *inside* what we would normally think of as the parent scope. We can certainly tell a story about that which makes the behavior consistent, rational, and explained. It's just that this story isn't the story we are actually telling about the behavior of LET. :-) Also, I should think that LET's behavior should be consistent regardless of the scope in which the LET appears. That is: top-level shouldn't be any more magical than it strictly has to be. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
