December 15, 2005
Today a friend of mine (a less experienced programmer) made a mistake which he could not immediately figure out, so he asked me, the mistake was:

time_t time;
time(&time);

I immediately spotted it because I've done this or something like it a few times before. :)

This lead me to thinking, what does D do in this situation? and so I coded:

void foo(int foo) {}
void main() {
	int foo;	
	foo(5); //function expected before (), not foo of type int
}

in short, the same thing. However it was pleasing to note that the error is better in D's case, the C complier gave simply...

  'time' : not a function

I think we all realise the int 'foo' is hiding the function 'foo'. But, the reason that it hides it, is it that D looks for a match in the lowest enclosing scope (that of 'main') and when it finds a match it stops looking, it does not step back up a scope and see the function 'foo'?

I believe this is the case. I believe this is due to the resolution rules D uses, which were copied from C.

Next question, can D handle this any 'better'?

I realise there is no chance that the resolution rules for D will be changed, it will likely always stop as soon as it finds a 'match'. (and I don't want to restart this old argument!) However.. I wonder if D's "context free grammar" allows us to make the resolution smarter by defining more exactly what constitutes a match? In this case, can it tell for certain that:

foo(5);

is a function call? and if it can, can it not ignore non function symbols as it tries to resolve the function call?

In other words can the above validly/correctly find and call the function foo?

Even assuming there are cases which remain ambiguous provided there are cases which are not, can't the resolution still be made smarter by ignoring symbols of the wrong type?

Thoughts?

Regan
December 15, 2005
On Thu, 15 Dec 2005 14:56:57 +1300, Regan Heath wrote:

> In this case, can it tell for certain that:
> 
> foo(5);
> 
> is a function call?

This might not help but from the syntax alone, you cannot tell if it is a call to a function called 'foo', or to 'foo.opCall(5)'. So it might not be so easy for the compiler.


-- 
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 1:19:37 PM
December 15, 2005
In article <ops1syc7n623k2f5@nrage.netwin.co.nz>, Regan Heath says...
>
>Today a friend of mine (a less experienced programmer) made a mistake which he could not immediately figure out, so he asked me, the mistake was:
>
>time_t time;
>time(&time);
>
>I immediately spotted it because I've done this or something like it a few times before. :)
>
>This lead me to thinking, what does D do in this situation? and so I coded:
>
>void foo(int foo) {}
>void main() {
>	int foo;
>	foo(5); //function expected before (), not foo of type int
>}
>
>in short, the same thing. However it was pleasing to note that the error is better in D's case, the C complier gave simply...
>
>   'time' : not a function
>
>I think we all realise the int 'foo' is hiding the function 'foo'. But, the reason that it hides it, is it that D looks for a match in the lowest enclosing scope (that of 'main') and when it finds a match it stops looking, it does not step back up a scope and see the function 'foo'?
>
>I believe this is the case. I believe this is due to the resolution rules D uses, which were copied from C.
>
>Next question, can D handle this any 'better'?
>
>I realise there is no chance that the resolution rules for D will be changed, it will likely always stop as soon as it finds a 'match'. (and I don't want to restart this old argument!) However.. I wonder if D's "context free grammar" allows us to make the resolution smarter by defining more exactly what constitutes a match? In this case, can it tell for certain that:
>
>foo(5);
>
>is a function call? and if it can, can it not ignore non function symbols as it tries to resolve the function call?
>
>In other words can the above validly/correctly find and call the function foo?
>
>Even assuming there are cases which remain ambiguous provided there are cases which are not, can't the resolution still be made smarter by ignoring symbols of the wrong type?
>
>Thoughts?

IMO it would lead to confusing and unclear code (also very error prone).
If this was allowed, couldn't it create hard-to-find errors?  (I'm not good to
fabricate mean examples) :)

