Arc Forum | Optional Parenthesis

Arc Forum

7 points by EliAndrewC 5928 days ago | 11 comments

In his essay "Arc at 3 Weeks", Paul Graham said, "We also plan to let programmers omit parentheses where no ambiguity would result, and show structure by indentation instead of parentheses."

This sounds absolutely wonderful to me, because it lets me turn code such as

(def f (x y) (let z (* x y) (* (- z x) (- z y))))

into

def f (x y) let z (* x y) * (- z x) (- z y)

I don't know whether my indentation will even show up, but I think the point is clear. I'm aware that most Lisp programmers don't care about having lots of parenthesis, but this really matters to a lot of people.

Are there still plans to allow for this in the future as Arc gets more mature, or has that idea been scrapped completely?

2 points by cje 5927 days ago | link

Parens are an issue -- you need to have all of them. Omitting some parens under some circumstances makes the code slightly shorter, but at the expense of partially hiding the structure of the code.

But here's the real problem: the reader has to understand the forms where parens can be omitted. If you write a macro that creates (def ...) forms, you can't elide the parens around it, because the reader doesn't know it can.

-----

2 points by EliAndrewC 5927 days ago | link

Well I agree that we should only omit parens where it's 100% unambiguous where the actual parens would be. There'd need to be a very small number of simple rules/exceptions (such as "every new level of indentation denotes an extra parenthesis unless ____").

A few years ago Paul Graham seemed to think this would work. However, it may be that he tried it and found that it would be too problematic. I'm hoping that he simply has been too busy to implement it so far.

-----

3 points by daivd 5928 days ago | link

I second this proposal. Somewhere in the tutorial (or in the announcement?) Paul quoted that "Code should be written for people to read". When you write pseudo code, you don't litter your code with parentheses. Just as when you write math, you use infix where possible.

I realize that having no separation between data and code representation is really neat when you do macros and other types of meta programming, but I think we can have our cake and eat it too. What I am aiming for here is a language that looks like, say, Python (no need to get religious here, but Python is damn easy to read and you know it), but with an optional "strict" LISP syntax, that I can use when I need it.

It seems to me that all we need is a simple preprocessor that converts "code style" to "data style" representation.

-----

2 points by EliAndrewC 5928 days ago | link

Right; my impression was always that Arc would basically just insert the parens for you on every level of indentation.

-----

2 points by roger_purves 5927 days ago | link

On "code should be written to read":

I like scheme a lot; and the parentheses never bothered me. But one device which could provide a gradual path through the thicket of parentheses, and perhaps make Arc more inviting to beginners, would be the:

        hide/show invisibles

of word processors. There could even be levels:

       hide/show some invisibles
       hide/show more invisibles
       hide/show all invisibles

Roger Purves

-----

1 point by EliAndrewC 5927 days ago | link

Yeah, personally I don't really care whether this is even a language feature or an editor feature. The ability to hide/show more or fewer is certainly interesting.

-----

2 points by EliAndrewC 5928 days ago | link

Since the indentation didn't come through, here's a link to what it should look like:

http://pastebin.com/f4a6cfbd6

As for parens not mattering, I agree that they don't matter all that much when the code is being written due to editors taking care of it. But I find that the code that uses whitespace to replace some parens to be much more readable.

-----

3 points by randallsquared 5928 days ago | link

For people who aren't used to lisp,

def f (x y) let z (* x y) * (- z x) (- z y)

is awful, especially since they'll automatically group "(* x y) * (- z x)" as an expression. :) But maybe your indentation fixed that.

-----

2 points by sjs 5927 days ago | link

I'm almost certain that Eli meant to write:

    def f (x y)
      let z (* x y)
        * (- z x) (- z y)

-----

1 point by EliAndrewC 5926 days ago | link

Exactly so, thank you. I've since Googled to find how to do code formatting, so I shouldn't have this problem in the future. Thanks for posting the correct code.

-----

2 points by janderson 5928 days ago | link

Parens don't matter to anyone who uses a decent editor. Try (I think) "M-x lisp" in emacs (or, even better, install slime) or ":set ai lisp" in vi.

With parens, emacs and vi will auto-indent your code for. There's no need to think about it, and, since they also highlight matching parens, there's no need to think about that, either.

Without parens....well, I hope you're good at hacking elisp, 'cause otherwise you're going to waste a lot of time manually indenting your code.

-----