6 ms·

> Also, Python is the worst imaginable engine for running Lisp What exactly do you mean by this?

by funklute 4y ago

giantdude 4y ago
slow. bloated. not particularly good at managing conses. is there tail recursion?
- xapata 4y ago
  No, Python does not have tail recursion optimization, because Guido decided that he wanted to preserve stack frames for better tracebacks. The language team may revisit that decision someday. I assume you're referring to an optimization, because one can write tail recursion in any language that supports subroutines.
  - giantdude 4y ago
    Thanks, that is what I thought, but didn't trust my memory. Yes, I did mean optimization - without it you can blow through your stack quickly (and the traceback will be long and redundant :)
    - aidenn0 4y ago
      Common lisp doesn't require tail call elimination either, fwiw
      - bjoli 4y ago
        But every implementation except clisp, ECL and clisp do it reliably.
        tmtvl 4y ago
        I think you may have meant to substitute ABCL for one of those clisps?
        aidenn0 4y ago
        sbcl doesn't always do it, depending on optimization settings, and clisp does do it when compiling; by "reliably" perhaps you meant "by default"?
    - xapata 4y ago
      In those cases, you may wish to use a dynamic programming technique. A bit of caching might be a greater optimization than tail call elimination. The `@functools.lru_cache` tool is very easy to experiment with.
    - xapata 4y ago
      > will be long and redundant They made a highly redundant traceback display much more pleasant a couple years ago, writing "the same thing 1,998 more times ..." or something like that.
  - Jtsummers 4y ago
    > because one can write tail recursion in any language that supports subroutines. If only! For anyone else who got saddled with some FORTRAN 77 code, you may or may not have recursion available even with subroutines. It wasn't required by the language standard, but some implementations supported it. Not the one I "got" to use (and quickly moved on from) a while back, though.

> Also, Python is the worst imaginable engine for running Lisp What exactly do you mean by this?

giantdude 4y ago

slow. bloated. not particularly good at managing conses. is there tail recursion?

xapata 4y ago
No, Python does not have tail recursion optimization, because Guido decided that he wanted to preserve stack frames for better tracebacks. The language team may revisit that decision someday. I assume you're referring to an optimization, because one can write tail recursion in any language that supports subroutines.
- giantdude 4y ago
  Thanks, that is what I thought, but didn't trust my memory. Yes, I did mean optimization - without it you can blow through your stack quickly (and the traceback will be long and redundant :)
  - aidenn0 4y ago
    Common lisp doesn't require tail call elimination either, fwiw
    - bjoli 4y ago
      But every implementation except clisp, ECL and clisp do it reliably.
      - tmtvl 4y ago
        I think you may have meant to substitute ABCL for one of those clisps?
      - aidenn0 4y ago
        sbcl doesn't always do it, depending on optimization settings, and clisp does do it when compiling; by "reliably" perhaps you meant "by default"?
  - xapata 4y ago
    In those cases, you may wish to use a dynamic programming technique. A bit of caching might be a greater optimization than tail call elimination. The `@functools.lru_cache` tool is very easy to experiment with.
  - xapata 4y ago
    > will be long and redundant They made a highly redundant traceback display much more pleasant a couple years ago, writing "the same thing 1,998 more times ..." or something like that.
- Jtsummers 4y ago
  > because one can write tail recursion in any language that supports subroutines. If only! For anyone else who got saddled with some FORTRAN 77 code, you may or may not have recursion available even with subroutines. It wasn't required by the language standard, but some implementations supported it. Not the one I "got" to use (and quickly moved on from) a while back, though.