Tail Call Optimization Proposals
Opened this issue · 5 comments
Hello l3x,
I'm currently reading your book. How do I know whether I have the draft or the latest version?
The first thing I learned from your book is the importance of getting TCO support into
the golang compiler in order for go to become a great functional programming language.
Unfortunately the github proposal you referenced at the end of the book has been closed
for outsiders on the project. If that wasn't the case, I would've written a comment there.
Theoretically this is only an implementation detail of the compiler and not something that
would've to exist in the language specification. A person or group skilled in compiler
development could develop a patch to add TCO support to the go compiler.
I'm not sure if Rob Pike and the go team will decide in favor of either implicit TCO
optimization or a keyword like become or goto. It's making my head shake that some
people argued against the proposal on the grounds of keeping the language simple,
when recursion is something natural and intuitive for anyone who understands math
or has done more than rudimentary programming in his life. Actually nobody is arguing
against recursion, which the language obviously has, they are arguing against making
a crucial optimization for it.
Hopefully your book is getting wide-spread in the go community, because people have to
know that this paradigm is worth some extra attention.
Please tell me how I can support TCO in golang now that the proposal is closed.
In the worst case scenario Rob Pike will decide against it, but I think this wouldn't have
to be the last word due to the nature of this being an implementation detail. We'd need
some experienced compiler developers, maybe even a crowdfunding campaign and we
could fund and maintain a patch set for go, that adds TCO support.
Hi Tobi,
I'll do my best to answer your questions:
How do I know whether I have the draft or the latest version?
If you see my photo in the About the Author section, then you have the latest version. (It's not perfect, I found an error or two when preparing for this presentation: https://www.youtube.com/watch?v=HRrP_P0PwFU ... but it's much better than the draft version of my book that was originally published ;-)
Please tell me how I can support TCO in golang now that the proposal is closed.
I suppose the best way it to open a new proposal and word it slightly differently.
This outlines the process: https://github.com/golang/proposal
What that will do is get the issue in front of key decision makers like Peter Bourgon.
Here's a fairly recent tweet that I responded to regarding Generics and how I think TCO is IMHO more valuable (and would be must less costly to implement than Generics):
https://twitter.com/peterbourgon/status/1034556871049240576
For whatever reason, emotions run high when it comes to Go and Functional Programming.
I recently discovered that the reviewers at O'Reilly are especially hateful in this regard:
https://www.oreilly.com/library/view/learning-functional-programming/9781787281394/
UPDATE: I just looked up that page and it looks like O'Reilly disabled our ability to see the comments or add one. It's just stuck at 3 stars. But from I recall, the first three comments were 1's. Two anonymous readers left no comment. The other literally said, "There is no place for a book like this [on Functional Programming] with Go."
Keep the faith and shy away from those negative emotions. You know what they say about attracting bees, right?
p.s. The best way to fight negativity is with positivity. Any positive support/book review for Learning Functional Programming in Go would be most appreciated :-)
Feel free to leave a review here:
https://www.amazon.com/Learning-Functional-Programming-applications-programming-ebook/dp/B0725B8MYW
or here:
https://www.packtpub.com/application-development/learning-functional-programming-go
Thanks!
Lex
@l3x
So it seems I've the latest version of the book. Even though I've only read a small fraction, I've found a sizeable number of errors. (Nothing that would make me hate the book, though)
You should really read your own book as though you had bought it yourself and I'm convinced you'd find the same errors that I saw. I wasn't ready to mark the errors in the book, because I think it's sad to scribble inside a book. I might start a separate error list, if I'm not too lazy.
My point is, that you put so much effort into this, and therefore you should definitely continue to revise your book and publish new editions.
You didn't comment on my idea of maintaining a patch set that enables TCO.
I don't see why people would hate on the idea of functional programming with go. Obviously it's not a pure functional programming language, but it is a multiparadigm language and has support for important functional programming elements.
Your comment: A person or group skilled in compiler development could develop a patch to add TCO support to the go compiler.
Agreed. Excellent point. Then, best case, the Go dev team would see people care enough to patch the compiler and then maybe they'd include it in Go 2.0 :-)
BTW - I updated the goenv utility to run on linux. Run this to see that Go 2.0 is not yet released: goenv list-available-versions
You should really read your own book as though you had bought it yourself and I'm convinced you'd find the same errors that I saw. I wasn't ready to mark the errors in the book, because I think it's sad to scribble inside a book. I might start a separate error list, if I'm not too lazy.
Agreed. Long story there. Bottom line: Even though I cranked this book out in 11 months, the publisher rushed it to the presses before any reasonable draft correction effort had been made.
If I had any say at at all into the publishing process I would have taken about 2 more months to fix typos and perfect its content. As it stands, I'm still proud of what I produced, especially considering the circumstances. I hope you find my book valuable, despite your extra scribble/correction efforts.
If you send me your scribbles/corrections I'll format them and put up a new "Book Corrections" page at http://lexsheehan.blogspot.com/ and give you the deserved credit for your efforts.
p.s. Here's a link to the goenv utility: https://github.com/l3x/goenv
@l3x hey glad i found this issue because i stumbled on your book randomly today and was so excited to see it. I come from a Haskell/Scala background but recently flip flopped in completely the opposite direction by joining a team doing Golang at a company where there's effectively no functional programming culture (well thats not entirely true. There are some guys like me who sneak it 😄 into our Kotlin codebases (which we have many) but I'm not currently working anywhere even near teams owning Kotlin services) and so really wanted to find literature on FP in Go cause I miss it dearly at this point but definitely did not expect to find a whole book. So thanks a bunch!
Anyway why I said I'm glad I found this issue:
You cite this function in the book:
as being tail recursive and I usually just bang my head against the wall until I realize my own mistake when I read programming books, because exceedingly rarely is the mistake actually in the book in not in my thinking. I think this could be one of those cases though. Did you mean something like this rather? :func Sum(vs []int) int {
return sumTailCall(vs, 0)
}
func sumTailCall(vs []int, sum int) int {
if len(vs) == 0 {
return sum
}
return sumTailCall(vs[1:], sum + vs[0])
}Thank you so much again for writing this!