Arc Forumnew | comments | leaders | submitlogin
2 points by zck 4642 days ago | link | parent

I took some sample code from my solution to Project Euler #21. This function determines whether the argument n is an amicable number -- that is, if you add up all its divisors, you get a number, and then you take that number and add its divisors, and you get n. The lowest amicable pair is (220, 284). Anyway, the code:

    (def amicable (n)
         (let step (sum-divisors n)
          (and (isnt n step)
               (is n
                   (sum-divisors (sum-divisors n))))))
Translated to new-syntax:

    (def amicable (n)
         (let step n.sum-divisors()
              (and n.isnt(step)
                   n.is(n.sum-divisors().sum-divisors()))))
I don't see it as a win. The function call is taken out of the first position, and placed later in the line. This puts undue importance on the first argument. Unlike Java, Ruby, and Python, you don't even have object orientation (read: single dispatch) to make that first argument actually more important. I prefer the function to be first, as that's the most important thing in the line of code. It tells me what's going on, and how to read the line. With functions being second in the line, I have to parse more of the line before getting a grip on the overall meaning of the line.

When nesting tables in Arc, you write something like this:

    ((nested-table user-id) name)
How would this look in new-syntax?

    name.user-id.nested-table()()
or

    name.(user-id.nested-table())()
or

    (user-id.nested-table() name)
Right now in Arc, you can do this:

    nested-table.user-id.name
It seems cleaner, at least for this example.

What do you see as the advantages of this syntax, beyond the fact that people will kneejerk less to Lisp style? Can you show us some code that looks better written in new-style?



1 point by Pauan 4642 days ago | link

I agree overall, but... I will note that object orientation is possible, for instance with my "object.arc" library[1]. However, I don't use the "." syntax for that either... for instance, this in JavaScript:

  foo.bar(qux);
Would be this, with my library:

  (foo<-bar qux)
However, it may be cool to be able to write "foo.bar(qux)" with my library instead. I've also considered a pretty radical idea, having every function dispatch to a method on an object. So this:

  (car foo)
Would translate to this, automatically:

  (foo<-car)
In any case, I agree that with functional style, I prefer Arc's syntax. But assuming somebody were to write/use an OOP library for Arc, I can see why they would prefer a more traditional syntax.

I think, ideally, Arc should allow you to change the syntax, on a file-by-file (expression-by-expression?) basis. Then the default could be what it is right now, but still allow people to write with whatever syntax they want. Arc isn't there yet, but I think that's a nice ideal to strive for.

---

P.S. Somewhat related, is the concept of "sweet expressions": http://www.dwheeler.com/readable/

With sweet expressions, you can write "foo(bar)" rather than "(foo bar)", but it still allows you to use "(foo bar)" when you want to. In other words, it lets you mix-and-match Lisp syntax and more traditional syntax, even within the same file. So you can use whichever one happens to be most readable at the time.

---

* [1]: https://github.com/Pauan/ar/blob/lib/object.arc

-----