Hi,
Thanks for following up here.
On Sunday, 12 November 2017 03:35:27 UTC+11, Petar Maymounkov wrote:
>
> 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.
>
What do these functions do? Can how show some working examples? What do you
mean by rewritten?
>
> 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,
>
There are lots of phases in the compiler, SSA occurs relatively late in the
process, and the one that's probably more relevant here is inlining.
Inlining does work across package boundaries, exported functions from one
package aren't supposed to be treated differently from functions in
another, although there could always be a bug. This is where a practical
example of what problem you're facing would be really helpful.
> (b) Is there any technical consideration prohibiting go packages from
> importing each other.
>
The prohibition on import loops exists because it would significantly
complicate the type checking of the compiler and the package import/export
mechanism. it's also just not a good idea from a program design point of
view as circular imports often denote high coupling which limit isolation
and effective code reuse.
>
>
> 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.
