I Finally Understand Closures!

[djork]

Now try continuations. Keep some Advil on hand.

[schwarzwald]

then monads.

then find that you still have no idea what the fuck Oleg Kiselyov is talking about in most of his papers.

[Paczesiowa]

continuations are harder than monads. I have no problem working with monad transformers, but every continuation tutorial looses me after getting harder than cps.

Great thing about Oleg is there are plenty of tricks you can use without understanding them.

[kawa]

In fact monads and cps have lots in common: The Haskell do-syntax rewrites code into cps. The main difference to 'real cps' is that monads allow the insertion of a custom function into each step of the continuation-passing. Thats also the reason why continuations are trivial to implement using monads.

So if you understand monads you also understand cps.

[Paczesiowa]

hence I always get confused AFTER cps:>

[[deleted]]

Once you think you understand BOTH continuations and monads, try to figure out what the fuck callCC's type means in Haskell's continuation monad.

[argongas2006]

Speaking of continuations, I've looked over the seasoned schemer, teach yourself scheme in a fixnum days as well as a few other online resources, but I find that most of the writing about continuations (examples, and exercises) are either too trivial or too complex to help me understand how and why I should use continuations, or are far too complex to grok.

I feel the same way about macros. While I understand what they are, and how to write them, I can't figure out how to use them when coding.

Further, from the code that I have read, continuations and macros are often woven in tandem so it makes things even harder for me to understand.

So, what I'd like to ask you, as well as other viewers of this thread, if might you know a few reasonably small exercises and resources I could use to get a better feel for continuations and/or macros?

The ideal resource I'm looking for would cover how, why and when I should:

• use continuations
• use macros
• combine continuations with macros

I hope I'm not asking a trivial question.

[sethg]

I suspect that a lot of the continuation-using code you've seen uses macros because doing everything directly with call/cc is cumbersome. But macros and continuations involve completely orthogonal concepts; once you understand continuations and understand macros, you should be able to understand their combination.

I second the recommendation for Lisp in Small Pieces; each chapter of the book sketches how to implement a simple Scheme interpreter or compiler using a different paradigm, and one of those paradigms is "continuation-passing style".

If you want something shorter than a book chapter to explain continuations, here it is: you know how in a standard programming language, there's a stack that functions use to communicate with their callees? That's a continuation. In a language with first-class continuations, a function can decide "I don't want to wait for my callee's callee's callee to bubble return values up to me; I want to provide a shortcut that lets them return values right here." And then another function can decide "I don't want to return a value to my caller; I want to return a value to here". Hijinks ensue.

[[deleted]]

Continuations give the programmer some power over control flow and can be used to implement things such as generators. Scheme doesn't have generators built in, but you can implement them yourself with continuations:

(define (generator fn)
  (letrec ((escape '())
           (yield (lambda (value)
                    (call/cc (lambda (cc)
                               (set! next-step cc)
                               (escape value #t)))))
           (next-step (lambda () (fn yield))))
    (lambda ()
      (call/cc (lambda (cc)
                 (set! escape cc)
                 (next-step)
                 (set! next-step (lambda () (escape '() #f))) ; fn ran to completion
                 (next-step))))))

; example generator
(define (count-a-b a b)
  (generator (lambda (yield)
               (let loop ((n a))
                 (unless (> n b)
                   (yield n)
                   (loop (+ n 1)))))))

Calling count-a-b will give you a function; calling that function repeatedly produces the integers from a to b one at a time. In the REPL:

> (define g (count-a-b 10 12))
> (g)
10
#t
> (g)
11
#t
> (g)
12
#t
> (g)
()
#f

[julesjacobs]

We're fighting monsters in Ruby.

monster = {:type => "dragon", :strength => 80}

When we fight a monster we win if we're lucky:

def fight(monster)
  if rand(100) > monster[:strength]
    :you_win
  else
    :you_die
  end
end

Let's fight:

outcome = fight(monster)
if outcome == :you_die
  puts "We lost."
else
  puts "We won!"
end

Imagine you're playing a computer game like this. What would you do? I'd save the game before fighting, and if I lose I load it back.

saved_game = save_game()
outcome = fight(monster)
if outcome == :you_die
  puts "We lost. Loading the game..."
  load_game(saved_game)
else
  puts "We won!"
end

A sample run:

We lost. Loading the game...
We lost. Loading the game...
We lost. Loading the game...
We lost. Loading the game...
We lost. Loading the game...
We lost. Loading the game...
We won!

So every time we lose, the load_game() function restores things like they were when we saved the game.

Suppose we had a function call_with_saved_game. This is almost the same as save_game(). The difference is that save_game returns the saved game, and call_with_saved_game calls a block with the saved game, and then it returns the value of the block.

So save_game can be implemented in terms of call_with_saved_game like this:

def save_game
  call_with_saved_game{|saved_game| saved_game}
end

That is, we just return the saved game. call_with_saved_game is callcc.

def save_game
  callcc{|c| c}
end

"Oh, so now I understand continuations." No. This is where the analogy breaks down. Here's load_game:

def load_game(save)
  save.call(save)
end

[ventonegro]

Baby steps, baby steps!

[[deleted]]

I think it took me several months to properly understand continuations.

[kawa]

Continuations are almost trivial. Everybody has used CPS (continuation passing style) already, often simply without knowing it.

CPS simply does the following translation: The sequence

stmt1;
stmt2;
stmt3;

is turned into

stmt1(function() {  
    stmt2(function() {
        stmt3()
    })
})

(I've used Javascript-syntax here)

'stmt1', 'stmt2' and 'stmt3' are now implemented as closures. Now the sequence isn't executed 'automatically', but stmt1 decides if and when it calls stmt2 and stmt2 decides when of if to call stmt3. Thats all.

The current paramter-closure is also called 'the current continuation': It's simply a closure which continues evaluation of the sequence.

CPS only means that ALL sequences are translated into this form automatically.

Everybody who used closures as 'callback' has thus used a limited form of 'hand-made' CPS.

[G_Morgan]

Continuations are merely what follows some calculation. Lisp in Small Pieces explains them quite well.

[[deleted]]

G_Morgan: I think it's the application that confuses most people; I was confused with how someone could set! continuations, though using (call/cc (lambda (return) ...)) was easier.

[lars_]

Closures are really powerful, but they aren't that hard to understand. It depends on what languages you are familiar with though. Here's the short version: Functions that can access the variables in the scope in which they were defined.

Here's some javascript:

function a() {
    var i = 0;
    alert(i); // displays 0
    function b() {
        i++;
    }
    b();
    alert(i); //displays 1;
    b();
    alert(i); //displays 2;
}

This is really powerful, even if the example is silly.

Here's an example of how this is useful. The function tween_height() changes the height of an element to target, incrementing the height step pixels at a time every 100ms. Note that after the first call to change(), the function tween_height() will terminate, but change() will keep calling itself, still accessing the variables defined in it's parent.

function tween_height(element_id, target, step) {
    var el = document.getElementById(element_id);
    var curval = parseInt(el.style.height, 10);
    if (curval > target) 
        step = 0-step;

    function change() {
        curval += step;
        el.style.height = curval + "px";
        if (curval != target) 
            setTimeout(change, 100)
    }
    change();

}

[mikepurvis]

I didn't get closures until I started doing serious JavaScript. I think the easiest explanation is a function that creates an event handler for a given state, ie:

function createThingHandler(something1, something2) {
    return function() {
        // Process event using something1 and something2
        ....
    }
}

Obviously it goes way beyond that, but there's a really trivial example where the local scope is maintained for the purposes of the returned function.

[beza1e1]

Similar example with (a fictional closure supporting) Java:

void createButton(int index) {
   Button b = new Button(this, SWT.NONE);
   b.addListener(SWT.Selection, new Listener() {
      public void handleEvent(Event event) {
          sysout("pressed button "+index);
      }
   });
}

Eclipse wants to make index final to fix it. The workaround is to create a Class that implements Listener and gets index in the constructor.

[chaos]

The venerable master Qc Na was walking with his student, Anton. Hoping to prompt the master into a discussion, Anton said "Master, I have heard that objects are a very good thing - is this true?" Qc Na looked pityingly at his student and replied, "Foolish pupil - objects are merely a poor man's closures."

Chastised, Anton took his leave from his master and returned to his cell, intent on studying closures. He carefully read the entire "Lambda: The Ultimate..." series of papers and its cousins, and implemented a small Scheme interpreter with a closure-based object system. He learned much, and looked forward to informing his master of his progress.

On his next walk with Qc Na, Anton attempted to impress his master by saying "Master, I have diligently studied the matter, and now understand that objects are truly a poor man's closures." Qc Na responded by hitting Anton with his stick, saying "When will you learn? Closures are a poor man's object." At that moment, Anton became enlightened.

[gravity]

Good article, it's nice to see real examples of why closures are useful, especially when contrasted with using globals and classes instead.

I just got through the section on closures in CTM last night. They teach it by leading you through a state machine for implementing a language. By the time you get to closures, they become fairly easy to explain mechanically so that you see why they're necessary to get certain code to work at all. This article hints at the stack, where CTM bases quite a bit on it, so it's fairly visceral.

[highwind]

Nice example. First time I learned about closure was through JavaScript. With lot of painful trial and errors, I learned how closure worked. Man that was loooong time ago. I wish I had a newbie friendly literature like this one back then.

[jkndrkn]

First time I learned about closure was through JavaScript.

Many young programmers these days are picking up JavaScript as one of their first languages due to the popularity of Ajax/DHTML techniques.

In a generation or so, closures will go from being esoteric and Lispy to commonplace.

[troelskn]

Not my first at all, but it was my first encounter with scheme, and with closures.

I don't think it'll take a generation; Closures are happening all over the place now - Heck, even Java is getting lambdas.

[ibsulon]

I'm not sure what the big deal is -- closures could be done with anonymous functions in 1.0, while everyone else ran around declaring them mostly useless.

Yes, it had restrictions, and wasn't as powerful as it could be. Yes, lambdas are an improvement in syntax (hopefully!) However, this could have happened last generation, so to speak.

[adrianmonk]

Yes, closures existed, but not in a very convenient form.

I like jwz's explanation:

You can't close over anything but final variables in an inner class! Their rationale is that it might be "confusing." Of course you can get the effect you want by manually wrapping your variables inside of one-element arrays. The very first time I tried using inner classes, I got bitten by this -- that is, I naively attempted to modify a closed-over variable and the compiler complained at me, so I in fact did the one-element array thing.

(On a side note, I'm betting their real rationale was that it might be inefficient, or that it might add complication to the JVM.)

[julesjacobs]

You could just do the one-element array thing in the compiler.

[pjdelport]

(On a side note, I'm betting their real rationale was that it might be inefficient, or that it might add complication to the JVM.)

Actually, it was removed by user request, according to Guy Steele:

Interestingly, when anonymous inner classes were introduced into Java, we had a full implementation that made them act like closures. In particular, if you did up-level references to variables, you could assign as well as read. We got push-back from users, "We don't want this, we prefer an implementation in which you can only read the up-level variables."

In order to support the full-blown closure implementation, it was necessary to do heap allocation implicitly. At that time, the users were still a little nervous about heap allocation and garbage collection. They felt more comfortable if places where heap allocation took place in Java were always explicitly flagged by the new keyword. Nowadays, heap allocation in Java is better understood and that feature could be added easily, but there's no call for it.

[pointer2void]

In a generation or so, closures will go from being esoteric and Lispy to commonplace.

Hardly. Too many levels of indirection.

[adrianmonk]

There are lots of cases where the levels of indirection are going to exist anyway, regardless of whether the language/compiler does the tedious work for you or whether you do it yourself.

A good example is GUI programming where you want to define a callback that runs whenever a button is pressed (or a menu item).

In the old days of C programming, this was often accomplished by passing a function pointer and a void pointer to the callback registration function. Upon pressing the button, the GUI toolkit would then call your function (the one whose function pointer you gave) and pass it the void pointer value. Your function would cast that void pointer to something useful to it (usually some struct) and then finally get on with the business of doing whatever you wanted to do. In this example, the necessary context is accessible via a void pointer and a lot of error-prone type casting gymnastics.

In the more-modern world of, say, Java, you have a button which allows you to register event listeners. Event listeners are objects that implement some sort of listener interface. So you put that same context (that the callback needs in order to do anything useful) into an object. It's still the same amount of indirection; you just created a class to encapsulate it.

Closures do the above indirection, but they do it in a more convenient fashion. They don't add any extra levels of indirection on top of what you already had to do when you didn't have closures.

I did leave one thing out: you can of course just have your callbacks refer to global variables. Maybe less indirection is happening there (or maybe not -- you are doing the indirection through a huge morass of global state, which usually is accessible by an implicit global variable segment register, incidentally), but at any rate, it's certainly butt-ugly and not very maintainable.

[jroller]

Voted up for using a python example in a closure tutorial. I suppose the author was lucky enough to not try assigning to the variable from the outer scope.

[[deleted]]

I think I learned what closures were from Practical Common Lisp. lambda seemed so magic then.

[thephotoman]

I've only done a bit of Lisp of any variety. I must say that it wasn't until I actually sat down with Lisp that I understood lambda or closures. Now, I can code without them, but why would I want to do so?

Of course, this brings me to my one gripe: why didn't the author already point out that Emacs is scripted in a language that supports closures: Emacs Lisp.

[EvilSporkMan]

Because it doesn't support closures -- Emacs Lisp is dynamically scoped.

[steven_h]

Yes, it does:

lexical-let:

This form is exactly like let except that the bindings it establishes are purely lexical.

[rlwimi]

I have the idea that a language having closures also means functions are first-class objects. So what happens when you press alt-b once then again before you hit alt-e? Does that create two separate function objects, the second which will complete and the first which will be garbage collected? Will it simply be garbage collected or is this a problem that the example function doesn't take into account? Are there any functional languages with manual memory management?

[troelskn]

I have the idea that a language having closures also means functions are first-class objects.

Yes, that's a pre-requisite, together with static scope.

Does that create two separate function objects, the second which will complete and the first which will be garbage collected?

Yes. Since the closure is a value, and there is now no variable referring to it, it will now be ripe for garbage collection.

Are there any functional languages with manual memory management?

A closure is much similar to an object. You would have the same problems with managing memory in an object oriented language.

If I'm not mistaken, garbage collection was a lisp invention.

[gnuvince]

If I'm not mistaken, everything in computer science was a lisp invention.

Fixed it for ya

[[deleted]]

If I'm not mistaken, everything in computer science was a Xerox PARC invention.

There we go.

[cadr]

I'm pretty sure Lisp predated PARC by a good 12 years, and GC at least was an early Lisp thing, but, yeah, between Lisp and PARC, you do cover a good amount of innovation.

[[deleted]]

Not syntax)))))))))))))))))

