Weblogs Forum - Closures and Anonymous Functions

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

Sponsored Link •

Weblogs Forum
Closures and Anonymous Functions

54 replies on 4 pages. Most recent reply: Sep 3, 2006 3:09 AM by Jules Jacobs

Welcome Guest
Sign In

Back to Topic List

Reply to this Topic

Search Forum

Threaded View


Previous Topic		Next Topic

Flat View: This topic has 54 replies on 4 pages [ « | 1 2 3 4 | » ]

Marcin Kowalczyk

Posts: 40
Nickname: qrczak
Registered: Oct, 2004

Re: Verbosity in language design

Posted: Aug 23, 2006 5:08 PM

> Not bad :)

Still bad. Same function in Haskell:

scaleList list factor = map scaleList (*factor)

Marcin Kowalczyk

Posts: 40
Nickname: qrczak
Registered: Oct, 2004

Re: Verbosity in language design

Posted: Aug 23, 2006 5:09 PM

(Oops, even a single line of code can have a typo.)

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Verbosity in language design

Posted: Aug 23, 2006 7:35 PM

I guess the resounding silence in reponse to my question means that there would be no new functionality and just shorter syntax?

Jules Jacobs

Posts: 119
Nickname: jules2
Registered: Mar, 2006

Re: Verbosity in language design

Posted: Aug 24, 2006 11:03 AM

I think you can use inner classes as closures, *if* you make all variables one element arrays.

> [1] First of all the 32 to 3 figure is obviously
> nonsense because the 32 count includes the map()
> implementation and the 3 does not. [2] In addition
> the 32 figure counts an empty main method and
> a Test class declaration.

[1] True, my mistake
[2] The problem is, you do have to use a class definition in Java if all you want is a function. If you remove all/most boilerplate code you get something like Haskell.

> Still bad. Same function in Haskell:
> scaleList list factor = map scaleList (*factor)

Wrong ;-). The function is map's first parameter, so it's:

scaleList factor list = map (*factor) list

that is:

scaleList f = map (*f)

(it's Haskell-style to use one letter variable names if it's still clear what a function does)

that is 8 syntax elements (better indication than LOC) for Haskell and ~80 for Java.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Verbosity in language design

Posted: Aug 24, 2006 11:35 AM

> I think you can use inner classes as closures, *if* you
> make all variables one element arrays.
>
> > [1] First of all the 32 to 3 figure is obviously
> > nonsense because the 32 count includes the map()
> > implementation and the 3 does not. [2] In addition
> > the 32 figure counts an empty main method and
> > a Test class declaration.
>
> [1] True, my mistake
> [2] The problem is, you do have to use a class definition
> in Java if all you want is a function. If you remove
> all/most boilerplate code you get something like Haskell.

I really am not sure if there's any other way I can say this. I understand that the Java way of doing this is a lot more verbose. I agree that it is too verbose. I am fully in favor of a closure and/or anonymous function addition to Java. I've was a proponent of such an addition before this proposal was announced. This is at least the third time I've pointed that out in this thread.

I still don't have an answer to my actual question.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Verbosity in language design

Posted: Aug 24, 2006 11:40 AM

Not to belabor the point, but are people not reading my posts in entirety? It's really quite frustrating. Am I writing in gibberish? What's the problem exactly? I really can't understand why someone would read my previous posts and then continue to go on about verbosity. I can only assume you aren't reading the whole post or that you are trying to needle me.

Max Lybbert

Posts: 314
Nickname: mlybbert
Registered: Apr, 2005

Re: Verbosity in language design

Posted: Aug 24, 2006 12:04 PM

Sorry I didn't get a chance to reply earlier.

/* First of all the 32 to 3 figure is obviously nonsense because the 32 count includes the map() implementation and the 3 does not.
*/

I'll concede the point here, but I still believe that Java encourages unnecessary verbosity (see below).

/* (me) So, yes, to me, the fact that Java requires not just more code, but ten times the LOC is pertinent to me.

(response) I didn't say it wasn't pertinent.
*/

My response was to the line

/* That it takes more code is not pertinent nor is it interesting.
*/

