Walter Bright wrote:
So, I propose the following:
1. Attempt the depth-first traversal of the static constructors.
2. If a loop is detected, rather than issuing an error message, simply
arbitrarily pick one order and continue constructing.
I'm of the camp that "if it's broken, the programmer
Walter Bright wrote:
Regan Heath wrote:
So, this needs to work when compiling modules seperately and then
linking, likewise libraries, right? Is that the problem you're
referring to?
Yes.
Couldn't you store a list of dependencies in usage order in the output
of the compile (the .o[bj] file
Regan Heath wrote:
So, this needs to work when compiling modules seperately and then
linking, likewise libraries, right? Is that the problem you're
referring to?
Yes.
Couldn't you store a list of dependencies in usage order in the output
of the compile (the .o[bj] file) and use these lists
Walter Bright wrote:
Regan Heath wrote:
Walter Bright wrote:
Regan Heath wrote:
Walter Bright wrote:
Regan Heath wrote:
I expect this either isn't possible or falls into the 'possible up
to a point' category.
It's possible up to a point, that point being the parts of the
program the comp
Regan Heath wrote:
Walter Bright wrote:
Regan Heath wrote:
Walter Bright wrote:
Regan Heath wrote:
I expect this either isn't possible or falls into the 'possible up
to a point' category.
It's possible up to a point, that point being the parts of the
program the compiler does not see.
S
Walter Bright wrote:
Regan Heath wrote:
Walter Bright wrote:
Regan Heath wrote:
I expect this either isn't possible or falls into the 'possible up
to a point' category.
It's possible up to a point, that point being the parts of the
program the compiler does not see.
So.. isn't that the s
Regan Heath wrote:
Walter Bright wrote:
Regan Heath wrote:
I expect this either isn't possible or falls into the 'possible up to
a point' category.
It's possible up to a point, that point being the parts of the program
the compiler does not see.
So.. isn't that the same point the current
Walter Bright wrote:
Regan Heath wrote:
I expect this either isn't possible or falls into the 'possible up to
a point' category.
It's possible up to a point, that point being the parts of the program
the compiler does not see.
So.. isn't that the same point the current import dependency me
Regan Heath wrote:
I expect this either isn't possible or falls into the 'possible up to a
point' category.
It's possible up to a point, that point being the parts of the program
the compiler does not see.
Walter Bright wrote:
Doing lazy initialization certainly works, but it would require all
static member access to go through a check for initialization, first.
The cost of this check persists for a statically compiled language; for
a JITted language like C# the access can be rewritten to remove
BCS, el 12 de marzo a las 04:43 me escribiste:
> Hello Walter,
>
> >2. If a loop is detected, rather than issuing an error message, simply
> >arbitrarily pick one order and continue constructing.
>
> How about a way to explicitly cut edges in the graph (tagging
> imports with "pragma(nodep)" or "
On 13.03.2010 2:27, Michel Fortin wrote:
On 2010-03-12 19:10:10 -0500, Max Samukha said:
If static constructors in templates ran during the initialization of
the module where they are defined, the problem with mixed-in code
could be solved like this:
But templates can take function and types
On 2010-03-12 19:10:10 -0500, Max Samukha said:
If static constructors in templates ran during the initialization of
the module where they are defined, the problem with mixed-in code could
be solved like this:
But templates can take function and types as argument. If the 'static
this' of a
On 12.03.2010 23:03, Walter Bright wrote:
BCS wrote:
Random thought: Aside from making a new corner case, why not make
static constructors in mixins only depend on imports from where they
are defined rather than where they are used?
Template mixins are intended to behave like macros - they ar
BCS wrote:
Hello Walter,
Don wrote:
If that's true, then perhaps a more restricted solution is better.
Eg, use Walter's proposal ONLY if the static initializer is mixed in.
I should note that all static constructors in a module are combined
into one function. So, the mixin static initialize
On 12-mar-10, at 19:17, Walter Bright wrote:
Doing lazy initialization certainly works, but it would require all
static member access to go through a check for initialization,
first. The cost of this check persists for a statically compiled
language; for a JITted language like C# the acces
Hello Walter,
Don wrote:
If that's true, then perhaps a more restricted solution is better.
Eg, use Walter's proposal ONLY if the static initializer is mixed in.
I should note that all static constructors in a module are combined
into one function. So, the mixin static initializers are combi
Don wrote:
If that's true, then perhaps a more restricted solution is better.
Eg, use Walter's proposal ONLY if the static initializer is mixed in.
I should note that all static constructors in a module are combined into
one function. So, the mixin static initializers are combined with any
ot
BCS wrote:
Random thought: Aside from making a new corner case, why not make static
constructors in mixins only depend on imports from where they are
defined rather than where they are used?
Template mixins are intended to behave like macros - they are
instantiated in the context of where th
Hello Walter,
Doing lazy initialization certainly works, but it would require all
static member access to go through a check for initialization, first.
The cost of this check persists for a statically compiled language;
for a JITted language like C# the access can be rewritten to remove
the chec
Hello Don,
If that's true, then perhaps a more restricted solution is better. Eg,
use Walter's proposal ONLY if the static initializer is mixed in.
Random thought: Aside from making a new corner case, why not make static
constructors in mixins only depend on imports from where they are define
Doing lazy initialization certainly works, but it would require all
static member access to go through a check for initialization, first.
The cost of this check persists for a statically compiled language; for
a JITted language like C# the access can be rewritten to remove the check.
On 12/03/10 16:44, Robert Clipsham wrote:
I don't know the full situation, or even if this will help, but maybe
something like the following could help?
a.d:
module a;
import b;
Foo fooA;
static this()
{
fooA = bar();
}
b.d:
module b;
import a;
class Foo { }
Foo bar()
{
return
On 12/03/10 02:42, Walter Bright wrote:
Currently, it is performed as a strictly "depth-first" traversal of the
graph defined by the import statements. As we've been discussing here,
this works great until one has circular imports, meaning the depth-first
graph has a loop in it.
The current beha
On 2010-03-12 15:05:25 +0100, Michel Fortin said:
[...]
Most mixins static constructors will probably have to be @cyclehead.
Here is an example of a reasonable use case to clarify why I think that
my proposal, or something like it is the correct solution.
Often the static initializers like t
On 2010-03-11 21:42:47 -0500, Walter Bright said:
Currently, it is performed as a strictly "depth-first" traversal of the
graph defined by the import statements. As we've been discussing here,
this works great until one has circular imports, meaning the
depth-first graph has a loop in it.
T
Fawzi Mohamed wrote:
On 12-mar-10, at 09:59, Don wrote:
BCS wrote:
Hello Walter,
2. If a loop is detected, rather than issuing an error message, simply
arbitrarily pick one order and continue constructing.
How about a way to explicitly cut edges in the graph (tagging imports
with "pragma(no
Walter Bright Wrote:
> I'm not happy with this solution, but it seems to be the best compromise
> I can come up with.
>
> What do you think?
The first thought that occurred to me was "how this was handled in other
languages". As C# is one of the more recent languages, and has some static
cons
On 3/12/10 03:42, Walter Bright wrote:
Currently, it is performed as a strictly "depth-first" traversal of the
graph defined by the import statements. As we've been discussing here,
this works great until one has circular imports, meaning the depth-first
graph has a loop in it.
The current behav
On 12-mar-10, at 09:59, Don wrote:
BCS wrote:
Hello Walter,
2. If a loop is detected, rather than issuing an error message,
simply
arbitrarily pick one order and continue constructing.
How about a way to explicitly cut edges in the graph (tagging
imports with "pragma(nodep)" or "@nodep" f
BCS wrote:
Hello Walter,
2. If a loop is detected, rather than issuing an error message, simply
arbitrarily pick one order and continue constructing.
How about a way to explicitly cut edges in the graph (tagging imports
with "pragma(nodep)" or "@nodep" for instance)? That has the same end
e
Andrei Alexandrescu wrote:
It looks like a step backwards to me.
Andrei
What solution do you propose for problem 1?
"Walter Bright" wrote in message
news:hnc9n2$2tk...@digitalmars.com...
> Currently, it is performed as a strictly "depth-first" traversal of the
> graph defined by the import statements. As we've been discussing here,
> this works great until one has circular imports, meaning the depth-first
On 03/11/2010 10:15 PM, Walter Bright wrote:
Ellery Newcomer wrote:
On 03/11/2010 08:42 PM, Walter Bright wrote:
2. Trying to analyze the static constructors to see what the
dependencies actually are is fraught with unsolvable problems.
could you elucidate on this point? Is it definitely im
Hello Walter,
2. If a loop is detected, rather than issuing an error message, simply
arbitrarily pick one order and continue constructing.
How about a way to explicitly cut edges in the graph (tagging imports with
"pragma(nodep)" or "@nodep" for instance)? That has the same end effect but
fo
On 03/11/2010 08:42 PM, Walter Bright wrote:
Currently, it is performed as a strictly "depth-first" traversal of the
graph defined by the import statements. As we've been discussing here,
this works great until one has circular imports, meaning the depth-first
graph has a loop in it.
The current
Ellery Newcomer wrote:
On 03/11/2010 08:42 PM, Walter Bright wrote:
2. Trying to analyze the static constructors to see what the
dependencies actually are is fraught with unsolvable problems.
could you elucidate on this point? Is it definitely impossible to get a
hold of a complete dag, eve
On 03/11/2010 08:42 PM, Walter Bright wrote:
2. Trying to analyze the static constructors to see what the
dependencies actually are is fraught with unsolvable problems.
could you elucidate on this point? Is it definitely impossible to get a
hold of a complete dag, even if at runtime?
Walter Bright:
> 1. Attempt the depth-first traversal of the static constructors.
> 2. If a loop is detected, rather than issuing an error message, simply
> arbitrarily pick one order and continue constructing.
Some alternative possibilities:
- Issue a warning too?
- Or allow that only if the cod
Currently, it is performed as a strictly "depth-first" traversal of the
graph defined by the import statements. As we've been discussing here,
this works great until one has circular imports, meaning the depth-first
graph has a loop in it.
The current behavior on detecting a loop is to quit wi
40 matches
Mail list logo
