View mode: basic / threaded / horizontal-split · Log in · Help
December 15, 2005
A small annoyance, can D make this better?
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
Re: A small annoyance, can D make this better?
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
Re: A small annoyance, can D make this better?
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
Re: A small annoyance, can D make this better?
"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
Re: A small annoyance, can D make this better?
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
Re: A small annoyance, can D make this better?
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
Re: A small annoyance, can D make this better?
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
Re: A small annoyance, can D make this better?
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
Re: A small annoyance, can D make this better?
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
Re: A small annoyance, can D make this better?
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