On Nov 15, 3:19 am, John <
jwfmccl...@gmail.com> wrote:
> I would argue that "proper tail call" support is different from
> exceptions. We have had exceptions for over 35 years and I am not sure
> we really understand how to use them, so while I am a little
> disappointed not to have them, I appreciate the trepidation expressed
> in the language FAQ (and I am curious to see how far multi-value
> return gets us).
I would however argue that after 35 years, we understand how to use
them fine. The problem is who the heck understands how to implement
exception handling, in a way that would make every ones teeth chatter
eventually :-P. The way Go code handles errors IMHO is easier to
handle (and read) then using exceptions, and the only real bonus
offered by exceptions are for recoverables that would other wise cause
a program crash; just take a look at Python.
Tail calls are way more interesting subject matter then exceptions,
and TCO less likely to complicate Go's internals, even half as much as
adding exceptions would. Not to mention there is no need to break
source compatibility to add TCO to the language.
Tail call optimisation and being able to do tail recursion without
*eventually* pushing your stack out the window, are not quite
synonymous but often make great bed fellows. There are surely ways of
implementing tail recursion like Scheme, but without paying much
penalty on regular function returns. TCO is arguably less brain-
busting then some of the optimisation tricks you'll find in the
compiler field, and the math might not strangle the rest of us :-P.
Recursive tail calls should also be as understood (by most) just as
easily as looping or recursion in general, although implementing that
feature might (and should likely) be unimportant right now. It would
be great to have in the long run.
Maybe I'm just a freak, that sees little difference between if+goto,
looping, and function calls, as long as the code yields the same
computation. I've often had to write iterative solutions to avoid
recursive edge cases, due to language implementations.
--
TerryP
Just Another Computer Geek