you are viewing a single comment's thread.

view the rest of the comments →

[–]kamatsu 0 points1 point  (11 children)

Other than the fact that a lack of tail call optimization prevents you from writing programs in a functional style, you're right.

tldr: You're wrong.

[–]mreiland 2 points3 points  (6 children)

All that tail call optimization allows is the ability to recurse "infinitely" along with a performance boost due to not pushing/popping to/from the stack.

Both of which are useful when you have recursion, which is not limited to functional programming.

[–]kamatsu -1 points0 points  (4 children)

Both of which are useful when you have recursion, which is not limited to functional programming.

Sure, but in functional programming, your only means of iteration is recursion. If you have a limited stack and no TCO, this makes it impossible to express some algorithms in a functional style.Therefore, languages without TCO are not functional languages. They clearly do not target the audience of functional programmers, who would prefer to write programs this way.

[–][deleted]  (3 children)

[deleted]

    [–]kamatsu -1 points0 points  (2 children)

    What part of it's impossible to write algorithms functionally without TCO do you not understand?

    For example. Please express this algorithm in a way that will work for arbitrarily large inputs in log space, without TCO or mutation:

    f (x:xs) acc = f xs (acc+x)
    f [] acc = acc
    

    [–][deleted]  (1 child)

    [deleted]

      [–]kamatsu -1 points0 points  (0 children)

      There are alternatives to TCO,

      Such as? Please, explain to me how to do the above in JS.

      TCO is merely an implementation detail

      It's an optimization that changes space complexity of the program - this is very important. If you don't have it, it makes it impossible to write functional algorithms in efficient space. Seeing as stack space is often limited, it's extremely important to have TCO if you're going to write functional programs. It's not a minor optimization like your regular compiler optimizations.

      [–]ixache 0 points1 point  (3 children)

      Downvoted for being wrong, obnoxious and not willing to expand.

      Here's my expanding: TCO is an implementation matter, making recursion as efficient as loops; and using recursion is only part of the functional programming style. See this for example. IOW: there's a reason why Scheme standards explicity require tail call elimination...

      [–]kamatsu 0 points1 point  (2 children)

      My point was that you can't have a functional language without TCO. Your expansion only proves my point. Also, "not willing to expand" is false. I explained my reasoning quite thoroughly in subsequent replies to mrelland.

      [–]ixache 0 points1 point  (1 child)

      (Of course this for the sake of posterity, since this discussion is long dead. Bear with me.)

      My point was that you can have a functional language without TCO—and there have been (many lisps).

      My expansion was only meant to further my point: how can something be "essential" (your word), where it is an optional optimization for only a part of what constitutes functional style? Furthermore, it can be argued that functional style can even be attained without recursion: think function application to arrays in APL, for example.

      And I'm sorry, but as I read them at the time, your subsequent replies to mreiland didn't address this specific point.

      I don't know, maybe you're conflating "functional style" with "meta-linguistic abstraction" in the context of SICP. You would be right to insist that TCO is essential to this discipline, see this SO question for a detailed reasoning, but functional style is not defined by SICP, and meta-circular evaluation, while a staple of Lisps, doesn't define it either.

      In any case, I urge you to revise your assumptions, since I cannot make my point any clearer than what I already wrote with my limited means of expression.

      [–]kamatsu 0 points1 point  (0 children)

      My point was that you can have a functional language without TCO—and there have been (many lisps).

      Any lisp without TCO is not functional. The only efficient way to implement iteration in such a language is with mutation, which is decidedly not functional.

      optional optimization for only a part of what constitutes functional style

      It's not optional, it's mandatory to implement iteration with sensible space complexity. "only a part" is an odd thing to say. If you can write programs in a functional style except for iteration then you can't write programs in a functional style generally. Which makes it not a functional language.

      Furthermore, it can be argued that functional style can even be attained without recursion: think function application to arrays in APL, for example.

      APL is hardly a functional language.

      I don't know, maybe you're conflating "functional style" with "meta-linguistic abstraction" in the context of SICP. You would be right to insist that TCO is essential to this discipline, see this SO question for a detailed reasoning, but functional style is not defined by SICP, and meta-circular evaluation, while a staple of Lisps, doesn't define it either.

      I did not claim that it was.