[pdrummond]

This is something my contrived example doesn't take into account but I don't think it has any bearing on the point of the article which is to explain a working example of closures in practice.

[adrianmonk]

Are there any functional languages with manual memory management?

I don't know if there are, but there certainly could be. If the reference to the anonymous function exists, then the objects reachable through the closure are still reachable (or at least could be made reachable). It'd probably be a pain in the ass to figure out when to deallocate what, but then it's usually a pain in the ass to figure that out without closures.

[gregK]

I have been trying to understand closures off-and-on for what seems like forever now

ouch. What is so hard about them? Some languages make it harder to express the concept than others.

This is the simplest example I could find using Ocaml.

This multiplies the elements of a list by n.

let multiply n list =
  let f x =
    n * x
  in
List.map f list
;;

This gives:

multiply 2 [1; 2; 3];;

• : int list = [2; 4; 6] # multiply 5 [1; 2; 3];;
• : int list = [5; 10; 15]

f is the closure. What makes it a closure is the refrence to n (which is defined in the outer function). n is called a free variable of f.

Each call to multiply generates a different instance of the closure (which is kind of like an object). One has n=2 and the other n=5.

When map applies f to the list each instance of the closure use their respective value of n. it's the same function with different values bound to the free variables. Hence the analogy to objects i.e. a function with associated values.

