Stefan Tilkov's Random Stuff

Arc: a New Programming Language

So the big news today, at least for some small community of the initiated, is the release of a first version of Arc, Paul Graham’s LISP dialect that many people waited for. I’ve seen some mixed reactions:

Antonio Cangiano writes:

[R]ight now it’s not really convincing as an alternative to CL or Scheme itself. Don’t construe this as a harsh criticism towards Arc, it is not. We are talking about a language that it’s in its infancy and that as I said, I plan to experiment with myself. I hope to see it grow rapidly and I congratulate Graham and his team for finally making it available. That said, right now I think it’s a weak release and therefore, in my opinion, the disappointment of many is justified. In any case, good luck Paul, we’ll watch this one closely.

The most disturbing critique — regarding Graham’s decision to not implement Unicode — comes from Aristotle Pagaltzis:

Getting character strings right, however, is something that you really do need to get right at the core language level. You cannot leave it for libraries to fix.

After a quick glance at the tutorial, the most intriguing bit seems to be the support for macros, which work (almost) like function definitions. Interesting, but nothing that gets me overly excited.

Sean McGrath thinks one needs to keep an eye on it. I agree.

Comments

On January 30, 2008 8:25 PM, Patrick Logan said:

The Arc macro system looks to be the same as the simplest macros in Common Lisp and in several Scheme implementations. As Graham wrote: good choice, to avoid the “hygenic”, er, crap.

On January 30, 2008 8:33 PM, Stefan Tilkov Author Profile Page said:

Could you elaborate a little? I always thought hygienic macros were a good idea?

On February 2, 2008 10:41 PM, Burkhard said:

Hello Stefan,

I don’t think that a hygenic macro system is a bad choice as default mode for a macro system. It does not allow some tricks you can do with unhygenic macros (see below for an example) but the safety is worth the restrictions. And (at least with scheme you can have both), see e.g R. Kent Dybvig nice stuff at http://www.cs.indiana.edu/~dyb/pubs/tr356.pdf .

(define-syntax silly-dsl
    (lambda (x)
        (syntax-case x ()
            ((_ expr ...) 
             ;; This shows how unhygiene can be introduced in a controlled manner
             ;; with syntax-case's datum->syntax-object. 
       ;; In this case occurences of the identifier ">>" in the
             ;; input form are replaced by the local definition of >> as a procedure at (*)
             (with-syntax ((>> (datum->syntax-object (syntax _) '>>)))
                                        (syntax 
                                         (lambda () 
                       (let ((>> (lambda args 
                                   (for-each (lambda (_) (display _) (display "; "))
                                             args)
                                   args))) ;; (*)
                         expr ...))))))))

(define fn (silly-dsl (apply + (>> 1 2 3))))
On February 3, 2008 8:49 PM, Patrick Logan said:

Sure, I think it is reasonable to have both. I prefer the simpler “non-hygenic” macros, but I have written macros using both in Scheme. I have written macros in both in Scheme.

I “grew up” with the simpler macros and frankly never thought the concepts were difficult to grasp and encode in the simpler form. I still find the simpler macros easier to read and write, but I have used them a good bit more.

For Graham, et al. trying to get a new language out there, the simpler form is probably the better choice — much easier for them to implement. It takes less than a day to write an implementation of “defmacro”, and I’ve done that. (Unfortunately called “mac” in arc, but oh well.)

On the other hand implementing a hygenic macro system, which I have never done and would not dare do, took years to evolve and the brightest scheme programmers to figure out how to implement and use. The arc guys chose the simpler form and could then spend the rest of their time on more important things.