lambda vs fn

[gilch]

One of the subissues from #240.

They're not quite the same, but still too similar to need both. Hy's lambda will use a Python lambda if it can. When it can't, because there's a statement or multiple lines, it acts exactly the same as fn. I don't know about Hy, but Python mostly doesn't care to distinguish lambdas from ordinary function objects. You can even set lambdas as methods for classes.

I'm in favor of keeping lambda and removing fn. If there actually is a case where you need a one-expression function and can't use a Python lambda, then you can force a Hy lambda to be a function simply by adding a docstring.

If we're OK with not reserving Python keywords as discussed in #899, then after dropping fn we can rename lambda to fn to keep the shorter alias. Then Hy would treat lambda like any other symbol. This may be problematic for Python interop, but there are workarounds.

[gilch]

Alternative proposal:
Make lambda different enough from fn to be worth another keyword

Just filling up a keyword quota is not good language design. But I already had a good suggestion for this for #739: Require explicit (return ...) expressions in fn, but use automatic tail returns in lambda. This is how Python does it anyway, so it's not confusing. To be clear, multiline lambdas would still have to translate to "anonymous" Python functions, in which case the return is inserted automatically at the tails, as now.

We would also add a deflambda form as defn would now require explicit (return ...). This is actually advantageous for class definitions, because we would no longer need to remember to put nils in every tail position for defn --init-- and defn --new--. Python automatically returns None if you don't return anything else.

This would also probably make #876 easier to implement, or at least make py2hy translations easier to do by hand.

[gilch]

If deflambda is too long, we could just call it def. setv already does the same thing anyway, so this will clean up another redundant keyword.