Lambda the Ultimate

In Python, I believe that lambda does return implicitly. Use of 'return' is only required in functions introduced via 'def'. No, I don't think this particularly makes a lot of sense. (This may have been what you meant, but it wasn't quite clear.)

I'm putting together a course at the moment, a sort of "Learning to Program With Python". (No, I didn't get to choose the language.) The course has a functional bias, but I must say that it has been of a trick to do this with Python. It really is not well-suited to FP.

A 'def' function will implictly return the value None if there is no return statement. It just doesn't do the 'last expression evaluated is automatically returned' which isn't necessarily inuitive. As the 'zen of python' says, explicit is better than implicit.

And in fact, since it doesn't look like the Zen of Python has been listed here before, maybe this will foster some constructive discussion:

Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)]
32
Type "help", "copyright", "credits" or "license" for more information.
>>> import this
The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!
>>>

Neither is more intuitive than the other. The first time I used Python, I was surprised that I had to explicitly return.

let x () =
  1;

def x ():
    return 1

let x () =
  1;
  2;
  3

def x ():
    1
    2
    return 3

Python is rather cranky about the difference between expressions and statements. Lambda takes an expression (and as a result is not terribly useful). Return converts an expression to a statement (that returns the result of the expression).

I'm putting together a course at the moment, a sort of "Learning to Program With Python". (No, I didn't get to choose the language.) The course has a functional bias, but I must say that it has been of a trick to do this with Python. It really is not well-suited to FP.

If you are teaching a sort of "Learning to Program with Python", wouldn't it be easier to teach Python rather than Scheme impersonated by Python? Swimming upstream, and all that....

Extending Python to be more FP is interesting to me, as long as it doesn't change any meaning in existing Python code. This post is geared just toward asking if folks know specific restrictions that can be loosened, that don't result in chaos.

(I don't mean to cause trouble. I'll duck exchanges about whether FP is good or not, or whether Python needs less or more of it. I just wonder if Python says "you can't do that" in some cases where nothing bad would happen if it were permitted instead.)

If a backend with more FP support (pervasive TCO for example) was used to implement Python, and care was taken not to change the meaning of existing Python syntax, what additional things might you do in Python like you could in Scheme if a restriction was loosened? Or if a new bit of non-ambiguous syntax was added? (Extending syntax would be a Python variant of course; you'd want compatibility in at least one direction.)

When you're reading a "function" in Python, if it doesn't return a value, you don't have to wonder if someone, somewhere, cares what value it returns. You don't have to wonder whether its callers know it has side effects. And you don't have to wonder whether the method call it happens to have as its last line returns a value you have to care about.

It substantially expands the number of modifications you can make to the program without being afraid of breaking it, without doing a whole-program analysis to understand their effects.

I agree, explicit return is essential for any dynamically typed language. The E language found this out the hard way, as even relatively simple refactorings caused unintentional information and authority leaks.

Ruby has no such problem. Just saying.

[Edit Note: I guess I should add that Ruby shares more in common with Smalltalk code blocks than it does with Scheme lambdas.]

Also, Python doesn't play well with recursion, which is yet another FP thing.

Luckily, the development version of the ruby interpreter/VM already does taill call elimination.

And yes, ruby's lambda are no substitute for normal methods.
At some point matz was esperimenting with syntax sugar that would allow foo() to mean foo.call() if there is a foo variable in scope, but that introduced some subtle ambiguities, IIRC.

Shouldn't langauge bashing go in the forum or comments?

Not on the homepage?

Yes. And in general, it may not even be appropriate in the forum or comments; see point 6(a) in the policies.

We can't change the fact that LtU is an FP site. We can't deny it either. We can only be more-accommodating of divergent views better than c.l.l. Okay, that's easy, but ... :o)

We can't change the fact that LtU is an FP site. We can't deny it either.

I suppose it depends on the definition of "an FP site". This thread had some good comments on this subject, in the linked comment and subsequent comments.

I think the point was intended to be that FP is a semantic issue rather than just a syntactic one - the "cancerous" comment isn't about paradigm, it's about paying attention to surface issues.

To put it another way, it's a complaint about Wadler's Law in action. Which isn't to say that it was necessarily a well-phrased one.

The obvious reference is, of course, to Perlis's epigram Syntactic sugar causes cancer of the semicolon.

Wadler seems to be suggesting that people spend a lot of time discussing things that aren't very important. Certainly they aren't the things that he thinks are important.

But maybe syntax and especially comment syntax is really more important than semantics. After all, you (a hacker in general, but especially someone like you, Philippa) can eventually Greenspun any Turing-complete language into something usable. But if other people can't read your program, it will have failed at conveying your ideas to them, and they won't be able to learn from it, fix bugs in it, or modify it to fit their needs.

So maybe the people discussing comment syntax are onto something.

Most research aimed at the theory of programming languages is based on the lambda calculus - and any meta-discussion of PLs will probably be framed in functional programming terms.

That said, I think the Guido has stated quite explicitly on any number of occasions that the goal of the Python community is not to create a PL that can be classified as an FP language. Given that acknowledgement, the merits of Python 3000 probably should not be judged on the basis of how well it supports a paradigm that it explicitly is not trying to achieve.

While I understand the points you're trying to make, you're using the wrong language for the audience. Amongst other things, 'trick' can often mean 'well-founded technique I hadn't seen the groundwork for before' - which isn't to say that Python isn't allowed to stick to a carefully chosen set of base concepts, but it can't be assumed that the audience here knows all of Python's stances.

Also, "single complex expression" is... not the simple concept you might think it is. Python has two distinct syntactic categories of 'expression', but there's not necessarily anything particularly special about ; as an operator whether it's explicit or implicit - Python programs are still "single complex expressions", there's just a certain amount of enforced convention to aid readability. There's no reason not to look at exploring other conventions for that purpose, or to make blanket statements that equate functional programming with minimalism of concrete syntax.

Python is not trying to be Haskell. Besides, if it is Haskell we want, we know where to find it.
Only that I had to write Python code, after something like one-and-one-half years of straight Ruby (no, not Rails, just scripting) and Haskell + OCaml, and I found that my expectations had changed along with my style. More recursion, an expectation of implicit returns, et al.
So, I'm generally rusting at Python. But ...

Python is becoming a better Python, and I really would have loved to be in the community yet. Python is great, even without being of the paradigm I favour these days.

Python is becoming a better Python

I agree, and I'm glad to see the improvement since I use Python at work. Years back, when Guido first started talking about Python 3000, I was disappointed at how small the changes seemed, but now the update looks like it will have some good stuff. (Maybe even generic functions!)

At risk of descending into advocacy, this Haskeller is far from convinced that writing functional code in Python is 'a lot easier than' writing procedural code in Haskell.

There's no reason to worry about advocacy.

Objectively you can't write functional code in (standard) Python for at least two distinct reasons.

All this time I thought I was writing functional code when I wrote higher-order functions with no side effects.

know of a language that handles it in a more elegant way?

I like the way Scala's library defines /: and :\ operators as semi-synonyms for foldLeft and foldRight respectively.

It does make one suspect, however, that it's only a matter of time before there's a smiley operator in there somewhere.

Perl6 provides operators for almost everything so of course it has something here :)