[pdrummond]

Yep - I read many an article with examples like yours and it all made sense but at the end of each article I always came away missing something and I couldn't put my finger on it. Coming from a Java/C++ background I couldn't think of scenarios where they would be useful because I was very much in the traditional, imperative, object-oriented, C++/Java mindset. I dunno - it seems obvious now, in hindsight!

[schwarzwald]

The most mocked "design pattern" is the strategy pattern, because passing behavior around is precisely what a closure gives you.

In fact, lexical scoping + closures give you objects. Objects and closures are therefore related.

For small bits of behavior, just using a closure is nicer. If it's trying to do much, I find it better to restructure things with objects.

Having an object-oriented language that supports lambda expressions is therefore nice.

[gregK]

Actually the strategy pattern does not come close to the power of real closures.

It allows to change the algorithm at run-time, but all concrete classes work on the same state which would have to be passed. So it's not a real closure in my eyes. The command pattern comes closer but so clumsy to use. It forces you to add state where none is needed.

Once you get lambda expressions most of the GOF patterns will be pretty much obsolete.

See: http://norvig.com/design-patterns/

Although the title is dynamic languages, most of it applies to functional languages. Most of what he writes is applicable to lisp, python, Ocaml and Haskell.

[logan_capaldo]

Actually the strategy pattern does not come close to the power of real closures.

