Re: A question about certain language features
- Posted by kbochert at ix.netcom.com Feb 17, 2002
- 608 views
-------Phoenix-Boundary-07081998- You wrote on 2/16/02 6:55:21 PM: > >Finally I just understood: > >integer foo foo=123 >integer bar bar=7 >procedure f(integer k, sequence s) > >is fine, but > >procedure f(integer k, sequence s) >integer foo foo=123 >integer bar bar=7 > >gives an error. It's all about scoping rules. Eg a for loop introduces >a new scope, so in > >for i=1 to 10 do >.... >integer k > >end for > >what the hell would be k's scope? (not that anyone is asking for >integer declarations in the middle of a for loop, but it's all part & >parcel of the same thing.) Above, the scope of bar clearly would not >include the code foo=123 but the only scope bar can legally have is >all of procedure k. And the semantic problems. Rob, if you're >listening, please please NEVER put that in! > The simple rule that could be used is that the scope of a variable extends from it's point of declaration to the end of the current block. k's scope would be from its declaration to the end of the for statement, just like i's scope is from 'i=1' to the end of the for loop. bar's scope would be from it's declaration to the end of the procedure (not including the 'foo=123' line). The only issue is whether the interpreter will always see the declaration before it sees any references, which is why declarations are normally restricted to the start of blocks. If it did see a reference first, the result would be no worse than an uninitialized variable. >And when that happens, the Euphoria interpreter stops, and >anything the user was doing is permanantly lost. >... > Rob, forget scoping or multiple >or nested recovery routines, just one at top level. Good idea! I would think it quite easy to make the interpreter find and execute a specifically-named procedure when a fatal error is encountered. The programmer would make sure the recovery routine was coded at the start (right after the globals it needed) so it would be available. Wouldn't solve everything but a LOT better than nothing. Karl Bochert -------Phoenix-Boundary-07081998---