5 ms·

Something tells me these are going to be as bad as PHP's closures; you can't just tack on lambdas at the last minute, it has to be part of the language design i

by jcapote 17y ago

Something tells me these are going to be as bad as PHP's closures; you can't just tack on lambdas at the last minute, it has to be part of the language design initially (no?)

dschobel 17y ago
C# got them in version 2.0 and most people think that's a pretty spiffy implementation. Even more-so with the sugar added in 3.0
- ilyak 17y ago
  It had delegates initially, tho.
adatta02 17y ago
PHP's closures are abhorrent. The syntax is partly the problem but also the fact that functions aren't first class objects in PHP.
kingkilr 17y ago
Python had them tacked on after the fact (version 2.0 as I recall, or was it 2.2?), they work pretty nicely IMO, as long as you treat functions as first class objects the whole time you're ok.
- stcredzero 17y ago
  they work pretty nicely IMO, as long as you treat functions as first class objects the whole time you're ok Clarify this? Also, isn't there some inconvenience due to the indentation thing?
  - kingkilr 17y ago
    There's no inconvenience, it reads pretty normally, for example: http://code.djangoproject.com/browser/django/trunk/django/views/decorators/http.py#L22 http://code.djangoproject.com/browser/django/trunk/django/vi...
    - stcredzero 17y ago
      I meant lambdas in particular. Example is too long for a discussion specific to lambdas.
- dantheman 17y ago
  Python lambdas do not work well, in fact they can only be one line long. For some cases this may be ok, especially if python was were the programmer learned about lambdas, but from those who come from with languages with real lambdas it is quite limiting.
  - deleted 17y ago
    [deleted]
  - kingkilr 17y ago
    We aren't talking about lambdas, we are talking about closures. Lambdas are simple syntactic sugar for a function definition that has a single expression, closures are a concept to capture the outer scope.
- silentbicycle 17y ago
  Not really. For one thing, you can't modify the closed over values unless you manually box them in a list, due to scope ambiguity. (This may be fixed in 3.0.) It's a little thing, but it makes code that depends on manipulating closures pretty ugly, discouraging their use. Scheme avoids the issue by having a non-ambiguous syntax (a big advantage of those parens), and Lua avoids it by defaulting to global scope* unless you declare them with "local", which also anchors their scope unambiguously. * Which is actually not a big deal - the global table is just another table, so you can hook its set method to catch unexpected globals (see strict.lua). It's far less trouble than Python's solution.
  - kingkilr 17y ago
    Python 3.0 introduces the nonlocal keyword which allows you to assign to closed over names.
- statictype 17y ago
  Someone correct me if I'm wrong, but, I think it was less of "tacking on closures" and more of getting the lexical scoping issues right. i.e, there was issues with scoping that had nothing to do with closures per-se. When they fixed it, closures automatically became possible.
tjsnyder 17y ago
The proposed system at http://javac.info/ http://javac.info/ is a little weird and unconventional but it could be promising. It really all depends on what Sun/Oracle decides to do with the language as JDK7 seems to be in limbo at the moment.
jrockway 17y ago
Not true in general. PHP just did it wrong, because the designers don't really know much about programming languages.
akeefer 17y ago
As someone who's implementing closures in a JVM-based language, I can tell you there's no technical limitations on the JVM side: there are decisions to be made as to how you want to implement them, but it's certainly doable with enough compiler magic. That said, the BGGA proposal is a bit of a disaster in my opinion: the distinction between "restricted" and "unrestricted" closures, along with non-local returns, just makes no sense. My assumption is that they want to use closures for things like control structures, which they're just totally inappropriate for, rather than as just anonymous functions, which is what they really ought to be. Basically, it's what they did with generics: take a relatively sensible concept, then add a bunch of baroque edges to it for no good reason. Honestly: => and ==> are almost equivalent things with totally different semantics as far as control structures? Really? People are going to understand that about as well as they understand why they can't add an Object to List<? extends Object>, or why they can't pass a List<String> back from a method that says it returns List<Object>. By which I mean, not at all.
- guelo 17y ago
  The info is sketchy at this point but it seems that Stephen Colebourne's First Class Method proposal is the one in the running. http://docs.google.com/Doc?id=ddhp95vd_0f7mcns http://docs.google.com/Doc?id=ddhp95vd_0f7mcns
- jrockway 17y ago
  The design principle behind Java is "don't add features that could confuse programmers". (This confuses me, a programmer, but that is a bit too meta for this post.) Despite this principle, Java's users asked for generics, and so the language designers added them. But with a twist; they intentionally made the simple concept very confusing. This is so that the next time someone asks for a feature, they can point at generics and say "look at how badly we broke that! do you really want us adding more features?" A few episodes like this (closures will be next), and people won't ask for features anymore. With no more feature requests, it will become clear that Java Is Perfect, and the designers can retire with a very smug feeling of self-superiority. I think.
- wgren 17y ago
  "That said, the BGGA proposal is a bit of a disaster in my opinion: the distinction between "restricted" and "unrestricted" closures, along with non-local returns, just makes no sense." The BGGA proposal was recently updated: "The concepts of restricted and unrestricted function types and closures have been removed. Now, all lambda expressions are restricted. The equivalent of the previous specification's unrestricted closure may be passed to a method by using the control invocation syntax." It is rumored that it is something like a compromise between the BGGA and the FCM proposals that Sun is pushing.

