Earlier quoted context omitted.
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.
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 :)
Lisp-stick on a Python
61–70 of 170 posts
Re: Lisp-stick on a Python
#62Wonder why not syntax totally common lisp so one does not need to change with switch to turn on certain or full Hy features. It is a bit confusing this partially Python partial Common Lisp then throw in a “!” for defmarco …
Re: Lisp-stick on a Python
#63https://github.com/Calysto/calysto_scheme
It's not blazing fast, but it's Scheme -- not paren-y syntactic sugar around Python.
Re: Lisp-stick on a Python
#64I've been hearing claims my entire programming career about how Lisp is supposedly "superior" to mainstream programming languages, but I've never seen a concise code example that actually demonstrates this. For instance, it's easy to demonstrate how Rust is superior to C: Just show a short piece of code where an array is returned from a function. In C, this will involve raw pointers and manual memory management with…
I can, without restarting my program: 1. Gather assembly level profiling information 2. Redefine & recompile a function 3. Gather new assembly level profiling I can iterate dozens of times between #2 and #3 in the time of a single incremental production build in rust (debug builds are not useful for gathering profiling data). Generally speaking it takes less than a second to recompile and load a source file, and it c…
Re: Lisp-stick on a Python
#65See also PEP 638 – Syntactic Macros https://peps.python.org/pep-0638/
And I say that while I wished I could use macro several times in Python because the syntax was lacking.
Re: Lisp-stick on a Python
#66Earlier quoted context omitted.
I can, without restarting my program: 1. Gather assembly level profiling information 2. Redefine & recompile a function 3. Gather new assembly level profiling I can iterate dozens of times between #2 and #3 in the time of a single incremental production build in rust (debug builds are not useful for gathering profiling data). Generally speaking it takes less than a second to recompile and load a source file, and it c…
Doesn’t VS do that too though? Also if you’re talking about performance or memory profiling, why are you using a Lisp in the first place?
Also, C++ linkage, while far faster than rust isn't the fastest thing, and compilation can be slow too (particularly with the popularity of header-only libraries).
Re: Lisp-stick on a Python
#67I've been hearing claims my entire programming career about how Lisp is supposedly "superior" to mainstream programming languages, but I've never seen a concise code example that actually demonstrates this. For instance, it's easy to demonstrate how Rust is superior to C: Just show a short piece of code where an array is returned from a function. In C, this will involve raw pointers and manual memory management with…
(define (eval exp env)
(cond ((number? exp) exp)
((string? exp) exp)
((symbol? exp) (lookup exp env)
((eq? (car exp) 'quote) (cadr exp))
((eq? (car exp) 'lambda)
(list 'closure (cdr exp) env))
((eq? (car exp) 'cond) (eval-cond (cdr exp))
(else (apply
(eval (car exp) env)
(eval-list (cdr exp) env)))))
which uses a Lisp to define itself. This means roughly that if you understand enough Lisp to understand this program (and the little recursive offshoots like eval-cond), there is nothing else that you have to learn about Lisp. You officially have read the whole language reference and it is all down to libraries after that. Compare e.g. with trying to write Rust in Rust where I don't think it could be such a short program, so it takes years to feel like you fully understand Rust.Indirectly this also means that lisps are very close at hand for “I want to add a scripting language onto this thing but I don't want to, say, embed the whole Lua interpreter” and it allows you to store user programs in a JSON column, say. You also can adapt this to serialize environments so that you can send a read-only lexical closure from computer to computer, plenty of situations like that.
Aside from the most famous, you have things like this:
1. The heart of logic programming is also only about 50 lines of Scheme if you want to read that:
https://github.com/jasonhemann/microKanren/blob/master/micro...
2. Hygienic macros in Rust probably owe their existence to their appearance in Lisps.
C2 asks the same question here: https://wiki.c2.com/?LispShowOffExamples with answers like
3. The object model available in Common Lisp was more powerful than languages like Java/C++ because it had to fit into Lisp terms (“the art of the metaobject protocol” was the 1991 book that explained the more powerful substructure lurking underneath this object system), so a CL programmer could maybe use it to write a quick sort of aspect-oriented programming that would match your needs.
4. Over there a link shows how in 16 LOC you can implement a new domain-specific language to define and run finite state machines: http://www.findinglisp.com/blog/2004/06/automaton-cleanup.ht...
Re: Lisp-stick on a Python
#68Earlier quoted context omitted.
Doesn’t VS do that too though? Also if you’re talking about performance or memory profiling, why are you using a Lisp in the first place?
I haven't used VS in a decade, but you needed to restart your program after changing the code. Also, C++ linkage, while far faster than rust isn't the fastest thing, and compilation can be slow too (particularly with the popularity of header-only libraries).
Re: Lisp-stick on a Python
#69I've been hearing claims my entire programming career about how Lisp is supposedly "superior" to mainstream programming languages, but I've never seen a concise code example that actually demonstrates this. For instance, it's easy to demonstrate how Rust is superior to C: Just show a short piece of code where an array is returned from a function. In C, this will involve raw pointers and manual memory management with…
Re: Lisp-stick on a Python
#70Earlier quoted context omitted.
Doesn’t VS do that too though? Also if you’re talking about performance or memory profiling, why are you using a Lisp in the first place?
I haven't used VS in a decade, but you needed to restart your program after changing the code. Also, C++ linkage, while far faster than rust isn't the fastest thing, and compilation can be slow too (particularly with the popularity of header-only libraries).