(2 + (3 * (sqrt 4)))

  {2 + {3 * sqrt(4)}}

  (2 + 3 * (sqrt 4))

> yes

Wasn't the point keeping the names car and cdr so you can compose them? (I remember reading such in one of pg's essays.) Then it seems to me to take full advantage of that you need to provide those names for use.

I don't think it is unreasonable to do the following, but it is currently not provided in Arc:

arc> (cdar '((1 2 3) (4 5 6))) Error: "reference to undefined identifier: _cdar"

On the one hand, it does feel like all the c....r s should be there.

  car  --> hd
  cdr  --> tl
  caar --> inner
  cddr --> skip2
  cadr --> second

Thanks. (Not that I intend to vote anyone down :)

  (let numbers '(4 6 3)
    (+ 3 @numbers 7))

  [foo 'a 'b @^ 'c]

  arc> (= x [+ 10 _])
  #<procedure: x>
  arc> (prn:prn.x 5)
  #<procedure: x>
  15
  15
  arc> (prn:prn.x 5)
  #<procedure: x>
  15
  15
  arc> (prn (prn.x 5))
  #<procedure: x>
  15
  15
  arc> (prn ((prn x) 5))
  #<procedure: x>
  15
  15

  arc> (def add (x) [+ x _])
  #<procedure: add>
  arc> (map [prn:add.40:idfn _] (range 1 5))
  41
  42
  43
  44
  45
  (41 42 43 44 45)

So you might potentially have a printer that wouldn't attempt to remove parentheses, and a pretty printer that would do so to an extent.

(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.)

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.

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

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

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

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

   (if x
        m
       y
        n)

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.)

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

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

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)

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

  (mac identity (x) x)

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)

  (def + args
    ...)

  (+ . a)

For example, it should keep working if the 'a' in (+ . a) is replaced with its actual value. In that case, we get:

    (+ . '(1 2 3))

    (+ . (quote (1 2 3))

    (+ quote (1 2 3))

    (apply + '(1 2 3))

Granted, to do the equivalent of (+ @(foo)) you would have to do;

  (let temp (foo)
       (+ . temp))

Edit: I used to think that . and @ would only differ in the sense that cons and splice have different list building semantics, but now I believe that they should also differ in the timing of the operation;

  (+ . (foo))  -> (+ foo)
  (+ . '(foo)) -> (+ quote foo)
  (+ @(foo))   -> what we want, given that foo returns a list
  (+ @'(foo))  -> (+ 'foo)

    (+ . (f x y))

    (+ f x y)

  arc> '(x . y . z)
  (y x z)

Consider:

  (x . < . y)  is turned into  (< x y)
  (integer? boolean? . -> . void?) is turned into (-> integer? boolean? void?)