And my response can be boiled down to "that it takes more code *is* pertinent to me." I didn't want to wade into any question outside of Java's verbosity. Which is why I relabeled my post.

Java has been held up for years as the poster child of good language design. And the big part of that "good design" is "Java *is* OOP" (compared to "Java *supports* OOP"). Java was advertised as great because you couldn't ever have anything that wasn't an object. No free-standing functions, no macros, nothing but objects. But what if you want a free-standing function? Well, you can forget about the "free-standing" part, but you can make it a class static method, which is pretty much the same thing. Although instead of writing int add_three(int x), you need to write something like:

class Fugger
{
  static int add_three(int x) { ... }
};

What use is class Fugger? Absolutely no use at all. How about static? Well, it just means that the useless class Fugger that we wrote doesn't have to actually be instantiated to use add_three. But we still have to write Fugger.add_three instead of simply add_three.

Whew. IOW, Java requires us to make an class to hold what could be a free-standing function, if only Java trusted us with one. And we have to always refer to that class if we ever want to use our method. At least Java doesn't require us to instantiate an object for add_three, but that's only because we asked Java nicely to let us use the method without making an object first.

These kinds of language issues are what I consider spinning my wheels, and why I believe Java is too verbose. http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html .

Max Lybbert

Posts: 314
Nickname: mlybbert
Registered: Apr, 2005

Whoops

Posted: Aug 24, 2006 12:09 PM

/* I really am not sure if there's any other way I can say this. I understand that the Java way of doing this is a lot more verbose. I agree that it is too verbose. ... This is at least the third time I've pointed that out in this thread.
*/

I formulated my response after I read the response to what I wrote yesterday, but I didn't get to post it until later. If I had read the comments posted in the meantime, I wouldn't have spent as much time explaining that Java's verbose. I appologize for that.

Max Lybbert

Posts: 314
Nickname: mlybbert
Registered: Apr, 2005

As to the question

Posted: Aug 24, 2006 12:17 PM

/* Can you do things with closures that you cannot do with anonymous inner classes or not? Are we just talking about reducing verbosity of something more?
*/

You can implement a new object system with closures (g): http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/msg03277.html .

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Verbosity in language design

Posted: Aug 24, 2006 12:31 PM

> /* (me) So, yes, to me, the fact that Java requires not
> just more code, but ten times the LOC is pertinent to me.
>
> (response) I didn't say it wasn't pertinent.
> */
>
> My response was to the line
>
> /* That it takes more code is not pertinent nor is it
> interesting.
> */

Sorry. That was my bad. What I meant was that I didn't mean the verbosity wasn't pertinent (i.e. important) in general but that it's not pertinent to the question that I am looking to find a definitive answer for. For good measure, I'll restate again:

Does a less verbose version of an anonymous inner class qualify as a fully-fledged closure (ignoring the final requirement on locals for a moment) or is there something else that is required.

I've often seen is stated that anonymous functions are the 'closests things to closures' in Java and I've yet to find a good explanation as to why they were just close. I guess I never considered that verbosity would be the only difference because that seems like a pretty superficial qualification. I mean I would find it odd to find a formal definition of closure that included something about how much code was required to create one. That's not a fundamental part of any concept in Computer Science that I am aware of.

It kind of reminds me of the scene from Spinal Tap: "The numbers all go to eleven. Look, right across the board, eleven, eleven, eleven"

Jules Jacobs

Posts: 119
Nickname: jules2
Registered: Mar, 2006

Re: Verbosity in language design

Posted: Aug 24, 2006 12:37 PM

> Not to belabor the point, but are people not reading my
> posts in entirety? It's really quite frustrating. Am I
> writing in gibberish? What's the problem exactly? I
> really can't understand why someone would read my previous
> posts and then continue to go on about verbosity. I can
> only assume you aren't reading the whole post or that you
> are trying to needle me.

My response:

> I think you can use inner classes as closures,
> *if* you make all variables one element arrays.

You can modify variables for the enclosing scope in a closure. You can't do this in anonyous classes. There is, however, a hack to modify these variables: you use an array as a wrapper. I believe that they are equivalent to closures if you declare variables that way. That said, I don't have much Java experience, so I could be wrong.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: As to the question

Posted: Aug 24, 2006 12:40 PM

