Arc Forum | Arc Indentation Syntax

Arc Forum

Arc Indentation Syntax

8 points by eds 5919 days ago | 18 comments

About a week ago there was discussion of a Python-like indentation syntax for Arc (http://arclanguage.org/item?id=374). Today, just for the fun of it, I tried coding a function that would read in text and return an expression with the white space of the input interpreted as nested lists. Thus typing:

  def foo (a b c)
    spam a
      eggs b
        ham c

Creates the following expression:

  (def foo (a b c)
    (spam a
      (eggs b
        (ham c))))

Where every new level of indentation is interpreted as a new expression.

Unfortunately, seeing as I am more familiar with Common Lisp than Scheme, I wrote in CL, so you can't actually try the new syntax in Arc (yet). And my code is probably pretty buggy, as I just wrote it in a couple of hours. But for what it is worth, you can get my code and try it out in your favorite CL implementation:

http://blackthorncentral.net/files/read-indentation.lisp

3 points by sjs 5919 days ago | link

I'm all for something like this, but it's tricky. SRFI 49 looks pretty good but I have not tried it.

There are some thoughts here[1], though I don't like how he's moved the procedure outside the parens to match algol-like languages and I don't like the curly braces stuff either.

[1] http://www.dwheeler.com/readable/

-----

3 points by fallintothis 5918 days ago | link

This keeps getting brought up, but apparently it's an idea that's already been scrapped for Arc:

"I spent a couple days working on getting rid of parentheses, and it got really ugly." -- http://news.ycombinator.com/item?id=35795

-----

5 points by pg 5918 days ago | link

I just posted that code: http://arclanguage.org/item?id=2003

-----

3 points by parenthesis 5917 days ago | link

Perhaps this idea should be a text-editor feature rather than a language one: the editor can be set to automatically add parentheses based on indentation.

This seems such an obvious idea, either it is actually hopelessly flawed, or else it has already been implemented by someone somewhere.

-----

3 points by ryantmulligan 5919 days ago | link

The reason I do not like this is that you are enforcing line breaks and whitespace, and this creates an asymmetry between the reader and the writer. Are you going to force the writer to return lisp code this way? What about lisp lists?

-----

2 points by eds 5918 days ago | link

Ok, I did a little more hacking, and made a Scheme version of the function I coded in CL earlier. Still nothing near usable, but it is enough that in about half a dozen lines of code you can hack ac.scm to use it instead of Scheme's normal read function. And because the function leaves normal lists alone, you can use it to load the normal arc.arc definitions without any problems.

(Note: if you actually want to try this, in addition to just adding (require "read-indentation.scm") and changing various instances of (read) to (read-indentation), you probably want to add (flush-output) after the (display "arc>") in the toplevel definition, or the REPL you'll get will be extremely messed up.)

http://blackthorncentral.net/files/read-indentation.scm

-----

2 points by soegaard 5919 days ago | link

Hate to be a kill-joy, but this sort of thing will most likely not catch on. Take a look at SRFI 49 and then - if you dare - try googling for comments on SRFI 49.

http://srfi.schemers.org/srfi-49/srfi-49.html

-----

5 points by eds 5919 days ago | link

After a 15 minute search of the comments, I see that there seem to have been a small group of very strong objectors to SRFI 49. (Ok, maybe a more complete search would have reveal more objections, but really, I couldn't find that many.)

Anyways, I don't particularly see that as a reason not to try the syntax at all.

In particular, I don't see how this syntax would be a Bad Thing. I mean, Python uses such a syntax, and so do other languages. And Python hasn't gone down the tubes because of its use of an indentation based syntax. So why can't a Lisp use such a syntax? The conversion between normal S-expressions and indented expressions (or I-expressions to use the SRFI term) is fairly straight forward, the code looks almost exactly the same minus the parentheses, and you can even interface with the traditional reader such that expressions of the typical (...) form read in normally (this is in fact what my code does). In short I don't see a significant difference between Python and Lisp that allows Python to use the indentation and not Lisp, except possibly that Python has to define an entire syntax to accomplish this and Lisp only requires a single function to be defined.

I'm not claiming that my code will amount to anything (I would be very surprised if it did), but I am saying we shouldn't dismiss the indentation based syntax out of hand.

-----

1 point by almkglor 5919 days ago | link

For traditional Lisp (cond ...) forms, it will actually look pretty good:

  cond
    (test)
        (exp)
    (test2)
        (exp2)

However, for Arc-style if's, you can't use that - you have to:

  if
   (test)
   (exp)
   (test2)
   (exp2)

-----

2 points by eds 5919 days ago | link

Yeah, if's look like a problem with my current system. Although I would make a couple of comments on what you have above. With the current conversion, you don't need the parentheses in the second version:

  if          --->    (if
    test      --->      (test)
    exp       --->      (exp)
    test2     --->      (test2)
    exp2      --->      (exp2))

Not that doing so makes it much better, because you still can't indent the expressions beyond the tests (and you can't indent the final default case either). On the other hand, if you kept the parentheses, because starting a line with a list turns off the conversion in my current system, you could do a more traditional style:

  if
    (test) (exp)
    (test2) (exp2)

Which would get converted to the same thing. But that isn't really satisfactory for longer if statements, with tests and expressions that take a full line each, and with enough cases that different indentation for test and expressions is needed to make the thing readable. So the syntax would probably need some significant revisions before it would be actually usable in code of any significant size.

-----

3 points by almkglor 5919 days ago | link

Another nitpick: how would you translate this to your syntax, then?

   (if x
        m
       y
        n)

BTW a bunch of people (mostly started by David Wheeler) have been discussion such syntaxes. See:

https://lists.sourceforge.net/lists/listinfo/readable-discus...

-----

1 point by eds 5918 days ago | link

Considering the expression above is trivially small it would be easiest just to leave it as is. (My program doesn't mess around inside lists, it only tries to interpret free symbols at the top level of input.)

But I think I know what you are really getting at, because when the single letter symbols above are more complex expressions, converting the above gets much more difficult. The fact is, in a system where indentation is significant, you can't make arbitrary decisions about indentation to make the code look the way you want. So either you have to line everything up equally so you can't distinguish between test and expression, or you need to come up with some fancy indenting rules that somehow know what an if expression is supposed to look like. I don't particularly like the former, and I'm to lazy to really work on the latter, so that leaves us with just having the badly formatted if expressions. (Unless someone else can think of something. Maybe that discussion does, but I don't entirely have time to look through their archives right now.)

But at the very least I am having fun messing with Arc internals, so not all is lost.

-----

3 points by almkglor 5918 days ago | link

Actually no - the problem is that you said:

  if          --->    (if
    test      --->      (test)
    exp       --->      (exp)
    test2     --->      (test2)
    exp2      --->      (exp2))

So, what if I need the variable test, not the function test? Suppose instead I have something like this:

  (if
    test
       (exp
          (exp2
             (very-long-exp3 5 6 7 8))
          (some-random-exp4))
    test2
       (exp5
          (exp6)
          (exp7)))

If a naked symbol all by itself becomes (symbol), how do I format the syntax if I need symbol, not (symbol)?

-----

2 points by eds 5918 days ago | link

Yeah, I don't know what to do about that one. I've been thinking about it for a while, I just didn't know that was what you were asking.

I can't see any way to make indentation show you need just a symbol and not a function call with no arguments. You could add symbols, but that works against the removal of the parentheses in the first place.

Its a bit of a hack but if you had a simple read macro for an identity function you could do it. (Quote doesn't quite work because it prevents evaluation.) But say you had a function identity like such:

  (def identity (x) x)

And you defined a CL style read macro (e.g. $) to expand to (identity x). Then in my current function, because the read macro would expand before checking the subexpression to see if it was a list or not, you could do the following:

  if
    $test
      exp
        exp2
          very-long-exp3 5 6 7 8
        some-random-exp4
    $test2
      exp5
        exp6
          exp7

Which basically exchanges all the parentheses in the traditional version for a identity macro. Of course, it isn't exactly the same because you are adding extra meaning (the call to identity) to the expression. But maybe you could make it a macro instead of a function, and do the expansion at compile time (although this is dangerous because if you expanded the macro too soon you would defeat the purpose of using it in the first place...):

  (mac identity (x) x)

On the other hand you could alway just use traditional s-expressions in the middle of significant-indent code. The goal is to make parentheses optional, not to remove them entirely. Sometimes it may just be more convenient to leave them in than take them out.

-----

1 point by eds 5918 days ago | link

I just thought of another solution which might fix this problem without needing any special syntax characters.

If you consider that the reason we know to add parentheses around structures in the first place is the indentation of forms below the current line, then it is ambiguous whether a form with no nested forms should be wrapped in parentheses or not. If the system then does not assume the innermost forms are function calls, then it solves the problem of interpreting literals as function calls. Thus you can now do this:

  if
    test
    exp
      exp2
        (very-long-exp3 5 6 7 8)
      (some-random-exp4)
    test2
    exp5
      (exp6)
      (exp7)

Which cleans up many parentheses (removing all parentheses was never our goal in the first place), and doesn't result in the extra parentheses that were a problem before.

I found that it was trivial to implement this in my previous code. You can find the updated version at: http://blackthorncentral.net/files/read-indentation.scm

-----

1 point by almkglor 5917 days ago | link

Note that the above syntax is already what is pretty much the basis for all i-exprs in the mailinglist I posted, which is the main reason I posted the mailinglist.

-----

2 points by soegaard 5919 days ago | link

Small group?

Here is a challege: Find one (just 1) example where srfi 49 is used.

-----

1 point by offby1 5919 days ago | link

this is The Meme That Will Not Die

-----