Tail call optimization

[JONNALAGADDA Srinivas]

        While on the topic of optimization, could the Go team comment on the plans for tail call optimization (or at least tail recursion optimization), if any?  Thanks.

                                                            Greetings,

                                                                    JS

[Ostsol]

http://groups.google.com/group/golang-nuts/browse_frm/thread/d282193c786b0f36/80ee39c7ecb6150f

-Daniel

[JONNALAGADDA Srinivas]

        Thanks.  I had seen that over-a-year-old thread.  I was inquiring about the *current* plans.  By the way, the following consumes all available memory (and more) on most computers, even with the current release.

~ % cat j.go

package main

func foo(n int) {

foo(n)

}

func main() {

foo(42)

}

                                                            Greetings,

                                                                    JS

[Russ Cox]

On Sat, Feb 12, 2011 at 23:14, JONNALAGADDA Srinivas <sigm...@gmail.com> wrote:
>         While on the topic of optimization, could the Go team comment on the
> plans for tail call optimization (or at least tail recursion optimization),
> if any?

There are no such plans for gc (6g, 5g, 8g).
Personally, I find meaningful stack traces helpful more
often than I find myself using unbounded tail recursions.
I have on other projects used gcc -fno-optimize-sibling-calls
precisely to make stack traces more useful.

I think it's very unlikely that the language would require it.
Go is not Scheme.

Russ

[Ostsol]

On Feb 12, 10:03 pm, Russ Cox <r...@golang.org> wrote:

Oops! So that thread that I linked contains obsolete information?

-Daniel

[Evan Shaw]

On Sun, Feb 13, 2011 at 6:27 PM, Ostsol <ost...@gmail.com> wrote:
> Oops!  So that thread that I linked contains obsolete information?

Russ just confirmed that what Ian said in that old thread still
applies. There's nothing stopping a compiler from implementing tail
call optimization; it's just that the programmer shouldn't count on it
when writing code because it's not required by the spec. It doesn't
sound like that will change, either.

- Evan

[Erwin]

There are no such plans for gc (6g, 5g, 8g).
Personally, I find meaningful stack traces helpful more
often than I find myself using unbounded tail recursions.
I have on other projects used gcc -fno-optimize-sibling-calls
precisely to make stack traces more useful.

Wouldn't a gc -no-optimize mode be a good thing to have once optimizations get in the way of debugging?

[chris dollin]

If I'm assuming/relying on tail-call optimisation in my coding, then
turning it off "for debugging" will likely make my program crash
demanding more stack frames.

We all have our choices: I'd rather have guaranteed TCO than full
stack-frames for debugging, but I don't think it's unreasonable for
someone else to have the opposite preference.

Chris

--
Chris "allusive" Dollin

[Evan Shaw]

On Sun, Feb 13, 2011 at 11:34 PM, Erwin <snes...@gmail.com> wrote:
> Wouldn't a gc -no-optimize mode be a good thing to have once optimizations
> get in the way of debugging?

That option already exists as -N.

http://golang.org/cmd/gc/

- Evan

[Eoghan Sherry]

I found Newsqueak's become statement a nice fit for TCO in an
imperative setting.

func sum(a, b uint) uint {
if a == 0 {
return b
}
become sum(a-1, b+1)
}

Eoghan

[Sokolov Yura]

I'd prefer special keyword for tailcall too: those who really need tailcall will write it explicitely.

[Linker Lin]

become +1

TCO is very important for porting other FP lang to Go.

[Ian Lance Taylor]

On Tue, Mar 27, 2018 at 12:05 AM, Linker Lin <linker...@gmail.com> wrote:
> become +1
> TCO is very important for porting other FP lang to Go.

This is https://golang.org/issue/22624.

Ian

> --
> 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...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.