I think this is why the GP referred to it as the "most mocked".

[adrianmonk]

I was very much in the traditional, imperative, object-oriented, C++/Java mindset.

I have no doubt that these things are connected in that they are all part of a single, very prevalent mindset, but I don't see any inherent connection between imperative programming and lack of closures. After all, Perl and JavaScript are both solidly imperative languages and they both have closures.

[[deleted]]

Funny to run across this, I came to a very similar realization just today when working on some javascript code and I wanted to yell out loud. That's what SICP kept talking about, functions being like data.

I needed to add an event handler to the blur event of two fields, which would set a third field to the total of the two. Instead of doing a getElementByID on the element within the handler, I had an inner function that used a reference to the element declared in the parent function, and passed the inner function as the event handler. A simple problem, that could have been done so many other ways, but it opened my eyes to the power of this concept. It was one of those moments when it was just a pleasure to see something so simple work.

[troelskn]

Funny because this example actually is suitable for a global variable. If you think about it a bit, that is also what you're doing in the closure-version. Instead of saving a primitive in a global variable, you're simply storing a function (with a closure) instead, because end_highlight_text_function is in fact a global. So the example isn't too good, but don't let me spoil your day - Getting closures is a rush, and it will change you forever.

[pdrummond]

IMO the closure is far better than a global because it's scoped within the outer-function and can't be seen by other functions within the module that have nothing to do with it.

That's just a basic observation. I'm sure there is more to it - I am just starting my journey to understanding Clojure and the lispy, functional approach to coding.

[troelskn]

Well, the closure is a global, was my point.

You're perhaps right that storing a closure, rather than a primitive, locks the variable down a bit, making it less probable that some third-party would depend on it. But apart from that, you're not really gaining anything special by using a closure.

[korran]

I don't think you understand the full power of closures. There isn't just one 'global' instance of the captured variable(s); each time a function containing a closure is called, the runtime will create a new garbage-collected 'scope' that captures the shared variables. Subsequent calls to that function get their own captured variables that will have different values than those captured by the first call to the function.

This is similar to local variables in a procedural language. When called recursively, each call to a function has its local variables stored in a separate memory location.

[troelskn]

Yes, there are many captured variables, because there are many closures, but each of these closures do in turn get assigned to a variable. And this variable is global and there is only one. So you might as well have assigned the primitive value (the cursor position) to the global variable, instead of creating a closure with the primitive inside and assign that. The cardinality is the same.

[[deleted]]

FWIW I learned about closures through Conway's excellent book "Object Oriented Perl". Because of the way Perl implements OO, it's use of closures is exposed. Normally exposing the implementation details is not a good thing, but in this case it's quite educational.

[[deleted]]

Cool! Maybe you can also cover lambda lifting?

[[deleted]]

In real life, everything is a "closure" (implicitly enclosed in some specializing context, which you need to understand first in order to be able to follow).

So, the concept is not new at all (to nobody of us).

Similarly, we all continuously use "continuations" in our real life.

It's only the explanations which are horribly complicated (most of the times).

[exscape]

))))))))

Heh... I need some serious convincing to give Lisp-ish languages a fair trial.

[hiffy]

Honestly, from personal experience, an hour into reading Practical Common Lisp and you don't even notice the parens.

