View mode: basic / threaded / horizontal-split · Log in · Help
July 11, 2007
Re: version and extern problems
Walter Bright Wrote:

> BCS wrote:
> > That is one thing I have never understood: why does lexical order ever 
> > (outside of statement lists e.i. function) ever cause an issue?
> 
> const string x = "abc" ~ foo;
> const string foo = x[1..4];

Surely that's just an "x is not defined on line 2" error?
July 11, 2007
Re: version and extern problems
On Tue, 10 Jul 2007 20:24:23 -0400, Walter Bright  
<newshound1@digitalmars.com> wrote:

> BCS wrote:
>> That is one thing I have never understood: why does lexical order ever  
>> (outside of statement lists e.i. function) ever cause an issue?
>
> const string x = "abc" ~ foo;
> const string foo = x[1..4];

This is always an issue and should cause an error, if extern uses strings  
or not. How does this really pertain to extern that doesn't cause problems  
even without the requested feature?
July 11, 2007
Re: version and extern problems
Reply to Walter,

> BCS wrote:
> 
>> That is one thing I have never understood: why does lexical order
>> ever (outside of statement lists e.i. function) ever cause an issue?
>> 
> const string x = "abc" ~ foo;
> const string foo = x[1..4];

That has little or nothing to do with lexical order. Baring retro-order dependencies 
does remove this type of error, but it also bars otherwise valid code.

I would propose that the evaluation could run like this:

use rand() to pick something to start with (not needed but it would work 
anyway)
attempt to evaluate value of foo
foo requires x
attempt to evaluate value of x
x requires foo
we have started but not finished evaluating x therefor "Error: cyclical dependency 
for foo"


The same model could be used for auto typing, template evaluation or whatever. 
As long as you never have to evaluate something as part of evaluating itself, 
order can be ignored.
July 11, 2007
Re: version and extern problems
"Walter Bright" <newshound1@digitalmars.com> wrote in message 
news:f70vtc$opn$1@digitalmars.com...
> Jarrett Billingsley wrote:
>>
>> Mind elaborating?  I can't see how this is a forward reference issue.
>
> Sure. What if the string is a const string defined after it is used?

Then fail.  It still wouldn't prevent the much more sensible and commond 
case of defining the string _before_ the extern.
July 11, 2007
Re: version and extern problems
Jarrett Billingsley wrote:
> "Walter Bright" <newshound1@digitalmars.com> wrote in message 
> news:f70vtc$opn$1@digitalmars.com...
>> Jarrett Billingsley wrote:
>>> Mind elaborating?  I can't see how this is a forward reference issue.
>> Sure. What if the string is a const string defined after it is used?
> 
> Then fail.  It still wouldn't prevent the much more sensible and commond 
> case of defining the string _before_ the extern. 

There are several bug reports marked as important in bugzilla where 
people are very desirous of using things lexically before they are 
defined. I do not wish to add to it.
July 11, 2007
Re: version and extern problems
nonnymouse wrote:
> Surely that's just an "x is not defined on line 2" error?

Nope. This, for example, is a perfectly valid D programme:

---<snip>---
module test;

int y=3+x;
const int x=5;

void main()
{
  printf("x=%i y=%i\n",x,y);
}
---<snap>---

Seems like D collects all declarations first, unlike C.

Regards, Frank
July 11, 2007
Re: version and extern problems
0ffh wrote:
> nonnymouse wrote:
>> Surely that's just an "x is not defined on line 2" error?
> 
> Nope. This, for example, is a perfectly valid D programme:
> 
> ---<snip>---
> module test;
> 
> int y=3+x;
> const int x=5;
> 
> void main()
> {
>   printf("x=%i y=%i\n",x,y);
> }
> ---<snap>---
> 
> Seems like D collects all declarations first, unlike C.
> 
> Regards, Frank


The snippet you snipped was:
const string x = "abc" ~ foo;
const string foo = x[1..4];

So more like
const int y=3+x;
const int x=5+y;

No matter which order you scan that, you can't come to a valid order of 
initialization.

--bb
July 11, 2007
Re: version and extern problems
0ffh Wrote:

> Nope. This, for example, is a perfectly valid D program:
[snip]
Then it must be "foo is not defined on line 1". ;-)

I think maybe you thought I said line 1 last time. I said line 2. I was assuming that the compiler had looked ahead and come to a dead-end (or more expressively: a cul-de-sac).
(We are assuming that is either the whole program or the only lines that matter here are we?)

At some point, even if it is just before code generation all these symbols need to be defined. The compiler must choose a, possibly arbitrary,  order in which it fills them. Surely when going through the AST to do this for a particular symbol, if it meets itself further down the tree it throws an error.

I chose a sarcastically vague one.. "Symbol x cannot de defined as definition of x is based on definition of x" might make a bit more sense.

Please, if possible, read this as a question rather than an answer. i.e I would genuinely like to be corrected where I have misunderstood (or missed out) some of the complexities of these issues.
July 11, 2007
Re: version and extern problems
Bill Baxter wrote:
> So more like
> const int y=3+x;
> const int x=5+y;
> 
> No matter which order you scan that, you can't come to a valid order of 
> initialization.

I get that, really, I do.
I just wanted to point out why
  'Surely that's just an "x is not defined on line 2" error?'
does not hold, nor is to the point (which you just repeated).

Regards, frank
July 11, 2007
Re: version and extern problems
nonnymouse wrote:
> 0ffh Wrote:
> 
>> Nope. This, for example, is a perfectly valid D program:
> [snip] Then it must be "foo is not defined on line 1". ;-)
> 
> I think maybe you thought I said line 1 last time. I said line 2. I was assuming that the compiler had 
> looked ahead and come to a dead-end (or more expressively: a cul-de-sac). (We are assuming that is either 
> the whole program or the only lines that matter here are we?)

Oops, now I get your drift. I was indeed misunderstanding you!
I think one might rather choose to call it a circular or recursive problem...

> At some point, even if it is just before code generation all these symbols need to be defined.
> [...] "Symbol x cannot de defined as definition of x is based on definition of x" might make a bit more sense.
> Please, if possible, read this as a question rather than an answer. i.e I would genuinely like to be 
> corrected where I have misunderstood (or missed out) some of the complexities of these issues.

Well, I think the gist of your explanation is right, even if we cannot know
about the actual implementation details.

Regards, frank

p.s.
Funny thing, I don't get you; and in turn Bill doesn't get me! That's Karma, if not coincidence! ;-)
1 2 3 4 5 6
Top | Discussion index | About this forum | D home