The Artima Developer Community
Sponsored Link

Weblogs Forum
Closures and Anonymous Functions

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

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 54 replies on 4 pages [ « | 1 2 3 4 ]
Cameron Purdy

Posts: 186
Nickname: cpurdy
Registered: Dec, 2004

Re: Verbosity in language design Posted: Aug 27, 2006 9:08 PM
Reply to this message Reply
Advertisement
Max -

> More in-depth discussion at Stevey's Drunken Blog Rants:
> http://opal.cabochon.com/~stevey/blog-rants/lisp-wins.html

I was following you up to the point that you linked to a "LISP will win" blog .. that blew all the credibility points ;-)

(Seriously though, although I disagree with half of what is being posted, I've learned a huge amount over the past few days just from following all the links posted here, so please keep arguing!)

Peace,

Cameron Purdy
http://www.tangosol.com/

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: Language design Posted: Aug 28, 2006 7:31 AM
Reply to this message Reply
> For instance, I'm tempted to use a garbage collecter every
> so often, but I know that garbage collectors have
> drawbacks (mainly, you can't guarantee when an object will
> be collected, so you generally can't guarantee when the
> finalizer will be run, so you can't use the finalizer to
> run code that needs to be run at a specific point in
> time). The language has to give a strategy for memory
> management and resource management. Perhaps a language
> could (1) provide a garbage collector automatically, (2)
> make it possible to turn that collector off if you need
> to, and (3) provide facilities that make it possible to
> write (a) a different garbage collector, and (b) smart
> pointers, or other memry/rsource management techniques.

Resource management should not be coupled with garbage collection.

The time and place that a resource is used should have nothing to do with the way the owner of the resource is allocated.

D has a very good approach to it: objects marked as 'auto' are 'finalized' on function return (so RAII works for D), while the object is allocated on the heap.

While the above is irrelevant to the main discussion, I think It deserves to be clarified.

Max Lybbert

Posts: 314
Nickname: mlybbert
Registered: Apr, 2005

Garbage collection and RAII Posted: Aug 28, 2006 10:42 AM
Reply to this message Reply
/* D has a very good approach to it: objects marked as 'auto' are 'finalized' on function return (so RAII works for D), while the object is allocated on the heap.
*/

Hmm. That's a pretty cool idea.

Max Lybbert

Posts: 314
Nickname: mlybbert
Registered: Apr, 2005

Steve Yegge Posted: Aug 28, 2006 11:06 AM
Reply to this message Reply
/* I was following you up to the point that you linked to a "LISP will win" blog .. that blew all the credibility points ;-)
*/

Actually, he no longer thinks LISP will win ( http://steve-yegge.blogspot.com/2006/04/lisp-is-not-acceptable-lisp.html ). I haven't seen a language I *really* *really* like, although Heron comes close. I've spent a lot of time thinking about why I like feature X, or don't like feature Y.

I can get along with C++ and Perl, I think a statically typed scripting language would be useful (because there are times I'm writing Perl and think "if only this were statically typed," and yes that really happens to me). Heron comes with HeronScript, and I'm responsible for getting it to run on Linux; Andrew Morton developed CS++ ten years ago ( http://www.zip.com.au/~akpm/cs++.html ), but it no longer compiles on modern compilers.

I keep trying to learn functional programming paradigms, which is why I look at LISP, OCaml, and Scala, etc.

Max Lybbert

Posts: 314
Nickname: mlybbert
Registered: Apr, 2005

Another thing closures do Posted: Aug 28, 2006 5:42 PM
Reply to this message Reply
I found something else closures do (which, I think, wouldn't work well with anonymouse inner classes): automated accessors. More info at http://schwern.org/~schwern/papers/Closures_and_Accessors/Closures_and_Automated_Accessors.txt .

Michael Stover

Posts: 28
Nickname: mstover
Registered: Jul, 2005

Re: Verbosity in language design Posted: Aug 29, 2006 8:56 AM
Reply to this message Reply
> 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?

From my limited understanding, you can cause program flow to return from the function/method where the closure is defined, from within the closure, and you cannot do that from within an anonymous inner class. That is the only fundamental difference I can think of.

Regarding the final keyword, it's not a fundamental difference, but I like that the programmer has to essentially pick out all the variables that will be stored for use by the inner class, rather than the compiler grabbing all variables it can find and storing them. But then, you can tell which side of the static/dynamic typing debate I am on :-)

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Verbosity in language design Posted: Aug 29, 2006 9:58 AM
Reply to this message Reply
> > 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?
>
> From my limited understanding, you can cause program flow
> to return from the function/method where the closure is
> defined, from within the closure, and you cannot do that
> from within an anonymous inner class. That is the only
> fundamental difference I can think of.

Can you give an example of what you mean? I'm not sure I've ever seen that done.

> Regarding the final keyword, it's not a fundamental
> difference, but I like that the programmer has to
> essentially pick out all the variables that will be stored
> for use by the inner class, rather than the compiler
> grabbing all variables it can find and storing them. But
> then, you can tell which side of the static/dynamic typing
> debate I am on :-)

Well, from the Java perspective, if you never use the variables, what value does storing them provide?

Jules Jacobs

Posts: 119
Nickname: jules2
Registered: Mar, 2006

Re: Verbosity in language design Posted: Aug 29, 2006 10:31 AM
Reply to this message Reply
> From my limited understanding, you can cause program flow
> to return from the function/method where the closure is
> defined, from within the closure, and you cannot do that
> from within an anonymous inner class. That is the only
> fundamental difference I can think of.

What you describe are continuations not closures.

> Well, from the Java perspective, if you never use the variables, what value does storing them provide?

Yes, the compiler can easily check which variables are used and wrap those in a final hack.

Andy Dent

Posts: 165
Nickname: andydent
Registered: Nov, 2005

Re: As to the question Posted: Sep 3, 2006 3:23 AM
Reply to this message Reply
> Implementing a new Object system with
> closures is reinventing the wheel as an oval if ever I've
> ever seen it.

Yeah but with a cool eccentric cam on the axle it still drives as smoothly.

BTW skimming the topic belatedly, I had no problem in understanding both your point and frustration with the responses.

regardless of verbosity, is there any functionality available in closures that is not available either currently with local classes or with anonmous inner classes?

Jules Jacobs

Posts: 119
Nickname: jules2
Registered: Mar, 2006

Re: As to the question Posted: Sep 3, 2006 6:09 AM
Reply to this message Reply
> regardless of verbosity, is there any functionality
> available in closures that is not available either
> currently with local classes or with anonmous inner
> classes
?

Any language feature can be implemented in another language. Sometimes it will be more verbose and sometimes it won't. You can implement closures with objects. You can implement objects with structs and function pointers. This may not be a good answer for you but it's the only correct answer.

Rolling your own closures with objects is harder than rolling your own object system with closures though.

Flat View: This topic has 54 replies on 4 pages [ « | 1  2  3  4 ]
Topic: Closures and Anonymous Functions Previous Topic   Next Topic Topic: Frustration-Driven Language Development


Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us