Re: Implicit variables - should they be reserved keywords?

[Evan Lavelle <anti.spam1@dsl.pipex.com>]

Galpin Darren (DC BRS) wrote:

> This wouldn't happen if result was a reserved word - the code with 
> either be syntactically correct or incorrect at the beginning, with no 
> scope for confusion. I would like to propose this as a change to the LRM 
> - does anyone agree or disagree with this?

I had the same problem recently with the design of another language, 
which also uses implicit named variables and, IMHO, this isn't the right 
way to go.

The main problem is backwards-compatibility - some existing programs 
wouldn't compile. A second problem is that it complicates the 
implementation. Think about writing an expression syntax, for example: 
an expression is a combination of names and operators. But if you allow 
certain keywords to also be names, you also have to cope with 
combinations of keywords and operators. This isn't a big problem, but it 
isn't clean, and it adds unnecessary complexity.

It's also not intuitively the right way to deal with implicit variables 
- an implicit variable is just a variable that has already been created 
for you, with a known name. It's much better, IMO, just to treat it in 
the same way as any other variable, and to allow the programmer to 
declare their own 'result' variables in contexts where the compiler 
doesn't already create one (what 'e' already does).

Having said that, I think your example code does show a problem. I think 
a better fix, if it was necessary, would be to ensure that all methods, 
not just value-returning methods, have an implicit 'result'; this would 
mean that 'result' only has a scope within the current method. This 
would give a more logical result in your second example, and also has 
the advantage of being less likely to cause backwards-compatibility 
problems.

Evan Lavelle
Riverside Machines Ltd.