> You can implement a new object system with closures (g):
> http://people.csail.mit.edu/gregs/ll1-discuss-archive-html
> /msg03277.html .

I suppose you are saying you couldn't do this with anonymous inner classes? To be honest, I'm not very moved with by the whole 'objects are a poor man's closures' argument. It seems more like a rationalization than an honest argument. Implementing a new Object system with closures is reinventing the wheel as an oval if ever I've ever seen it.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Verbosity in language design

Posted: Aug 24, 2006 1:00 PM

> My response:
>
> > I think you can use inner classes as closures,
> > *if* you make all variables one element arrays.
>
> You can modify variables for the enclosing scope in a
> closure. You can't do this in anonyous classes. There is,
> however, a hack to modify these variables: you use an
> array as a wrapper. I believe that they are equivalent to
> closures if you declare variables that way. That said, I
> don't have much Java experience, so I could be wrong.

Ah, is my face red or what. Sneaky, putting your answer above my the quoted section.

This is pretty much what I thought. Actually with generics in 1.5, we can do this:

class Pointer<E>
{ 
    E ref;
}

But actually, I think there may be a distinction. With an anonymous function or closure in a lot of languages, can't you return an anonymous function with a return type of int (for example) in place of an int. In effect delaying the execution of the function until the return value is used or something? That's something you definitely can't do in Java.

Max Lybbert

Posts: 314
Nickname: mlybbert
Registered: Apr, 2005

Re: As to the question

Posted: Aug 24, 2006 2:42 PM

/* I suppose you are saying you couldn't do this with anonymous inner classes?
*/

To be honest, I've only used closures in Perl, and only as callbacks. Aside from that, I know the mantra "closures are a poor-man's object." I'm not really the guy to ask about what exciting things you can do with closures.

You've obviously read the linked-to message, but a simple quote for the guys who didn't follow the link:

"But from another perspective, the apply 'method' of a closure can be used as a low-level method dispatch mechanism, so closures can be, and are, used to implement very effective objects with multiple methods. ... Used in this way, closures can be said to be richer than objects because they can support many more capabilities than just a single language-provided method dispatch mechanism."

I don't know if that's easy or hard to do with anonymous fuctions. Perhaps it was a bad example to use, but it was the first one that came to mind.

And, yes, you can question the wisdom of inventing a custom object system in an object-oriented language. Once upon a time I ran across the now-mothballed Amulet project over at Carnegie-Melon. Amulet is written in C++, but has its own dynamic object system that makes some of the C++ code act more like a scripting language ( http://www.cs.cmu.edu/afs/cs/project/amulet/amulet3/manual/ORE.html#1024910 ). Of course, today, you could use Lua in C++ to get a similar effect.

Why would you want a different object system? First idea on my mind is to work with web services. You create a WebServices objects that can add new methods at runtime. Java's object system didn't permit this when I stopped using Java five years ago; I can't say anything about whether it lets you do that today.

Back to the closures and custom object system, I would love to get multimethod dispatch without using the Visitor pattern ( http://www.sidhe.org/~dan/blog/archives/000194.html ). It's not as useful as other features, but when it's useful it's incredibly useful ( http://www.sidhe.org/~dan/blog/archives/000198.html ).

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: As to the question

Posted: Aug 24, 2006 7:37 PM

> Why would you want a different object system? First idea
> on my mind is to work with web services. You create a
> WebServices objects that can add new methods at runtime.
> Java's object system didn't permit this when I stopped
> d using Java five years ago; I can't say anything about
> whether it lets you do that today.

No, it doesn't. There are other ways to solve that problem in an OO way but that's another discussion.

> Back to the closures and custom object system, I would
> love to get multimethod dispatch without using the Visitor
> pattern (
> http://www.sidhe.org/~dan/blog/archives/000194.html ).
> It's not as useful as other features, but when it's
> s useful it's incredibly useful (
> http://www.sidhe.org/~dan/blog/archives/000198.html ).

Java should have had multi-methods from the start. It's what most (in my experience) developers expect and you can don't have to use the feature.

Flat View: This topic has 54 replies on 4 pages [ « | 1 2 3 4 | » ]

Previous Topic

Next Topic