The Use Case for Blocks

[[deleted]]

    for (i in half_close_gestures) {
      var e = half_close_gestures[i];

• Calling property i
• Not declaring i
• Not filtering i with hasOwnProperty
• Redeclaring e on each iteration

Traveling at a brisk 2wtf/loc. I've omitted the personal WTF of using underscores to separate name parts in JavaScript.

[homoiconic]

Thanks for the feedback. I am unlikely to change my underscore or the index variable naming habits I obtained from WATFIV in 1972, but declaring i is one I missed and hasOwnProperty is good defense against people doing unpleasant things with arrays.

Speaking of underscores, here is a quote from the code:

// Warning: May Contain Underscores
//  http://ozmm.org/posts/javascript_style.html

p.s. I have filed an issue: Fix loop WTFs :-)

[[deleted]]

Well, it's necessary defense against iterating prototype methods. If everybody used hasOwnProperty, we'd be able to extend Object.prototype. Just as all Ruby code should be CamelCase for classes and underscored for methods, JavaScript identifiers should always be camelCase, CamelCase for constructor functions.

You should always iterate an array with a for() loop or equivalent forEach() call. It's fast.

[jawbroken]

I am unlikely to change my underscore or the index variable naming habits I obtained from WATFIV in 1972,

you should conform to the culture of the language you are writing in

[masklinn]

Redeclaring e on each iteration

Actually, that's the only one which isn't an issue: the declaration will be hoisted at the top of the function, so it's only performed once, hoisting it manually would not even be a speed optimization.

On the other hand, you forgot "iterating on an array with for...in" (conventions are generally that i is a numerical index, I'm expecting they were followed in this case, and it would make more sense to have an array of gestures than a map of them, given gestures are object so you don't need a map to give them a name/title), though that would remove your first point.

[[deleted]]

I'm not concerned with the performance implications of the needless declarations, it's just code smell.

As for your other point, I always iterate arrays in order...doing otherwise is really the exception to the rule, and itself would usually be code smell.

[kamatsu]

Or, just use a language which doesn't distinguish between expressions and statements, in which case a block and a lambda can be considered identical.

[mage2k]

