Consider a chain of functions that call each other:
func f1(x X) { ... f2(y) ... }
func f2(y Y) { ... f3(z) ... }
and so on.
Assume also that their arguments and return values are static Go types (no
interfaces).
Generally, such a chain of statically-typed invocations will fall within
the domain of the SSA optimizer and will be rewritten (theoretically)
optimally.
The issue arises when the invocation chain is recursive, e.g.
func f1(x X) { ... f2(y) ... }
func f2(y Y) { ... f3(z) ... }
func f3(z Z) { ... f1(x) ... }
and the user desires to implement f1 and f3 in different packages.
This is not possible due to the design of the packaging system (as the
packages of f1 and f3 would have to import each other).
Consequently, large amounts of recursive code cannot be spread across
packages.
This situation has arisen in practice for us at a pretty large scale
(many/long recursive chains).
I am wondering a couple of things:
(a) Is there any technical consideration prohibiting large-scale SSA,
(b) Is there any technical consideration prohibiting go packages from
importing each other.
Thank you.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
