For those unaware, the transformation is roughly:
(let ((foo bar) ...) Y) -> ((lambda (foo ...) Y) bar ...)
Reading around it seems that it breaks several pythonic control-transfer functions that treat functions specially (e.g. yield from inside a let would be surprising).
Without knowing much about Hy's semantics, it should still be doable by rewriting variable names. That's likely not doable in a robust manner via a macro though, so would have to be part of Hy's transformation from sexpr to ASTs.
I think it really comes down to python having limited scoping capabilities (I think you can only really make new scopes with function declarations), this can maybe be hacked around, but at too high a performance cost to be usable.
In short, let kept running into trouble with yield, exceptions, breaking out of loops and such. It would have been really tricky (probably close to impossible) to get everything working correctly.
I gather that the main remaining problem is that break, continue, yield, async, await work differently if you covertly introduce a new function scope. Would it be sufficient if scopes could have explicit labels and break, continue, yield took an argument that said which label to break/continue/yield out of? Would that solve the problem with async, await too?
If Hy did extensive code analysis to determine where to introduce 'nonlocal', and if Python's break/continue/yield took this extra argument, would implementation of 'let' by Hy then become possible or are there still additional impediments that i am missing?
(let ((a 3)
(b 5)
(c -1))
(* a (+ b c)))
def «gensym»(a,b,c):
return (a * (b + c))
«the-gensym»(3,5,-1)
Can you give an example of code that is improved by let significantly? ...and can't be rewritten in a more readable way without it?
Any piece of code that uses a variable.
But.. do you really prefer to write huge functions instead of smaller ones?
Also: I think Python's default args being evaluated at function definition time kills the need for the usage of let when defining closures inside loops (you can just pas the value you want to capture in a closure as the default value of a param) or other things like that.
That’s true. I revise my comment as "Any piece of code that uses a variable[ to hold something you use multiple times and don’t want to recompute]."; for example creating an API client then using it twice.
Probably I'm a bit too stuck on "the python way" on this clash-of-cultures to see such cases that are clearly part of "the lisp way"...
"Let" is one of the most important special operators in Lisp. It allows you to create lexical variables within an s-expression.
Roughly equivalent to creating local variables within a block (in other languages).
So i'd claim it is essential.
(defun udpate ()
(let ((pos (find-char-pos)))
(move-char pos))
(print (stats))
(rotate enemies))
(defun udpate ()
(set 'pos (find-char-pos))
(move-char pos)
(print (stats))
(rotate enemies))
(1) feel more drawn to "Flat is better than nested." from "Zen of Python" to dislike the extra scoping level despite the conceptual clarity it provides (because I'm sure some "idiot" will abuse it and I'll end up reading a 10 nested let-s monstrosity pretty soon)
(2) like to write small functions, so forever will always be "~10 loc max" for me
...so imho if you're used to "thinking in classic Lisps" you'll miss let, otherwise you won't. What I'd miss for example would be some Haskell-like where (https://wiki.haskell.org/Let_vs._Where#Advantages_of_where) but I'd wake quickly out of it since it would make no sense to someone not already "stuck in Haskell-like thinking mode".
(defun udpate ()
(ag-if (find-char-pos)
(move-char it))
(print (stats))
(rotate enemies))