in variable initialization, dependencies within functions are not recursively resolved about gno HOT 7 OPEN

This bug exists because gnovm's "compilation" unit is a file and the Go compiler's compilation unit is a package.
If the dependency graph i wrote would be used, the ast' of all files within a package must be merged and then preprocessed.

After a conversation @jaekwon , we will wait for his evaluation of the problem and reach a conclusion if the graph would be used or not.

from gno.

This bug exists because gnovm's "compilation" unit is a file and the Go compiler's compilation unit is a package.

This is not true, predefineNow is perfectly capable of resolving dependencies on names declared in other files.

from gno.

This bug exists because gnovm's "compilation" unit is a file and the Go compiler's compilation unit is a package.

This is not true, predefineNow is perfectly capable of resolving dependencies on names declared in other files.

this is not what i meant.

from gno.

This bug exists because gnovm's "compilation" unit is a file and the Go compiler's compilation unit is a package.

This is not true, predefineNow is perfectly capable of resolving dependencies on names declared in other files.

predefineNow might be able to do many things but it doesn't change the fact that the unit of processing is a file.

from gno.

predefineNow might be able to do many things but it doesn't change the fact that the unit of processing is a file.

By "unit of processing is a file", what I understand is that the implementation of the language is considering the individual file rather than the package, especially when resolving dependencies for names. The obvious example of a language that does this is C, which requires you to import header files for anything else you want to import.

Go, and Gno by extension, are not like this and will support referencing names within the same package. This is a feature of both languages that exists and is implemented; albeit the Gno implementation is undoubtedly still with many more bugs.

Of course, there is one notable exception and that is that package imports are scoped within the file they are declared. For this reason, it is still important for the implementation both in Go and in Gno to keep track of individual files, as they have different imports and as such can have different sets of "global" identifiers.

The fact that the GnoVM processes the package by iterating over each file is not behaviour specific to the GnoVM, inconsistent with what there is in Go. The Go implementation still very much works on individual files deep into the compiling process. Here's an example in the type checker, here's an example in the "noder" (converter to IR)

So, no, as far as I'm concerned, the problem is not architectural as you claim, ie. us having a "file" compilation unit while Go having a "package" compilation unit.

from gno.

predefineNow might be able to do many things but it doesn't change the fact that the unit of processing is a file.

By "unit of processing is a file", what I understand is that the implementation of the language is considering the individual file rather than the package, especially when resolving dependencies for names. The obvious example of a language that does this is C, which requires you to import header files for anything else you want to import.

Go, and Gno by extension, are not like this and will support referencing names within the same package. This is a feature of both languages that exists and is implemented; albeit the Gno implementation is undoubtedly still with many more bugs.

Of course, there is one notable exception and that is that package imports are scoped within the file they are declared. For this reason, it is still important for the implementation both in Go and in Gno to keep track of individual files, as they have different imports and as such can have different sets of "global" identifiers.

The fact that the GnoVM processes the package by iterating over each file is not behaviour specific to the GnoVM, inconsistent with what there is in Go. The Go implementation still very much works on individual files deep into the compiling process. Here's an example in the type checker, here's an example in the "noder" (converter to IR)

So, no, as far as I'm concerned, the problem is not architectural as you claim, ie. us having a "file" compilation unit while Go having a "package" compilation unit.

This is unralated in 2 different ways, at least.
We are not talking about type checking or code generation and my original comment should be taken into the context of the way my PR solves the problem of the issue.
Since you opened this issue and seem to disagree with that solution, i've assigned it to you.

from gno.

predefineNow might be able to do many things but it doesn't change the fact that the unit of processing is a file.

By "unit of processing is a file", what I understand is that the implementation of the language is considering the individual file rather than the package, especially when resolving dependencies for names. The obvious example of a language that does this is C, which requires you to import header files for anything else you want to import.

Go, and Gno by extension, are not like this and will support referencing names within the same package. This is a feature of both languages that exists and is implemented; albeit the Gno implementation is undoubtedly still with many more bugs.

Of course, there is one notable exception and that is that package imports are scoped within the file they are declared. For this reason, it is still important for the implementation both in Go and in Gno to keep track of individual files, as they have different imports and as such can have different sets of "global" identifiers.

The fact that the GnoVM processes the package by iterating over each file is not behaviour specific to the GnoVM, inconsistent with what there is in Go. The Go implementation still very much works on individual files deep into the compiling process. Here's an example in the type checker, here's an example in the "noder" (converter to IR)

So, no, as far as I'm concerned, the problem is not architectural as you claim, ie. us having a "file" compilation unit while Go having a "package" compilation unit.

https://github.com/golang/go/blob/a63907808d14679c723e566cb83acc76fc8cafc2/src/cmd/compile/internal/types2/initorder.go#L15

this is where all package level variables are collected.

	// Compute the object dependency graph and initialize
	// a priority queue with the list of graph nodes.
	pq := nodeQueue(dependencyGraph(check.objMap))

from gno.