The prefix "reduce metaoperator" takes an operator and basically just puts it between the arguments, eg:

[+] 1,2,3

IIRC it handles folding to left or right just by relying on the definition of the operator.

Additionally, since perl6 provides chaining operators it also allows stuff like
[>] 1,$x,3
to mean 1 > $x > 3

I should also mention that I didn't find Mark's post objectionable, or as praticularly opinionated. And I like Python...

It seemed inexplicably unfair to me. Here's why (quoting from the story):

Syntax focus seems cancerous

This inflammatory remark is neither explained nor supported. The subsequent phrase doesn't seem to relate:

leaving FP sandwiched between set literals and backtick syntax, under Miscellany:

This refers to the ordering of bullet points in a short list of changes, yet it's phrased as though it's somehow a valid criticism. It's not. (See also "FP = Miscellany" below).

* reduce() is gone

This quote of Guido's is the only change that might have supported the story's focus, but Guido's post was apparently later edited to add "(moved to functools, really)". [Edit: ...which only emphasizes the weakness of Mark's remaining points.]

The idea that FP = Miscellany

One FP-related change and one FP-related non-change was listed under "Miscellaneous". That hardly translates into any kind of claim that "FP = Miscellany".

* zip(), map(), filter() return iterables

So FP is not even a free-standing category yet

I don't know what this means, in the context of Python and these functions. Why should FP be a "free-standing category" in Python, and what does that mean? What should these functions return, to achieve that? A bit of explanation would have added some substance to the story.

Finally, individual members are allowed (indeed, encouraged...) to have opinions, and shouldn't be afraid to express them, when appropriate, for fear they might help some outsider claim that LtU is an FP site (or any other silly generalization).

What outsiders think is not particularly important. Expressing the opinion that Python should have a stronger focus on FP is reasonable. But this story went beyond that, into mischaracterization. We should aspire to better than this.

I'm not saying this is one of them, but still: Ponder the spectacle of a language which says it does not want FP, achieving its most famous success with FP - Google's MapReduce - and the company then hiring the language designer.

I'm not sure why you suggest that MapReduce is a success for Python. Wikipedia states that Google's MapReduce is implemented in C++ (though it does note that they have Python bindings). MapReduce appears to have little or nothing to do with Python specifically.

"Most REBOL programmers have no idea they are in effect using Scheme/Lisp FP. They just know it works magic. They (and I) see the same zen in it as listed in the Python zen creed."

Agreed :)

- REBOL guy