Derek Parnell wrote:

[...]
> so I wouldn't have a function and a variable with the
> same name in my programs.
[...]
>     int lFoo;     // 'l' means local scope
[...]

But maybe integer and float local variables are called the same?

void f(){
  int lFoo:
  void g(){
    real lFoo;
    lFoo= 1; // now what?
  }
}

-manfred

On Thu, 15 Dec 2005 06:16:40 +0000 (UTC), Manfred Nowak wrote:

> Derek Parnell wrote:
> 
> [...]
>> so I wouldn't have a function and a variable with the
>> same name in my programs.
> [...]
>>     int lFoo;     // 'l' means local scope
> [...]
> 
> But maybe integer and float local variables are called the same?
> 
> void f(){
>   int lFoo:
>   void g(){
>     real lFoo;
>     lFoo= 1; // now what?
>   }
> }

Yuck! Who'd be mad enough to write code like that! That's just plainly silly. Would it not be better to give variables a meaningful name for the purpose that they are used for?

But I digress .. the 'l' prefix still means 'local' to me. So the 'lFoo= 1;' line assigns a value to the variable that is *local* to the assignment's scope. In this case, the one defined inside the g() function.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"A learning experience is one of those things that says,
 'You know that thing you just did? Don't do that.'" - D.N. Adams
15/12/2005 5:41:37 PM

Derek Parnell wrote:

[...]
> In this case, the one defined inside the g() function.

And that is opposite to the scope rule Regan proposes.

Following Regan the plausible extension would be:

void g(){
  int lRead;
  real lRead,

  lRead= 1;
  lRead= 2.0L;

  writefln( int.lRead, " ", real.lRead);
}

Because in essence he wants to change the identifier look up to a lookup for the pair consisting of the identifier and a type, making variables attributes of types and introducing the (nearly?) same overloading mechanisms for variables as for functions.

Hmmmm ... interesting, never thought of that before.

-manfred

On Thu, 15 Dec 2005 07:21:40 +0000 (UTC), Manfred Nowak wrote:

> Derek Parnell wrote:
> 
> [...]
>> In this case, the one defined inside the g() function.
> 
> And that is opposite to the scope rule Regan proposes.
> 
> Following Regan the plausible extension would be:
> 
> void g(){
>   int lRead;
>   real lRead,
> 
>   lRead= 1;
>   lRead= 2.0L;
> 
>   writefln( int.lRead, " ", real.lRead);
> }
> 
> Because in essence he wants to change the identifier look up to a lookup for the pair consisting of the identifier and a type, making variables attributes of types and introducing the (nearly?) same overloading mechanisms for variables as for functions.
> 
> Hmmmm ... interesting, never thought of that before.
> 
> -manfred

Something wicked this way comes ... I can only see tears if this is adopted. On the other hand, we still have goto so this is just as trouble-causing as that construct.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"A learning experience is one of those things that says,
 'You know that thing you just did? Don't do that.'" - D.N. Adams
15/12/2005 6:34:36 PM

In article <ops1s0ubkp23k2f5@nrage.netwin.co.nz>, Regan Heath says...
>
>On Thu, 15 Dec 2005 02:25:32 +0000 (UTC), Tom <Tom_member@pathlink.com> wrote:
>> In article <ops1syc7n623k2f5@nrage.netwin.co.nz>, Regan Heath says...
>>> Thoughts?
>>
>> IMO it would lead to confusing and unclear code (also very error prone).
>
>I'd say that it would _allow_ confusing and unclear code. I don't expect people like Derek :) would ever use it intentionally. It could be said that the fact that it allows it is bad enough :)

You're right, maybe it's my poor english narrative :P

>> If this was allowed, couldn't it create hard-to-find errors?  (I'm not good to fabricate mean examples) :)
>
>I can't think of one, if anyone can please post it.
>
>Regan

Tom