Tom
December 15, 2005
"Regan Heath" <regan@netwin.co.nz> wrote in message news:ops1syc7n623k2f5@nrage.netwin.co.nz...
> Today a friend of mine (a less experienced programmer) made a mistake which he could not immediately figure out, so he asked me, the mistake was:
>
> time_t time;
> time(&time);
>
> I immediately spotted it because I've done this or something like it a few times before. :)
>
> This lead me to thinking, what does D do in this situation? and so I coded:
>
> void foo(int foo) {}
> void main() {
> int foo; foo(5); //function expected before (), not foo of type int
> }
>
> in short, the same thing. However it was pleasing to note that the error is better in D's case, the C complier gave simply...
>
>   'time' : not a function
>
> I think we all realise the int 'foo' is hiding the function 'foo'. But, the reason that it hides it, is it that D looks for a match in the lowest enclosing scope (that of 'main') and when it finds a match it stops looking, it does not step back up a scope and see the function 'foo'?
>
> I believe this is the case. I believe this is due to the resolution rules D uses, which were copied from C.
>
> Next question, can D handle this any 'better'?
>
> I realise there is no chance that the resolution rules for D will be changed, it will likely always stop as soon as it finds a 'match'. (and I don't want to restart this old argument!) However.. I wonder if D's "context free grammar" allows us to make the resolution smarter by defining more exactly what constitutes a match? In this case, can it tell for certain that:
>
> foo(5);
>
> is a function call? and if it can, can it not ignore non function symbols as it tries to resolve the function call?
>
> In other words can the above validly/correctly find and call the function foo?
>
> Even assuming there are cases which remain ambiguous provided there are cases which are not, can't the resolution still be made smarter by ignoring symbols of the wrong type?
>
> Thoughts?
>
I believe this could be useful to an extent, though it could open up the
possibilities for wrong or vague naming; calling a function and variable the
same thing is something (and please correct me if I'm wrong) that by
definition should not happen too often.
On the other hand, the compiler should not attempt to instruct the
programmer in naming, and I can see definite uses in the variable/function
pools beeing separate.
> Regan


December 15, 2005
On Thu, 15 Dec 2005 13:23:38 +1100, Derek Parnell <derek@psych.ward> wrote:
> On Thu, 15 Dec 2005 14:56:57 +1300, Regan Heath wrote:
>
>> In this case, can it tell
>> for certain that:
>>
>> foo(5);
>>
>> is a function call?
>
> This might not help but from the syntax alone, you cannot tell if it is a
> call to a function called 'foo', or to 'foo.opCall(5)'. So it might not be so easy for the compiler.

Good point. In either case it's not an 'int' though, so theoretically it could skip some types and not others when looking for a match, assuming it has such knowledge at the time.

Regan
December 15, 2005
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 :)

> 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
December 15, 2005
On Wed, 14 Dec 2005 21:36:01 -0500, Ameer Armaly <ameer_armaly@hotmail.com> wrote:
> "Regan Heath" <regan@netwin.co.nz> wrote in message
> news:ops1syc7n623k2f5@nrage.netwin.co.nz...
>> Thoughts?
>>
> I believe this could be useful to an extent, though it could open up the
> possibilities for wrong or vague naming; calling a function and variable the same thing is something (and please correct me if I'm wrong) that by
> definition should not happen too often.

Perhaps, perhaps not, perhaps we are simply used to not being able to do it?

I suspect the cases in which this idea could be applied are fairly limited (maybe reason enough not to bother), they're the really obvious ones, in which case they shouldn't be confusing in and of themselves and it does allow us to call our variables what we want, where we want.

> On the other hand, the compiler should not attempt to instruct the
> programmer in naming, and I can see definite uses in the variable/function pools beeing separate.

Indeed. A case which has caught me in the past was using "read" to indicate how many things I had read, this then conflicted with the function "read" which reads data.

Regan

December 15, 2005
On Thu, 15 Dec 2005 15:50:25 +1300, Regan Heath wrote:

> 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.

LOL ... of course not. I use a half-decent naming convention for variables so I wouldn't have a function and a variable with the same name in my programs.

 void foo(int pFoo) // 'p' means a parameter
 {
 }

 void main()
 {
    int lFoo;	// 'l' means local scope
    foo(5);
 }

-- 
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 2:29:04 PM
December 15, 2005
Regan Heath wrote:

[...]
> Indeed. A case which has caught me in the past was using "read" to  indicate how many things I had read, this then conflicted with the  function "read" which reads data.

... and next time you have a function variable named `read' that conflicts with a function named `read'?

-manfred
December 15, 2005
Regan Heath wrote:

[...]
> is a function call? and if it can, can it not ignore non function symbols  as it tries to resolve the function call?
[...]

That is BASIC-like.

In fact the scope rules used in D are currently C-like and algol- like. Both scope rules stemmed from the idea that functions or blocks would be coded by different people and then textually merged into another function or block.

Doing so would introduce naming conflicts in case of not supporting this action. This assumption is not true any more, if it ever was.

The module concept isolates the work of each individual and make it reachable, shielded by the protection rules.

Therefore Walters decision to drop the C-like scoping, change to algol-like scoping and drop the exception for inner scopes is the right way to go.

algol-like scope rule:
A binding is valid within the whole smallest range containing the
definition, except in inner ranges where a binding for the same
identifier holds. An identifier may be used before its definition.

D-like scope rule should be:
A binding is valid within the whole smallest range containing the
definition. An identifier may be used before its definition.

-manfred
« First   ‹ Prev
1 2
Top | Discussion index | About this forum | D home