On Nov 11, 2017, at 5:33 AM, Petar Maymounkov <pet...@gmail.com> wrote:
>
> 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) ... }
Are you building a state-machine?
Looks like what you really want is tail-call optimization....
I don't think Go implements this. I tested this with two
mutually recursive functions and the program ran out of stack
space. IMHO you are better off using another language or a
different scheme. For example, each function returns a
function and its args as a struct to a driver routine.
func f1(x X)(Fn, Arg) { ... return f2, &Arg{y} ... }
A driver (much like an interpreter main loop) based approch
will be somewhat slower.
> (b) Is there any technical consideration prohibiting go packages from
> importing each other.
When I needed this I defined a common package that declared a
table and common types. Then each individual package added
its own entries to this table via their init() function. The
table can be a map or an array (in the latter case you'd have
to define a constant for each package globally, which makes it
less flexible).
--
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.
