Hacker News Reader

Comment by waleedka | Hacker News Reader

The nice thing about Python is that it's intuitive and feels natural. To that end, this syntax for defining functions is nice, and I would love to see it implemented in native Python:

    f(x) = x^2 + 1

But most of the other ideas are less intuitive than their native counterparts. For example, I think that the native form:

    3 in [1,2,3,4,5]

is clearer than:

    [1,2,3,4,5] /contains/ 3

View on HN

Julia has this kind of syntax (among others) for functions.

Related to your first idea, Fortran had statement functions, and it didn't go very well in the end.

What went wrong with them in Fortran?

With the usual method of declaring a function, it was easy to understand that 'x' was local to the function. Adding a second, more concise way to express functions led to confusion about the scope of 'x'.

Also, declaring types for the function and arguments (which is optional but has been strongly recommended since the Fortran '77 era) had to be done outside of the function, which again is unlike the usual syntax.

The only code I've ever seen statement functions used in dated from the 1970s.

Interesting. It's clear to me.

It looks a lot people who had some confusion with the scope of x in something like ...

    f(x) = x^2 + 1

would also have problems quickly seeing the scope of x in lambdas that are present in a bunch of modern programing languages like python.

    f = lambda x: x^2 + 1

It seems python lambdas also don't support type hinting like you mention was a problem in Fortran, too.

I think the Fortran problem was that f(x) = x^2 + 1 looks a lot like a normal statement, with only a subtle clue on the left hand side ("Hey, f isn't an array!...") Whereas in python, having 'lambda' is a bigger clue. Hard to know without trying it out on some test subjects. I don't think anyone really studied why the Fortran thing was a problem, but of course lots of people (including me) have guesses.

As for type hinting, Python 3 does support it: https://docs.python.org/3/library/typing.html but I think the better lesson to learn is that it can be hard to future-proof alternative syntax or syntactic sugar. I looked at the 3.X docs, and PEP 484 and 526, no mention of how this typing can work with lambdas, and no comment that it doesn't (!)

Mis-seeing it as an array makes a lot of sense for the f(x) syntax. That's probably even more true than it would be in a higher level language like python, because you're doing more stuff like that.

But for Python3 lambda type hints, I'm reading a definitive comment in PEP 3107 that it isn't supported [0]. Anecdotally, that also jives with what I'm seeing on the REPL.

    Python 3.6.0 (default, Jan 18 2017, 02:51:38)
    [GCC 4.9.2] on linux
    Type "help", "copyright", "credits" or "license" for more information.
    >>> import typing
    >>> f = lambda x: int: x * 6 
      File "<stdin>", line 1
        f = lambda x: int: x * 6 
                         ^   
    SyntaxError: invalid syntax

[0] https://www.python.org/dev/peps/pep-3107/#lambda

The docs pointed me to PEP 484 and 526, that's why I mentioned exactly what I'd looked at. PEP 3107 is not mentioned in https://docs.python.org/3/library/typing.html

Not trying to be pedantic here, just illustrating the point that this style of function can collide with future language developments, and confuse users.

Here's someone complaining that PEP 484 doesn't mention the impact of the new syntax on lambda: https://mail.python.org/pipermail/python-dev/2015-April/1397...

Reply on news.ycombinator.com