Currently the path in an include specifier is resolved relative to the location of the include specifier. This makes it hard to "drop in" library code that uses include specifiers, because the location of the specifier may not be known by the author of the specifier. For example, a file that says include "../../foo/bar.fppi" must be two directories down from the start of the relative path foo/bar.fppi. But a user may want to put the file in a different place.
The proposal is as follows:
Add a new kind of symbol called a location symbol. For example
location L
Add a new location specifier for location symbols:
locate L at foo.fpp
In an include specifier, allow a location symbol to be specified. For example:
include L "bar/baz.fppi"
In item 1, L is the name of a location definition. To simplify the name resolution, location definitions may occur only at the top level (not inside a module or any other scoped construct). The name may be a qualified name, e.g., A.B.C, and the qualification is unrelated to the qualification implied by the nesting of scoped constructs. This approach is similar to Java and Scala package names.
In item 2, the location specifier says that the definition of location L is located in the file [absolute path]/foo.fpp, where [absolute path] is the absolute path of the directory containing the file containing the specifier.
In item 3, the include path bar/baz.fppi is relative to the location of the symbol L. The user can put the file with the include specifier anywhere; the location specifier for L will say where the root of the path bar/baz.fppi is. In the example in item 2, the root is [absolute path].
The at construct for instance definitions could work similarly:
instance i: C base id 0x100 at L "bar/baz.hpp"
To make the analysis deterministic, we can use the following algorithm:
While there are any include specifiers in the model
Non-recursively resolve all include specifiers that have no location specifier.
Resolve all uses of location specifier symbols.
Non-recursively resolve all include specifiers that have location specifiers.
For example, consider the following input:
File a.fpp: include b.fppi
File b.fppi: location L
File c.fpp: include L d.fppi
File d.fppi: Empty
We would resolve include b.fppi; then we would resolve the use of L in include L d.fppi; then we would resolve include L d.fppi.
An attempt to include a location specifier through another location specifier would fail. For example, this input would fail, because the symbols L and M would be undefined in step 2:
Currently the path in an include specifier is resolved relative to the location of the include specifier. This makes it hard to "drop in" library code that uses include specifiers, because the location of the specifier may not be known by the author of the specifier. For example, a file that says
include "../../foo/bar.fppi"must be two directories down from the start of the relative pathfoo/bar.fppi. But a user may want to put the file in a different place.The proposal is as follows:
Add a new kind of symbol called a location symbol. For example
Add a new location specifier for location symbols:
In an include specifier, allow a location symbol to be specified. For example:
In item 1,
Lis the name of a location definition. To simplify the name resolution, location definitions may occur only at the top level (not inside a module or any other scoped construct). The name may be a qualified name, e.g.,A.B.C, and the qualification is unrelated to the qualification implied by the nesting of scoped constructs. This approach is similar to Java and Scala package names.In item 2, the location specifier says that the definition of location
Lis located in the file[absolute path]/foo.fpp, where[absolute path]is the absolute path of the directory containing the file containing the specifier.In item 3, the include path
bar/baz.fppiis relative to the location of the symbolL. The user can put the file with the include specifier anywhere; the location specifier forLwill say where the root of the pathbar/baz.fppiis. In the example in item 2, the root is[absolute path].The
atconstruct for instance definitions could work similarly:To make the analysis deterministic, we can use the following algorithm:
includespecifiers in the modelincludespecifiers that have no location specifier.includespecifiers that have location specifiers.For example, consider the following input:
a.fpp:include b.fppib.fppi:location Lc.fpp:include L d.fppid.fppi: EmptyWe would resolve
include b.fppi; then we would resolve the use ofLininclude L d.fppi; then we would resolveinclude L d.fppi.An attempt to include a location specifier through another location specifier would fail. For example, this input would fail, because the symbols
LandMwould be undefined in step 2:a.fpp:include M b.fppib.fppi:location Lc.fpp:include L d.fppid.fppi:location M