Right, and I agree with that. I prefer = over define.
The problem comes when everything is "inlined".
(def color (r g b)
(with (c (table)
f (fn (x) (if (< x 0) 0 (> x 255) 255 x)))
(= (c 'r) (f r) (c 'g) (f g) (c 'b) (f b))
c))
This is the first thing in html.arc
I can't make sense of it, it's way too terse.
This is probably why python doesn't have a proper lambda expression.
EDIT:
After some pondering, I see what it does ..
An equally terse implementation in python:
def limit(n, lower, upper):
if n < lower: return lower
if n > upper: return upper
return n
def color(*args):
return dict(zip("rgb", [limit(c, 0, 255) for c in args]))
>>> color(10, 20, 30)
{'r': 10, 'b': 30, 'g': 20}
This is a lot clearer, without sacrificing conciseness:
def color(*args):
rgb_values = [limit(c, 0, 255) for c in args]
return dict(zip("rgb", rgb_values))
By simply getting the inlined list comprehension outside the dict expression, the whole thing becomes 10 times easier to read: "Ah, it's mapping 'rgb' characters to rgb values."
Comments
Right, and I agree with that. I prefer = over define.
The problem comes when everything is "inlined".
This is the first thing in html.arcI can't make sense of it, it's way too terse.
This is probably why python doesn't have a proper lambda expression.
EDIT:
After some pondering, I see what it does ..
An equally terse implementation in python:
This is a lot clearer, without sacrificing conciseness: By simply getting the inlined list comprehension outside the dict expression, the whole thing becomes 10 times easier to read: "Ah, it's mapping 'rgb' characters to rgb values."