You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I don't think there is any context where this suggestion makes sense: or is not a function and cannot be passed as one. And if it's used as a head of an expression (like (#(or %1 %2) (something 1) (something 2))), then it changes the semantics by adding short circuiting.
So I think eta-reduction should not be suggested for macros at all. It's really hard to prove that the macro works the same way in eta expanded and reducted form, and chances are slim that someone wrote it in the harder way by accident.
The text was updated successfully, but these errors were encountered:
Kibit is run form-by-form with no tracking of variable state. We can't know which forms are macros (except for the built-in ones). We could potentially exclude those. Would that be acceptable?
definitely! I'm happy for whatever improvement there might be, and most of the exclude-able cases are builtin well known macros anyway, because it's extremely unlikely anyone would need to turn a self made macro into a function by eta expanding it.
Kibit 0.1.8 makes this suggestion:
I don't think there is any context where this suggestion makes sense:
or
is not a function and cannot be passed as one. And if it's used as a head of an expression (like(#(or %1 %2) (something 1) (something 2))
), then it changes the semantics by adding short circuiting.So I think eta-reduction should not be suggested for macros at all. It's really hard to prove that the macro works the same way in eta expanded and reducted form, and chances are slim that someone wrote it in the harder way by accident.
The text was updated successfully, but these errors were encountered: