3 ms·

He's practically the poster boy for Sufficiently Smart Compiler cheerleading, but he despises the most useful real-world example? And he's in the middle of a bl

by blasdel 17y ago

He's practically the poster boy for Sufficiently Smart Compiler cheerleading, but he despises the most useful real-world example? And he's in the middle of a blog series about how awesome auto-parallelization will be? How is observable nondeterminism not a much bigger lie than TCO? If you like Clojure's recur but find its syntacticalness distasteful, and clueful compilers abhorrent, the Y Combinator is exactly what you want.

jasonwatkinspdx 17y ago
I like Joy's recursion primitives for much the same reason, and particularly since they make various patterns (ie binary recursion) explicit.
bad_user 17y ago
I don't know much about Tim Bray, and I don't usually read its articles. But this argument is OK. Having a smart compiler is one thing ... but a tail-call is not a simple optimization that speeds up your software. And personally I haven't seen a "sufficiently smart compiler" that does a reasonable job ... Haskell's GHC does a pretty good job, but without having internal knowledge the results are often horrible. When you modify your function and accidentally move the call such that it's no longer in a tail position (and this one does happen) that function may not run anymore. Engineers relying on tail-calls end up looking at the generated bytecode/assembler to ensure that it's really a tail-call, otherwise the software crashes. That's why a tail-call should be explicit. Because you're relying on it for the computation to complete. It's not for speed, it's for correctness, and with implicit tail-calls you are effectively trading one kind of accidental complexity for another.
- silentbicycle 17y ago
  Is it really that hard to tell whether or not a call is in a tail position? It's like type inference - it has a major impact on what kind of code is idiomatic, and if you know the language, you'll need to understand it. Still, TCO is a lot less complicated than pointers or all of the conceptual baggage necessary to design OO class hierarchies well.
  - jimbokun 17y ago
    "Is it really that hard to tell whether or not a call is in a tail position?" It is easy to forget when you are focusing on the logic of the code, and easy to change accidentally. Clojure explicitly tells you when you are trying to recur from a non-tail position, which is rather nice, and not possible with implicit tail call optimization (how do you know if the programmer really wanted a tail call or not?). Having the compiler catch your mistakes is always nice.

by blasdel 17y ago

jasonwatkinspdx 17y ago

I like Joy's recursion primitives for much the same reason, and particularly since they make various patterns (ie binary recursion) explicit.

bad_user 17y ago

I don't know much about Tim Bray, and I don't usually read its articles. But this argument is OK. Having a smart compiler is one thing ... but a tail-call is not a simple optimization that speeds up your software. And personally I haven't seen a "sufficiently smart compiler" that does a reasonable job ... Haskell's GHC does a pretty good job, but without having internal knowledge the results are often horrible. When you modify your function and accidentally move the call such that it's no longer in a tail position (and this one does happen) that function may not run anymore. Engineers relying on tail-calls end up looking at the generated bytecode/assembler to ensure that it's really a tail-call, otherwise the software crashes. That's why a tail-call should be explicit. Because you're relying on it for the computation to complete. It's not for speed, it's for correctness, and with implicit tail-calls you are effectively trading one kind of accidental complexity for another.

silentbicycle 17y ago
Is it really that hard to tell whether or not a call is in a tail position? It's like type inference - it has a major impact on what kind of code is idiomatic, and if you know the language, you'll need to understand it. Still, TCO is a lot less complicated than pointers or all of the conceptual baggage necessary to design OO class hierarchies well.
- jimbokun 17y ago
  "Is it really that hard to tell whether or not a call is in a tail position?" It is easy to forget when you are focusing on the logic of the code, and easy to change accidentally. Clojure explicitly tells you when you are trying to recur from a non-tail position, which is rather nice, and not possible with implicit tail call optimization (how do you know if the programmer really wanted a tail call or not?). Having the compiler catch your mistakes is always nice.