[gjm11]

I don't think that's fair. Being able to implement if doesn't mean that the entire remainder of the system is built without any conditional instructions anywhere in its implementation. (The point, after all, isn't some sort of mystical purity; it's that if you can implement if then you can probably also implement whatever other control structures you happen to fancy. Which you can.)

[redxaxder]

To implement a usable if, you need to tie it to some form of logical branching. Haskell can tie it to pattern matches. C compiles them to conditional jumps in asm. The asm jump instructions are implemented in hardware. The meat of the if definition lies in how you tie it to whatever form of conditional behavior your language has. This is missing from the article.

Smalltalk (presumably) has a form of logical branching in it somewhere. To finish the if, just pick one.

For a satisfying conclusion, you want to use one that doesn't already look like an if statement.

[more_original]

> Smalltalk (presumably) has a form of logical branching in it somewhere. To finish the if, just pick one.

It uses dynamic binding.

In Java it would look like something this (but it's less useful without proper closures):

  abstract class Bool {
    void ifTrue(Runnable f, Runnable g); 
  }

  class True extends Bool {
    void ifTrue(Function f, Function g) {
      f.run();
    }
  }

  class False extends Bool {
    void ifTrue(Function f, Function g) {
      g.run();
    }
  }

Then, given a variable

  Bool b;

the if-then-else becomes

  b.ifTrue(new Runnable() {
      public void run() {
         System.out.println("It's true!");
      }
    }
  , new Runnable() {
      public void run() {
         System.out.println("Not true!");
      }
    }
  );

It's a bit more verbose, though...

[more_original]

s/Function/Runnable/g

[chc]

Actually, that really is how Smalltalk does if.

[pupeno]

In the blog post I include a screenshot of it... but my server is dying at the moment.

[JoelMcCracken]

The problem is that reading this seems very bait-and-switch-y. Basically, author is doing:

(define (my-if cond t f) (if cond (t) (f)))

(my-if #t (lambda () ....) (lambda () ....))

The trickyness about if lies in the order of argument evaluation. If you ignore that, then it is relatively easy to implement if in any reasonable language. Even C (I had to leave out the function pointer types, as I haven't worked with c in a few years, and forget the syntax):

void my_if(bool cond, t, f) { if(cond) { t(); } else { f(); } }

void if_true() { ... } void if_false() {

}

my_if(true, if_true, if_false);

Point being, I think redxaxder may have been coming from a scheme background, realizing that if needs to be a builtin. It would indeed be fancy to be able to implement an if that doesn't rely upon other logical branching, though!

[chc]

How is it "bait-and-switch-y"? Where's the switch? That is actually how if works in Smalltalk. The true block is evaluated when ifTrue:ifFalse: is sent to True and the else block is evaluated when ifTrue:ifFalse: is sent to False. It's just normal message dispatch.