Creating a Swift syntax extension: the Lisp 'cond' function

Interesting idea. We can support unlimited cases by using tuples and varargs, though the fallback has to be the first argument if we don't want to return an optional:

    func cond<T>(#fallback: T, testsAndExprs: (test: @auto_closure () -> Bool, expr: @auto_closure () -> T)...) -> T {
        for (t, e) in testsAndExprs {
            if t() {
                return e()
            }
        }
        
        return fallback
    }

And in use:

  // y is assigned "0 == 0, of course"
  let y = cond(fallback: "fallback", (test: false, expr: "not this branch"), (test: 0 == 0, expr: "0 == 0, of course"))

Incredibly cool hack.

But i'm going to be the first one to point out that having function arguments not evaluated at call time is very, very unintuitive. Anyone with a background in traditional (procedural/OO) languages is reasonably going to expect both `perform_side_effects` calls to be invoked here.

    var ctest = cond_1(a == 1, 2 + perform_side_effects1(),
                       a == 2, 3 + perform_side_effects2(),
                       0)

> In Lisp, cond works as follows:

> ...

> Much like a switch statement,

No. cond is nothing like a switch statement. cond is Lisp's version of if..else if...else if..else.

The distinction being, of course, that if you have a contiguous range of cases in your switch statement, a proper C compiler will compile it to an O(1) jump table, rather than an O(n) set of tests like an extended if-statement. This is so crucial and basic a distinction that I am astounded every time I find another person claiming that cond==switch.

The closest thing that Lisp has to a switch statement (and this is a significant failing in the language) is CASE. And that's only if you are careful and have a very smart compiler -- not sure if SBCL will jump-table it for you, for example.

That @auto_closure annotation seems to work exactly like D's `lazy` keyword, transparently wrapping the passed-in value in a closure. Pretty cool that more languages are getting built-in support for laziness.

And... shit like that is why features like operator overloading or this @auto_closure attribute are a bad idea.

I sympathize with the idea of creating a language mostly defined as a library of itself.

It's nerdy, it's neat, it's minimal, it's very Lattnerish.

But it has a fatal flaw: it assumes people will use that feature set in an intelligent, restrained, minimal way. For good.

And let's face it. Most of us devs are fucking morons. It took people only a few days to start abusing it. I wonder where we'll be a year from now.