in variable initialization, dependencies within functions are not recursively resolved

[thehowl]

This works:

package main

func main() {

}

func hello(s string) {}

var myDep string

var cmplx = func() { hello(myDep) }

But this doesn't:

package main

func main() {

}

func hello(s string) {}

var myVar = func() { hello(myDep) }

var myDep string

// panic: main/a.gno:9: name myDep not declared

EDIT: After #1854, this is still an issue, you just need to spleet it in different files.

// a.gno
package main

func main() {
	myDep = "123"
	myVar()
}

func hello(s string) {
	println(s)
}

var myVar = func() { hello(myDep) }

// b.gno
package main

var myDep string

[petar-dambovaliev]

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.

[thehowl]

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.

[petar-dambovaliev]

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.

[petar-dambovaliev]

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.

[thehowl]

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.

[petar-dambovaliev]

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.

[petar-dambovaliev]

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