Lambda the Ultimate

Python claimed to have the lambda calculus as part of the language for years, even though it didn't really.

Lambdas got a lot less broke around version 2.2 or so. You can now form a closure using a lambda but not using a def. Python's scoping rules are *weird*.

Maybe Dylan is what Dan is looking for.

As it has dynamic behavior with static typing. But on the surface, the syntax is quite different than Python.

Maybe when Needle is ready, that'll be even closer.

WRT, Python. Guess I need to go relearn the language. :-)

Needle won't ever by ready, because I've changed my mind about what sort of language I want to program in. :) If you like that style, though, please take a look at Nice instead.

Started to look at it a couple of times, but never got far (being absorbed in Alice for the last 6 months hasn't helped matters). Isaac Gouy did send me Nice Shape example sometime back - and I really ought to link that in with the rest of the examples.

Admittedly from only looking, I was preferring Needle to Nice and similar languages, and was sad to hear it "die".

You can now form a closure using a lambda but not using a def.

You can form a closure with either. You don't get to mutate closed-over bindings, though.

Python's scoping rules are *weird*.

Yep. Pretty much all of it stems from not distinguishing between binding and assignment in the syntax.

The following two links seem to suggest that most general-purpose functional programming constructs are going to disappear from Python:

http://www.python.org/peps/pep-3000.html

http://www.artima.com/weblogs/viewpost.jsp?thread=98196

The surviving FP-ness in Python will be list comprehensions.

The 'lambda' keyword is getting removed but closures remain as they have always been. Traditionally 'lambda' was almost always used in Python programs in conjunction with 'map' and 'filter'. So, given that list comprehensions provide a much more readable alternative to those higher-order functions for the vast majority of use cases, Guido decided to remove them. Now, I would have liked to have kept them but in all honesty I almost never find myself wanting to use either 'lambda', 'map' or 'filter' despite that my coding style features higher-order functions and such heavily. I know that Ehud has mentioned that he programs in Python, so maybe he and other LtUers can provide their perspective on this?

Anyway, all in all, I'm not sure it's fair to say that the only surviving "FP-ness" is list comprehensions. In fact, more "FP-ness" is being introduced with the appearance of the 'partial' higher-order function (which performs currying) in the Python 2.5 standard library. (It can be accessed in Python 2.4 by importing it from __future__.)

I know that Ehud has mentioned that he programs in Python, so maybe he and other LtUers can provide their perspective on this?

lambda is not easily replaceable by a library function but removing filter, reduce etc. from the builtins into some custom FP module is just usual refactoring and more severe refactorings are expected to happen on Py3K. The status of lambda remains unclear. Some say that the feature should be removed from the language altogether with the "lambda" keyword others just want another syntax. Ironically I like 'lambda' and I wish it had some companions namely 'phi' and 'xi' ;) But this is a different topic and I might come back to this later here on LtU.

For FPL programmers it weights much more that recursion in Python is rather slow and will not be optimized by means of tail call elimination. Guidos prevalence on the OO paradigm may shine through but I don't want to criticise this here simply because his insight is somehow correct that FP is not just a bunch of features but a complete methodology and Python won't ever fit into this. Functions like map, and reduce have clearly not the same significance in Python than map and fold have e.g. in Haskell. Since they are not used recursively but as iterators they are redundant and can be replaced by list/generator comprehensions.

For __future__ I'm not sure that Python will not be superseded by itself? The PyPy runtime[1] is not just a very actively maintained project but the group around Holger Krekel and Armin Rigo where that clever that they get funded by the EU with a budget of 2Mio €. Since PyPy enables extension of the runtime in Python the language becomes finally a programming programming language. Which forces will drive the development of Python if PyPy succeeds in approaching CPython speed no one can tell.

Kay

[1] http://codespeak.net/pypy/dist/pypy/doc/news.html

Who said:

"Object-Oriented Programming
in languages that don’t require
tail-call optimizations makes
no sense."

?

In the presentation "Functional Objects, Functional Classes" Felleisen tries to find common ground between object oriented programming and functional programming.

It contains some very sharp observations.

• The whitespace
• The way the ASCII character set is used sparingly.

• Java usually requires break keywords in switch and in the rare instances when they genuinely shouldn't be there they look like bugs.
• var : type is in my view better than type var since the first draws attention to the variable name and makes it easier to 'decode'. Compare apples : int Array of 0..9 to int apples[10].

I'm sure not everybody aggrees with me on everything I said but I hope this clarifies what I mean a bit better. I'll take a look at GvR. BTW I like the slicing syntax too.

Note: You need to close the italics </i>

The whitespace

The way the ASCII character set is used sparingly

Java usually requires break keywords in switch and in the rare instances when they genuinely shouldn't be there they look like bugs.

var : type is in my view better than type var since the first draws attention to the variable name and makes it easier to 'decode'. Compare apples : int Array of 0..9 to int apples[10].

