On Sunday, November 12, 2017 at 12:13:11 PM UTC-5, Bakul Shah wrote:
>
> On Nov 11, 2017, at 5:33 AM, Petar Maymounkov <pet...@gmail.com
> <javascript:>> 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?
>
> No. Each individual call to the top-level processor go function
is a stateless/context-free transformation of the input.
State is represented as arguments to the function calls.
> 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.
This is an interesting observation. However, I don't require
tail recursion. The stack depth is controlled from our technology.
What I am interested in is optimization of chains and cycles of
static invocations. (This is different than tail recursion, I believe.)
> 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.
>
>
This approach (or equivalently using an interface) escapes from the SSA
semantic. (dynamic func pointers)
> > (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).
>
> Again: dynamic function values or interfaces break the SSA call chains. So
this does not resolve my problem
of exposing the chains to the compiler. It does resolve the mutual package
import problem though, I agree.
--
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.