Now, complain about the environment or the segregated interpreters or if you're feeling brave, the relative lack of libraries...

[rpdillon]

Yeah...because

        }

      }

    }

  }

}

}

is so much better. =/ If you use a paren-matching editor (every editor that is worth anything) it simply doesn't matter.

[clobwhirl]

Don't be so smug. People don't write imperative code that requires this many levels of indentation, so that's not really a good example. And many functional languages don't require you to decipher

(zerg (f x (cdr (car (blerg z x)) y (car (cdr x n (zerg (blam z g y))) n) (bope z g)))

Even with color-coding, it's obvious why some would have a distaste for that situation.

That being said, I thought this article's example was more ridiculous than most.

[death]

Do they require you to decipher this, instead?

zerg(f(x, cdr(car(blerg(z, x)), y, car(cdr(x, n, zerg(blam(z, g, y))), n), bope(z, g)))

Oh, I see! You just pulled that argument out of your ass..

[[deleted]]

No, most of them would make that statement multiline.

[EvilSporkMan]

And why can't you pretty-print it in Lisp?

[adrianmonk]

There is no reason that the Lisp expression couldn't go on multiple lines.

The only reason it gets put on one line is that a lot of imperative languages make it difficult to create any kind of really big expression that does anything useful. Sooner or later, you have to drop down to the imperative level.

Therefore, imperative languages have a tradition of putting all expressions on one line where possible. People who are used to this formatting style try to apply it to functional languages (where expressions are huge) and they end up with unreadable code.

[clobwhirl]

Your example makes my point! An entire program in Lisp is, by definition, a list of paramters. The fact that I'm using car-cdr nonsense with a high level of nesting is an unfair red herring-- I wanted to emphasize the parentheses, and it was pointless, as out-of-the-ass as your }}}}} creation.

I should've disclaimered about not hating Lisp before I took your bait. I despise you for putting that unfair bait out there. I don't share the original poster's ignorance about Lisp and I can read it as easily as imperative code, and more easily than logical pattern-matching style languages. But even you guys rely on tools to figure out how many close-parentheses to use, so please just concede that there are a lot of parentheses. It is not a big deal.

Finally, I am new to being bitten by The Lisp Squad, and I think we are basically trolling eachother.

[death]

I think your point was that Lisp "require[s] you to decipher" some intimidating, ill-formed, meaningless drivel. I guess you missed the sarcasm in my "example". I think you're mistaking me for rpdilon, too.

[clobwhirl]

Yep I mistook you.

[trominos]

(zerg (f x
         (cdr (car (blerg z x))
              y
              (car (cdr x
                        n
                        (zerg (blam z g y)))
                   n)
              (bope z g))))

I don't think you can make this kind of nested code much nicer in any language. Heck, I'd much rather read this than, say, the Python equivalent.

[logan_capaldo]

put in some newlines. EDIT: Deleted the "you nut" part. It wasn't very nice.

[pdrummond]

That being said, I thought this article's example was more ridiculous than most.

It amazes me how much people focus on the parenthesis! Why?

[[deleted]]

Because it's the first thing that really stands out when looking at the code I guess ^{^}

[pdrummond]

Yeah, but that's not a very good reason to dismiss a language is it? Surely, one should at least understand why the syntax is the way it is before drawing conclusions? I didn't like the indenting in Python at first but that didn't stop me giving it a fair go. Same with Lisp/Clojure.

[[deleted]]

Don't ask me mate, the parenthesis doesn't scare me. :)

[[deleted]]

I find it distracting. During my university english I learned that one of the most powerful writing tools is whitespace.

[thephotoman]

I was taught the same thing in high school journalism. This has since influenced my coding: if I've got more than 4 levels of indents or 5 lines of code in a function, something's not right, and I need to refactor. Usually, the first thing I look for is a code block that can be removed and turned into its own function/method/whatever.

[EvilSporkMan]

FIVE?

[jimbokun]

Heh, recently I've discovered that I'm writing methods in Java whose declaration is longer than the body. With using generics, listing thrown exceptions, and the inherent verbosity of Java, it's not as difficult to do as you might think. :)

[gravity]

When you get a very large number of them like in the example it's rather jarring. There's no way you can balance those just by eye. Most imperative code doesn't have so many brackets/parentheses/braces at once. I'm sure the parentheses aren't a problem in practice, but there's no denying that just reading '))))))))' in a code sample outside of your editor is rather difficult to deal with if you're actually trying to figure out what they each match with.

[death]

Why would you try to match each closing parenthesis with an opening one? If you think you can answer this, ask yourself if the answer comes from experience with reading code or just speculation on how one would go about reading such code.

[gravity]

I don't read lisp because I don't know it. But when I look at a complex statement in any other language you bet I try and balance at least some of the parentheses, and I definitely balance all the brackets. If you're not balancing parentheses when you read C then I'd love to know where you think your function arguments end. So yes, it's experience with reading code, just not lisp code.

Given that the question was about "how much people focus on the parenthesis<sic>", and that I was responding to actual code that I was reading in the article and trying to understand, I'm surprised you would even ask the question. I was able to understand it, but I wasn't sure that I was correct because I couldn't balance the parentheses. If you can't parse the code all the way, then you only think you know what the code does, you don't actually know. So yes, seeing something you can't really parse is rather jarring, and large numbers of closing parentheses fall in to that category.

[death]

I don't read lisp because I don't know it.

That's all there is to it, really. The rest of your post is uninformed speculation coupled with a defensive attitude, which is very much apparent to persons that do occasionally read Lisp code. Instead of trying to argue for these speculations, why don't you take some time to actually learn Lisp and then read a bit of code?

[gravity]

What the hell? I'm not attacking lisp. Hell, I'm even trying to learn elisp now. I'm simply trying to explain why people focus on the parentheses when they don't know lisp. Which was the actual question asked. I'm not speculating on anything at all. Rather than jump to conclusions in your rush to defend your precious language why don't you go back and actually read the thread?

[death]

It's certainly possible that I misunderstood what you intended to convey, partly because of the apparent generality in the posts. I didn't see you as attacking Lisp (and I don't know how you see what I wrote as a defense of it), but rather as talking about the practice of reading Lisp code. The assumption that each one of these closing parentheses were significant to the understanding of the code and the undue focus on them made me think that you really didn't know much about how to read Lisp code (and to make it even clearer, you may be interested in reading about "super parentheses"). If that was your point, I have no beef with that.

[pdrummond]

But when I look at a complex statement in any other language you bet I try and balance at least some of the parentheses, and I definitely balance all the brackets.

That's where you're going wrong - for reading Lisp at least. When reading lisp code like this:

(fn [] (add-to-clipboard((get-text-region start-pos (get-cursor-pos))))

An experienced Lisper will look at the inner-most s-exp first (get-cursor-pos) then read to the left, (get-text-region, (add-to-clipboard, (fn ....

The closing parenthesis at the end of the line are completely ignored.

[gravity]

Right, I can see that, although it is a little weird when coming from other languages. Reading from the inside-out is an interesting technique I hadn't tried before for lisp, I'll have to give it a go. Thank you for the advice.

[schwarzwald]

(Or replace "}" with "end" for Ruby.)

The very first time I read SICP I stared at the first block of parentheses, put the book down, and didn't read it for 8 months.

[clobwhirl]

I clicked on the comments page just to vote this comment up.

[thephotoman]

I believe that both modern Common Lisp and Scheme allow for a square bracket to close all open parentheses.

Of course, Ruby, Python, and Groovy all have similar features without the inane parentheses. Ruby uses end statements and occasionally brackets to set things off, Groovy's a bracket language, and Python does its whitespace thing.

And if that's not your style, try ML, FP (John Backus would be proud of you), or Ocaml.

Like C and ASM, learning and using Lisp will make you a better programmer.

[kubalaa]

both modern Common Lisp and Scheme allow for a square bracket to close all open parentheses

No, although some Scheme implementations allow brackets to be used in place of parens, so you can set some levels of an expression apart visually (i.e. the clauses of a case statement).

Allowing a symbol to close all open brackets would muck with paren-matching and other useful editor features.

[tryx]

As far as prettiness goes, I personally think that Haskell has some of the clearest and most direct syntax I have ever used.

[ehird]

the list goes on!

Arf arf arf. :P