none of them was entirely satisfactory: either the climate wasn't quite right in the later part of the afternoon, or the day was half an hour too long, or the sea was exactly the wrong shade of pink.

Edit Note: GvR is Python head of state Guido van Rossum. The addition of type information was discussed previously on LtU.

I'm fairly religious about indentation and structure, but I dislike assigning semantic meaning to whitespace. Indentation is a job for a pretty printer, not a compiler.

Could you explain your reasoning here? I used to think that too but then I realised that whilst working as a C++ developer the only places where code was not ever indented correctly (so that a Python interpreter could read it if it was Python) was where somebody had used tabs. As a student I found it frustrating trying to read other students bad code but whilst I somehow coped with students naming classes after themselves it was the bad indenting that made code impossible to read.

Can you suggest procedural code that breaks the Python whitespace semantics but is more readable than if Python's whitespace semantics had been used?

Whitespace semantics "works" fine given the syntax of Python. But I still prefer not to have whitespace have semantic meaning. Styles and idioms are nice things to have, in terms of readibility. But they are a craft that's best left to the programmers. If the programmers fail, then a pretty printer can fix the problem in fairly short order.

The fact that you have C code that's unreadable, owing to layout, is the fault of your code editor. I have my own view preferences when it comes to code - preferences that come about having used a bunch of different languages. Reading code should be as much a matter as conforming the layout style to the reader, as opposed to a universal set of guidelines that match all needs.

Like I said, I was weened on Pascal. As such, I prefer code that is blocked with keywords when necessary that indicates a block or structure is being entered into. It's all a matter of personal preference. What we need is to have the code editors cater to our personal preferences, rather than relying on the vagaries of individual programmers, or the arbitrary decision of the compiler to decide which particular styles and idioms have to be enforced at all costs.

In the end, I don't buy the Pythonista's argument that code readibility hinges strictly on nice neat columnar layout of the code. Probably helps for the degenerate case of programmers that don't have enuf sense to properly lay out things. But generally this same population can screw up readibility in more than one way (each attempt to make things idiot proof, is doomed to creating ever expanding types of idiots).

That said, where assignment of whitespace semantics gets beyond nuisance is in code that is embedded code or code that is saved off in a format other than a text file.

What about the approach taken by Haskell, where use of layout-sensitive syntax is optional (that is, layout kicks in locally only if you omit braces at certain well-defined and obvious points)? That should address most of your concerns. I always found it the ideal solution - and Haskell code beautiful indeed.

Suits my tastes better than strict reliance on layout. Mostly being contrarian on the issue, as it really doesn't make a big difference to me either way. Though I can't help that a language's surrounding culture makes more of a difference in terms of writing maintainable code. Haskell code is easier to read because Haskell coders are immersed in a culture that values elegance. Much Smalltalk code is not bad on the eyes, but in that case the lack of a safety net in syntax actually has forced the culture to rally around styles that are enforced by the power of shun. Layout rules are more a way to encourage good coding styles, than they are the ultimate solution to having all code in the language be easily accessible.

I've never understood the whitespace thing of Python, Haskell, Merd, yadda. I mean, what if I ever want to copy & paste code? I know, "you shouldn't ever be copying and pasting code!" but that just isn't realistic. For me. Speaking for myself. And just I.

In Haskell, it's never been a problem. I just don't find myself pasting code from a different block. Also, Haskell gives you the option to use '{', '}', ';' instead of the offset syntax. However, I've never heard of anybody going back to the curly braces after getting comfortable with the offset syntax.

I agree... I like slicing too. Though I still find list manipulation in Python somewhat cumbersome, even with slices. You might agree, once you've been seduced by a functional programming language and master its art of list processing. (It's even better if you use pattern matching!)

I thought of Dylan because it's sort of a fusion of Java and Python semantically, and I somehow missed you were talking more syntax. Syntactically, Dylan is its own beast, kinda verbose and conventionally makes moderate to heavy use of ascii.

But syntax is just syntax. I'll take terrible syntax with good semantics over great syntax with bad semantics almost any day of the week.

Your programming prowess would really benefit from learning a radically different language than Java and Python. Most LtU'ers have mastered at least one of Haskell, OCAML, or Scheme. Of these options, Haskell has the most "Pythonic" syntax; OCAML and SML have more of an "ALGOL-ish" syntax, and Lisp/Scheme is in it's own category.

If you decide to explore Scheme, there are a large number of implementations to wade through. I highly recommend Dr Scheme because of its user-friendly syntax editor and integrated development environment. The right editor makes pleasant the often painful Lisp syntax experience.

var : type is in my view better than...

Well Zonnon is probably too traditional for you, so try Scala.

class Stack[T] {
  var elems: List[T] = Nil;
  def push(x: T): Unit = elems = x :: elems;
  def top: T = elems.head;
  def pop: Unit = elems = elems.tail;
}

Albeit with a tremendously crufty syntax.