-
Notifications
You must be signed in to change notification settings - Fork 371
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make fn
work like lambda
and remove lambda
#1228
Conversation
First thing to come to mind is that lambdas can't be decorated: => (defn double [func] (fn [x] (* (func x) 2)))
=> ((with-decorator double (fn [x] x)) 5)
File "<input>", line 1, column 2
((with-decorator double (fn [x] x)) 5)
^--------------------------------^
HyTypeError: b'Decorated a non-function' But without the changes, example works: (defn double [func] (fn [x] (* (func x) 2)))
=> ((with-decorator double (fn [x] x)) 5)
10
=> ((with-decorator double (lambda [x] x)) 5)
File "<input>", line 1, column 2
((with-decorator double (lambda [x] x)) 5)
^------------------------------------^
HyTypeError: b'Decorated a non-function' In my opinion, this is big enough drawback not to do this change. |
That could be implemented, but why would you write |
Point of the code was to show a simple testcase which will fail if this change is pulled in. Actual content of the example decorator isn't important. Currently user can be confident that result of |
My argument isn't specific to your test case. It applies no matter how complex the decorator or the decorated |
This feature is of dubious value by itself, but it's necessary to allow `defn` to create a lambda instead of a `def`.
That is, allow it to generate a `lambda` instead of a `def` statement if the function body is just an expression. I've removed two uses of with_decorator in hy.compiler because they'd require adding another case to HyASTCompiler.compile_decorate_expression and they have no ultimate effect, anyway. In a few tests, I've added a meaningless statement in `fn` bodies to force generation of a `def`. I've removed `test_fn_compiler_empty_function` rather than rewrite it because it seems like a pain to maintain and not very useful.
7dd54c5
to
604ec93
Compare
Right, now I follow. Shouldn't test things before second cup of coffee in morning. Indeed, following works as expected: => (defn double [func] (fn [x] (* (func x) 2)))
=> (with-decorator double (defn test [x] x))
=> (test 2)
4 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn't find any funny edge cases with quick testing, so this in general looks good to me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it be worth it to mention why the setv
change is needed in a bit more detail somewhere? At a glance, it just seems really confusing.
Like the commit message says, "it's necessary to allow |
So technically, supporting |
Or, putting it another way, the |
And that's commit 2,000. This calls for celebration! |
The bug was a regression that I introduced in hylang#1228. I've created a new special form named `fn*` that works like the old `fn` (that is, it always creates a FunctionDef). Since this is intended only for internal use, like `with*`, I haven't documented it.
The bug was a regression that I introduced in hylang#1228. I've created a new special form named `fn*` that works like the old `fn` (that is, it always creates a `FunctionDef`). Since this is intended only for internal use, like `with*`, I haven't documented it.
The bug was a regression that I introduced in #1228. I've created a new special form named `fn*` that works like the old `fn` (that is, it always creates a `FunctionDef`). Since this is intended only for internal use, like `with*`, I haven't documented it.
Closes #910.