Arc Forum | fmota's comments

Arc Forum

new | comments | leaders | submit | fmota's comments

9 points by fmota 6140 days ago | link | parent | on: The proposed : syntax

Another possibility (with pg asked me to post here) was to use : as a low-precedence infix apply operator.

I mentioned it at [http://reddit.com/r/programming/info/6710p/comments/c0317pb]. Here's the text:

----------

When programming in lisp you tend to accumulate parens on the right. One way to virtually eliminate this is to have a very low precedence infix operator apply, like Haskell's $. I used : in Atom:

Atom code - `(op: / _ 2)`

Arc code - `[/ _ 2]`

It also opens avenues to python-like block indentation syntax. For example...

Atom code:

    def (fact n):
        if (= n 0):
            1
            * n (fact: - n 1)

Arc code:

    (def (fact n)
        (if (eq n 0)
            1
            (* n (fact (- n 1)))))

This makes programming in Atom very different from programming in other Lisp dialects, but it's a feature I'd kill for... If Arc had it, I wouldn't have to design Atom. :P

----------- And then I clarified the meaning of the last example: -----------

Each line in the indented block is added to the if's line. For example:

    foo:
        bar
        baz

Is the same as:

    foo bar baz

And

    + 1:
        * x x
        * y y

is the same as

    + 1 (* x x) (* y y)

So, you see,

    if (predicate):
        (then-instr)
        (else-instr)

Is the same as

    if (predicate) (then-instr) (else-instr)

-----

2 points by bayareaguy 6139 days ago | link

Something doesn't look right here. I think I know what you're trying to propose but if

    foo:
        bar
        baz

is the same as

    foo bar baz

and

    if (predicate):
        (then-instr)
        (else-instr)

is the same as

    if (predicate) (then-instr) (else-instr)

then shouldn't the second example

    + 1:
        * x x
        * y y

be the same as

    + 1 * x x * y y

Or alternately if the indented lines gain implicit parens shouldn't

     foo:
        bar
        baz

be the same as

    foo (bar) (baz)

?

-----

3 points by fmota 6139 days ago | link

Yes, you stumbled right into the problem with this scheme. But it's not really a problem if you accept PG's idea that parens are allowed to be implicit whenever that is the only thing that makes sense.

So, in the case of

    + 1:
        * x x
        * y y

The parens around * x x and * y y are implicit.

-----

4 points by greatness 6140 days ago | link

(A) That looks suspiciously like python. (B) If it IS implemented at some point, I would not be against it, but that colon better be optional :p

-----

3 points by fmota 6140 days ago | link

(A) I love python. ;)

(B) Makes sense. After all, if you're going through the troubles of adding indentation, you might as well make the colon optional.

-----

3 points by chrisdone 6140 days ago | link

I have found s-expressions easier to edit with a smart editor than other syntaxes. Having to think again about the layout of syntax doesn't sound very appealing, but I would probably give it a try if someone implemented it.

-----

3 points by cratuki 6139 days ago | link

The more I think about this the more enthusiastic I am about it. Where are you going to go with it?

-----

2 points by fmota 6138 days ago | link

I'm prototyping an interpreter in Python, and then when it gets to the point that it's mostly executable, go from there.

-----

2 points by babo 6138 days ago | link

Is your code publicly available?

-----

2 points by cratuki 6140 days ago | link

I wonder if you could try implementing this as another compile step on top of arc (with another REPL layer, etc), and then see whether it becomes more popular to code with or without this.

-----