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?

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?

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.

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

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.

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

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

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.

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

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! ;-)