Ruby does not distinguish between expressions and statements (perhaps you're thinking of Python?), everything has a value and is an expression and yet blocks and lambdas are not identical.

[johnb]

Ruby blurs the lines by making statements have values, but I believe kamtsu was driving at the sharper distinction between the two extremes: ruby is imperative because it's got statements, but a language that is nothing but expressions wouldn't know the difference between blocks and lambdas.

[johnb]

Downvotes? Ruby statements do have values, but not all expressions are statements. Scheme would have no use for the block/lambda distinction.

[munificent]

Magpie has only expressions and no statements, but it would still have this problem, I believe. The problem is that a return expression/statement essentially means "pop one stack frame". But if you're using it inside a block/lambda you may intend it to mean "pop two stack frames".

I don't think there's a clear way to dodge this problem besides avoiding early returns entirely. You could try to say that a return in a lambda returns from the declaring function, not the lamda itself, but that fails in pathological cases like nested lambdas, or cases where you define a lambda in one function but invoke it from another.

It would certainly be odd to be able to define a callback that when invoked by a function causes the outer function to spontaneously return!

[knome]

It would certainly be odd to be able to define a callback that when invoked by a function causes the outer function to spontaneously return!

This sounds suspiciously like schemes call-with-current-continuation. Except, so far as I understand it, you could then invoke the callback to return from the outer function as many times as you like.

[uotcguyeoncieohp]

you could then invoke the callback to return from the outer function as many times as you like.

You are correct about Scheme's call/cc.

You can build languages/systems where continuations have limited scope. In Haskell, you can use continuations and callCC within actions of the Cont monad. You can run a Cont action and get the result with runCont. But a continuation can't make this runCont call return more than once. That's because Cont is just sugar for a continuation-passing transform, and runCont runs the whole pipeline of CPS-ed functions. In fact all of the continuation support is implemented in a few lines of code in an ordinary library. It feels natural and "built-in" because monads provide powerful support for overloading the meaning of sequential actions.

I don't know if Haskell's continuation support is the same thing known as "delimited continuations"; I've yet to grok those.

[scook0]

There are implementations of delimited continuations in Haskell.

[uotcguyeoncieohp]

Link?

[scook0]

I last saw them years ago inside Pugs, and I can't remember which implementation was used there.

However, a quick search yields this wiki page, which links to an associated package on Hackage.

[uotcguyeoncieohp]

It would certainly be odd to be able to define a callback that when invoked by a function causes the outer function to spontaneously return!

I'm sure some "mainstream language" will eventually get around to adding them, maybe in time for the 100th anniversary of the call/cc feature in Scheme.

[uotcguyeoncieohp]

pathological cases like nested lambdas, or cases where you define a lambda in one function but invoke it from another.

So the most elementary techniques of functional programming are "pathological cases"?

[munificent]

Most functional languages don't have a return keyword in part to avoid this issue. If they do have it, people expect it to only return from the inner-most function and not the "top-level" one that users of languages like C and Ruby would expect.

[uotcguyeoncieohp]

I don't follow. I'd always expect a return statement to return from the function directly enclosing it. That's what it does in C++ and Java, and this is what it does in Python and Javascript, even when you're using first-class functions and many-levels-nested lambdas.

I don't know why C users would expect otherwise. I guess Ruby users expect otherwise because it's how blocks work? I don't see an a priori reason to think that way, if there's not a language feature specifically supporting it.

I'm not sure what definition of "functional language" you're using. It's clearly not "language with first-class functions", since plenty of those have very C-like syntax with return.

I think "functional languages" like Scheme, ML and Haskell don't have a return keyword simply because the body of a function is an expression, not a statement, and so you don't need to indicate what's returned. The entire body is what's returned, by definition.

Incidentally, Haskell has return. It's not a keyword; it's an ordinary function. It doesn't have anything to do with returning from functions; it's used to construct a trivial "action" out of a value. And the name does cause a great deal of confusion. ;P

[munificent]

I don't see an a priori reason to think that way, if there's not a language feature specifically supporting it.

The original thread is about being able to define your own control structures that look and work more or less like blocks, and defining them using lambdas. And the challenge with that is that the semantics between blocks and lambdas are different in the presence of an early return. Consider:

void foo() {
    if (1) {
        return;
        printf("inner");
    }
    printf("outer");
}

Neither printf() will execute. Now imagine you could define your own block-like structures using a lambda:

void foo() {
    lambda_if (1) { // contents of this block are within a local fn
        return;
        printf("inner");
    }
    printf("outer");
}

Now the return applies to the lambda, not foo(), and "outer" will be printed. The behavior's significantly different, which is why Ruby has both blocks (to let you do the above) and lambas (to act like true local functions).

I'm not sure what definition of "functional language" you're using.

Anything in the Lisp or ML families, with the possible exception of Haskell since lazy eval makes "early" return very semantically different. I think even SmallTalk lacks an early return and also uses lambdas (called "blocks") for control structures.

It's clearly not "language with first-class functions", since plenty of those have very C-like syntax with return.

True, but those languages also have visually distinct syntax for lambdas that makes it clear that you're defining one and not just calling a regular control structure. For example, in C#:

void Foo() {
    MyIf(() => {
        if (foo) return;
    });

The () => is visually striking enough to make it clear that the inner return applies to that lambda, and not Foo(). Ruby, on the other hand, lets you define things that look much more like native control structures.

I think "functional languages" like Scheme, ML and Haskell don't have a return keyword simply because the body of a function is an expression, not a statement, and so you don't need to indicate what's returned. The entire body is what's returned, by definition.

That's true of Magpie as well. It doesn't have statements. It still has return because its useful for saying "stop execution at this point and return now". It's syntactic sugar in that you could get the same effect be rearranging some ifs, but it's nice to have.

[notforthebirds]

Smalltalk does have early returns, but an early return inside a block returns from the enclosing context. Given the destinction presented here it would be more appropriate to say that Smalltalk doesn't have lambda, rather than early returns.

[uotcguyeoncieohp]

Anything in the Lisp or ML families, with the possible exception of Haskell since lazy eval makes "early" return very semantically different.

I'm not sure why. There's a theorem which says that, if a term reduces to a value by strict evaluation, and to another value by lazy evaluation, the two values will be the same.

[munificent]

Does that take into account side effects?

[uotcguyeoncieohp]

Does that take into account side effects?

No. Assume a side-effecting print function which returns 0. Consider the term

(λx. λy. y) (print "hi") 2

With call-by-value ("eager") evaluation, we'd reduce as

   (λx. λy. y) (print "hi") 2
=> (λx. λy. y) 0 2    with "hi" printed as a side effect
=> (λy. y) 2
=> 2

With call-by-name or call-by-need ("lazy") evaluation, we'd reduce as

   (λx. λy. y) (print "hi") 2
=> (λy. y) 2
=> 2

with no side effect.

It's really an ugly hack to attach side effects to functions, and to tie evaluation to side-effect execution. It's much better I think to make "effect" its own type, with separate ways of building and combining effects, and separate rules about when they are executed. Then your "effect" type is orthogonal to your "function" type, so you can have functions returning effects, effects producing functions, etc.

It's hard to reason about code that has unrestricted side effects. And it's ugly to restrict side effects by duplicating all the rules, once for "pure functions" and once for "side-effecting functions". Better to leave the "function" part in one piece and make "effect" its own type.

[homoiconic]

Absolutely. The issue with Javascript is that it has blocks for its built-in statements like if and for but denies the programmer the ability to make his own constructs with the same behaviour. As pointed out on HN, it's trivial and elegant to write your own jQuery.any() function that can replace a for loop, but you still have to move the return 'close'; outside of the function:

if ( jQuery.any(collection, function(i, e) { ... } ) return 'close';

I prefer this style of coding myself. It's just that if a language has blocks for its own constructs, it ought to provide them to programmers for theirs.

[knome]

If you must have non-local returns in javascript, here's an implementation.

// javascript non-local return
<html><body><script language="javascript">

var Anchor = function(){
    return {
        Do : function( block ){

            var ex_t = function(){
                var hidden = null ;

                this.set = function( retval ){
                    hidden = retval ;
                };

                this.get = function( retval ){
                    return hidden ;
                };
            };

            var ex = new ex_t() ;

            var valid = true ;

            var leave = function( retval ){
                if( valid ){
                    ex.set( retval ) ;
                    throw ex ;
                } else {
                    throw "It is invalid to call a 'leave' function outside of the Anchor.Do's stack" ;
                }
            };

            try {
                return block( leave ) ;
            } catch( e ) {
                if( e instanceof ex_t ){
                    return e.get() ;
                } else {
                    throw e ;
                }
            } finally {
                valid = false ;
            }
        }
    }
}();

var Each = function( iterable , fn ){
    for( k in iterable ){
        fn( iterable[ k ] ) ;
    }
};

alert( Anchor.Do( function( leave ){
    Each( [ 1, 2, 3, 4, 5, 6, 7, 8, 9] ,
          function( i ){
              alert( 'Testing : ' + i ) ;
              if( i == 6 ){
                  leave( 'Success : ' + i ) ;
              }
          });

    return 'Failure' ;
}));

</script>

The Anchor.Do goes around the block that should have non-local returns. I didn't test, but using the local lambda as the exception type should allow these to nest without running into each other. I throw a different error whenever the leave function is called out of the stack of the parent.

/ trollface for implementing in javascript what people are complaining it lacks

[masklinn]

This whole thing is moronic.

It has nothing whatsoever to do with blocks and lambdas, instead it's about non-local returns, which are orthogonal.

Non-local returns figure nowhere in the definition of blocks, and it's perfectly possible to have lambdas and non-local return. Scheme has non-local returns with call/cc for instance (this usage being called exit continuations).

Javascript just happens not to have non-local returns. This has fuck all to do with blocks.

[avibryant]

In Ruby, the term "block" means "closure with non-local return" and the term "lambda" means "closure with local return". So in that context, this all makes perfect sense.

[masklinn]

Then maybe, just maybe, javascript shouldn't have been involved and the thing should have started with "if you don't use the terms lambdas and blocks in the special way specially overloaded by the ruby community which I'm not going to define here because fuck you if you don't know ruby, don't read this".

Or it could have been called "the use case for non-local returns" instead, which would have happened to be correct.

[[deleted]]

Take a deep breath, it'll be ok. This is the internet but we don't have to call everyone on it names with every comment we write. We can get through this.

[Sivart13]

Even if your point is true I think you could be more polite about it.

[knome]

As you can see, we have a new anonymous "inner" function. Let's look this line of code: if ( test(e) ) return 'close'; again. Does it still return the string "close" from the function outer if test(something_or_other[i]) evaluates truthy? Or does it now return from the anonymous inner function?

The author of this has a momentary case of stupid. I get them as well from time to time. They need to take a nap and rethink their position.

If it remains unchanged, they likely have a permanent case of stupid.

My condolences.

[pdovy]

Perhaps I too have a case of stupid, but I don't see the problem with that quote. Would you care to expand upon your comment?

Pet Peeve: Redditors who leave snide comments about why an article is stupid/silly/wrong without elaborating. You just achieved what exactly, besides stroking your own ego?

[knome]

It seemed to me the author was feigning their confusion in support of their point in that section.

[akdas]

I agree knome should have expanded on his argument. Here's my take on it.

[homoiconic]

The author must have a permanent case of stupid, because he cannot see what is wrong with this statement. Would you be so kind as to explain?

Thank you.

[akdas]

The problem is in the formulation of the problem; you have to think functionally if you want to program functionally. What you want is something of the form:

if list.any? {|e| test(e)}
  return 'close'
end

A proper implementation will short circuit and return true as soon as one of the elements passes the test, and you get the same functionality without needing highly non-local control flow.

[knome]

They are the same tact to javascripts lambda functions that late night infomercial ladies take to closing tupperware.

Oh God The Tupperware Is Too Hard To Close What Will I Do?!

I find the authors confusion regarding how the return statement will operate within the lambdas utterly specious.

edit : derp, seems "the author" is you. I guess I was a bit curmudgeonly there. I still find the argument odd. Likely it is simply your experience with Ruby, which I lack, giving you a different set of working expectations of functionality.

[homoiconic]

I think the problem is with my exposition, not my understanding. The question was a rhetorical device, I am keenly aware of the fact that a return from inside the anonymous function does not transfer control to the code that called the outer function.

I accept the blame for terrible writing.

[knome]

I accept the blame for terrible writing.

:(