by jcapote 17y ago

Something tells me these are going to be as bad as PHP's closures; you can't just tack on lambdas at the last minute, it has to be part of the language design initially (no?)

dschobel 17y ago

C# got them in version 2.0 and most people think that's a pretty spiffy implementation. Even more-so with the sugar added in 3.0

ilyak 17y ago
It had delegates initially, tho.

adatta02 17y ago

PHP's closures are abhorrent. The syntax is partly the problem but also the fact that functions aren't first class objects in PHP.

kingkilr 17y ago

Python had them tacked on after the fact (version 2.0 as I recall, or was it 2.2?), they work pretty nicely IMO, as long as you treat functions as first class objects the whole time you're ok.

stcredzero 17y ago
they work pretty nicely IMO, as long as you treat functions as first class objects the whole time you're ok Clarify this? Also, isn't there some inconvenience due to the indentation thing?
- kingkilr 17y ago
  There's no inconvenience, it reads pretty normally, for example: http://code.djangoproject.com/browser/django/trunk/django/views/decorators/http.py#L22 http://code.djangoproject.com/browser/django/trunk/django/vi...
  - stcredzero 17y ago
    I meant lambdas in particular. Example is too long for a discussion specific to lambdas.
dantheman 17y ago
Python lambdas do not work well, in fact they can only be one line long. For some cases this may be ok, especially if python was were the programmer learned about lambdas, but from those who come from with languages with real lambdas it is quite limiting.
- deleted 17y ago
  [deleted]
- kingkilr 17y ago
  We aren't talking about lambdas, we are talking about closures. Lambdas are simple syntactic sugar for a function definition that has a single expression, closures are a concept to capture the outer scope.
silentbicycle 17y ago
Not really. For one thing, you can't modify the closed over values unless you manually box them in a list, due to scope ambiguity. (This may be fixed in 3.0.) It's a little thing, but it makes code that depends on manipulating closures pretty ugly, discouraging their use. Scheme avoids the issue by having a non-ambiguous syntax (a big advantage of those parens), and Lua avoids it by defaulting to global scope* unless you declare them with "local", which also anchors their scope unambiguously. * Which is actually not a big deal - the global table is just another table, so you can hook its set method to catch unexpected globals (see strict.lua). It's far less trouble than Python's solution.
- kingkilr 17y ago
  Python 3.0 introduces the nonlocal keyword which allows you to assign to closed over names.
statictype 17y ago
Someone correct me if I'm wrong, but, I think it was less of "tacking on closures" and more of getting the lexical scoping issues right. i.e, there was issues with scoping that had nothing to do with closures per-se. When they fixed it, closures automatically became possible.

tjsnyder 17y ago

The proposed system at http://javac.info/ http://javac.info/ is a little weird and unconventional but it could be promising. It really all depends on what Sun/Oracle decides to do with the language as JDK7 seems to be in limbo at the moment.

jrockway 17y ago

Not true in general. PHP just did it wrong, because the designers don't really know much about programming languages.

akeefer 17y ago

As someone who's implementing closures in a JVM-based language, I can tell you there's no technical limitations on the JVM side: there are decisions to be made as to how you want to implement them, but it's certainly doable with enough compiler magic. That said, the BGGA proposal is a bit of a disaster in my opinion: the distinction between "restricted" and "unrestricted" closures, along with non-local returns, just makes no sense. My assumption is that they want to use closures for things like control structures, which they're just totally inappropriate for, rather than as just anonymous functions, which is what they really ought to be. Basically, it's what they did with generics: take a relatively sensible concept, then add a bunch of baroque edges to it for no good reason. Honestly: => and ==> are almost equivalent things with totally different semantics as far as control structures? Really? People are going to understand that about as well as they understand why they can't add an Object to List<? extends Object>, or why they can't pass a List<String> back from a method that says it returns List<Object>. By which I mean, not at all.

guelo 17y ago
The info is sketchy at this point but it seems that Stephen Colebourne's First Class Method proposal is the one in the running. http://docs.google.com/Doc?id=ddhp95vd_0f7mcns http://docs.google.com/Doc?id=ddhp95vd_0f7mcns
jrockway 17y ago
The design principle behind Java is "don't add features that could confuse programmers". (This confuses me, a programmer, but that is a bit too meta for this post.) Despite this principle, Java's users asked for generics, and so the language designers added them. But with a twist; they intentionally made the simple concept very confusing. This is so that the next time someone asks for a feature, they can point at generics and say "look at how badly we broke that! do you really want us adding more features?" A few episodes like this (closures will be next), and people won't ask for features anymore. With no more feature requests, it will become clear that Java Is Perfect, and the designers can retire with a very smug feeling of self-superiority. I think.
wgren 17y ago
"That said, the BGGA proposal is a bit of a disaster in my opinion: the distinction between "restricted" and "unrestricted" closures, along with non-local returns, just makes no sense." The BGGA proposal was recently updated: "The concepts of restricted and unrestricted function types and closures have been removed. Now, all lambda expressions are restricted. The equivalent of the previous specification's unrestricted closure may be passed to a method by using the control invocation syntax." It is rumored that it is something like a compromise between the BGGA and the FCM proposals that Sun is pushing.