Likewise, Scsh shows that a lisp-1 could encroach on territory typically occupied by Ruby and Perl.

Besides the early flurry of articles at its release it hasn't really gotten much notice. But that's OK- the goal of this language is to create something with a long time horizon in mind. Nobody, not even pg, would argue that arc, in its current form, is much of a technological breakthrough yet. Its contributions are more conceptual at this point. I think, though, for a certain style of programmer (such as myself and the few others frequenting this forum :-) it has a lot to offer, even in its current, incomplete, form.

Arc has a few advantages : it's got a canonical implementation (the fact that code is specification makes it easier), a charistmatic benevolent dictator and it is directed toward a popular and modern concern : web apps.

It could make Lisp popular, but it needs some kind of killer app. The news app is cool, but it won't be enough. Anybody's got an idea ?

...until you realize that nearly every non-pg, non-rtm Arc user prefers to use the non-canonical Anarki, and recommends it because of the sheer number of bug fixes (never mind the new features, such as 'defcall, 'defm, 'p-m:, 'sync, 'thread-local, 'file-table ... etc.)

> It could make Lisp popular, but it needs some kind of killer app. The news app is cool, but it won't be enough. Anybody's got an idea ?

This also means that if Anarki tries to keep full compliance with ArcN in the future, without pg updating ArcN reasonably frequently, eventually (in a year? half a year?) Anarki will either: 1) die out as a source of innovation, because people will simply rather wait for pg's next update rather than push a change that might be overridden by pg in the future, or 2) drift so far away from pg's internal ArcN that when pg releases it, the merge hell will be very, very hot.

Take an example this: http://arclanguage.com/item?id=6138

  arc> (ssexpand 'foo?x)
  (is foo x)

The fact that broken pg's code is specification is a pain in the back and doesn't make anything easier.

i mean changing the notation to normal 2+2 instead of + 2 2 and getting rid of the parenthesises, is that really really hard to do and still keep all the features of the language? i guess it is since it hasnt been done.

Now I'll introduce to you a special syntax in Stutter. In Stutter, () introduces a data constant called an array, which is just like any other sequential data collection in any other language. So it's possible to do something like this in Stutter:

  set[var  (1 2 3 4)]

  set[var (1 "hello" ("sub-array" 4 ))]

  set[var (hello world)]

The array is just like any other array in any other language. You can concatenate them like so:

  set[var append[(array 1) (array 2)]]
  => now var is (array 1 array 2)

  set[var cons[1 (some array)] ]
  => now var is (1 some array)

  nth[1 (this is the array)]
  => this returns the label "is"

  nil[]

  array["hello"]
  => returns the array ("hello")

They called their Stutter interpreter "lave", because they were hippie wannabes and were tripping at the time they were choosing the name. It was supposed to be "love", but like I said, they were tripping.

Of course, since lave accepted arrays, it couldn't get at the nice f[x] syntax. So they decided that the first element of an array would be the function name as a label. f[x] would become the array (f x).

lave had some limitations. For example, instead of Stutter's nice infix syntax a + b, lave needed (plus a b). Fortunately lave included a plus[x y] function which was simply:

  define plus[x y]
   x + y

  cond[
    { x == y
         ...your then code...
    }
    ;yes, what can I say, Stutter's BDFL is lazy
    { !(x == y)
         ...your else code...
    }
  ]

  (cond
    ( (eq x y)
      ...your then code...)
    ( (not (eq x y))
      ...your else code...))

  if[
    (eq x y)
    (...your then code...)
    (...your else code...)]

It looked like this:

  define if[c then else]
    append[
        (cond)
        cons[c
          array[then]]
        cons[ append[(not) array[c] ]
          array[else]]]

  lave[
    if[ (eq x y)
         (...your then code...)
         (...your else code...)
     ]
  ]

Basically, you could tell lave that certain Stutter functions would be treated specially in their lave-syntax. These functions would have the "orcam" property set in some private data of lave. Instead of just running the function, lave would extract the array components, pass them to the function, and then run whatever array that function returned. So you could simply say:

  lave_set_orcam_property[(if)]
  lave[
   (if (eq x y)
      (...your then code...)
      (...your else code...)
   )
  ]

  define for[s c u code]
    append[ (begin) //begin{} is just a compound statement
        cons[ s
            append[(while)
                cons[c
                    cons[ code array[u]]
                ]
            ]
        ]
    ]

  for[(set i 0) (less i 42) (preincrement i)
    (begin (print i))]

  (begin
    (set i 0)
    (while (less i 42)
       (begin (print i))
       (preincrement i)
    )
  )

  lave_set_orcam_property[(for)]
  lave[
    (for (set i 0) (less i 42) (preincrement i)
        (begin
             (print i)
        )
    )
  ]

Soon after lave's creators added orcam-property-functions, Stutter's BDFL decided to do something about the language. He was always bothered about the bug in Stutter array syntax where something like (hello world) would return, well, the array (hello world), instead of sensibly returning an array with the values of hello and world. So he introduced the `, syntax. An array constant prefixed with "`" would have a special meaning. It would not be completely a constant. Instead, when it saw a "," Stutter would evaluate the expression following the comma and insert that element into the array being created. So `(,hello ,world) could now become (42 54), if hello was 42 and world was 54.

Some of the top ocam-property-function writers realized that Stutter's new `, syntax would really, really help. For example, instead of the kludgy, virtually unreadable if code, you could just write:

  define if[c then else]
   `(cond
        (,c ,then)
        ((not ,c) ,else)
    )

  define for[s c u code]
     `(begin
          ,s
         (while ,c
              ,code
              ,u
          )
      )

Because of this, creating orcam-property-functions became easier and their power skyrocketed. Other languages which automatically evaluated variable labels in their arrays couldn't imitate it (so what was originally a bug - that (hello world) did not evaluate the variables hello and world - became a feature). Worse, those other languages' arrays sometimes couldn't themselves contain arrays, or even have different types.

Their arrays just weren't powerful enough to hold code, so other languages never managed to create a powerful orcam-property syntax.

Eventually, people were writing Stutter programs like so:

  lave[
   (define (fn x)
      (if (less x 1)
          1
          (times x (fn (minus x 1)))
      )
   )
  ]

  while[true]{
    print[ lave[ read[] ] ]
  }