Confusion over new lily blocks (dangling else problem)

[Brian Callahan]

So we have this commit: 94674cc

The problem it solves is great. The dangling else problem sucks. But it has (at least for me) created new sources of ambiguity and confusion.

Let's take the follow sample snippet:

if a == 1: {
    return 1
elif a == 2:
    return 2
else:
    return 3
}

Perhaps this is my being a C person coming through, it is not obvious at all that the code under the elif and else will ever be run, despite the fact that (I think) Lily is trying to tell me that it will if a isn't 1. The way I read it, if a isn't equal to one, control will go to the }, not to the elif or the else.

It does definitely look better when you nest several layers deep:

if a == 1: {
    b = 2
    if b == 2: {
        c = 3
        if c == 3: {
            return 0
        else:
            return 1
        }
        return 2
    else:
        return 3
    }
    return 4
else:
    return 5
}

But still looks (to me) like if a is not equal to 1, then you do nothing instead of return 5.

I get not necessarily wanting to look like C, but I've also never seen another programming language with this definition of a block (and in fact, editors like vi and emacs with brace matching may in fact confuse the user as well), which makes me wonder if the deviation harms readability (and thus, sadly, adoption), even as it solves the problem it intends to solve.

Of course, I have no diff so I have no leg to stand on about this other than as someone interesting in using Lily.

[FascinatedBox]

It's not just you wondering about it. It's a common-ish question when I discuss the language, right next to making an llvm/jvm/etc. backend.

The Zimbu language ( http://www.zimbu.org/ ) has a similar bracing idea. One brace for all blocks, but for some reason there's no opening braces. Zimbu has quite a few ideas like that which I don't get. In terms of more mainstream languages, I don't think there's a parallel to Lily.

I like the bracing structure because I can have a single brace for an entire block. Suppose that, in a C-like language, I want to expand a single-expression section. I have to stop, put braces around it, and do what I want. If I want to add temporary debugging, sometimes I may need to remember to un-brace if I added temporary braces to wrap some call in an expression.

Less braces floating around means there's less likelihood of having an unterminated brace. Or a mismatched brace, the latter of which can cause more problems.

As for code folding, that's not a feature I use in my editor of choice, so I can't speak on that measure. But I suspect that given Python's popularity, that there's code folding for it. That might be a good start for doing folding on Lily code, assuming Lily becomes popular.

I'm also a fan of how having fewer braces makes code more dense. More instructions floating around, less syntax that doesn't

[Brian Callahan]

Thanks for the explanation!

[Brian Callahan]

Closing I guess? Not sure there's anything left to do here.