First, for your particular example, you could just do this:

  a!b.4!c!d!e!f

  (!f:!e:!d:!c:a!b 4 5)

Not really, it should create this;

  a.b(4, 5).c.d.e.f

  ((compose (get (quote f)) 
            (get (quote e)) 
            (get (quote d)) 
            (get (quote c)) 
            (a (quote b))) 4 5)

  (function(){
    var g3283=arraylist(arguments);
    return get('f')(get('e')(get('d')(get('c')(apply(a.b,g3283)))));
  })(4,5);

Of course, you can still use (((((a!b 4) 'c) 'd) 'e) 'f) to generate a.b(4).c.d.e.f. [1]

> mzscheme 372 does not compile for me

Did you know Arc 3.1 works on the latest MzScheme? [2]

---

[1] Actually, you might be further disappointed to know (((((a!b 4) 'c) 'd) 'e) 'f) is currently compiling to:

  get('f')(get('e')(get('d')(get('c')(get(4)(get('b')(a))))));

[2] http://arclanguage.org/item?id=10254

  get('f')(get('e')(get('d')(get('c')(get(4)(get('b')(a))))));

1. If the form has a single quoted arg, as in (x 'y), it's compiled to x['y']. This allows object access chains like document!body!innerHTML to be compiled correctly by default.

2. If the form has 0 or 2+ args, or 1 arg that isn't quoted, then it's considered a function call:

  (x) => x()
  (x y) => x(y)
  (x y z) => x(y,z)

  (x "y")
  (x `y)        ; quasiquote isn't currently used for anything else
  (x 'y nil)    ; the function can just ignore the nil arg
  (fncall x 'y)

  callget!y.x

  arc> 'x.'y
  x.
  arc> y   ; still evaluating previous expr
  arc> 'x.`y
  |x.`y|

I'm currently torn about whether to do

  x!y => (x 'y) => (fncall x 'y) => x('y')
  x.`y => (x `y) => (objref x 'y) => x['y']

  $(document).ready(function() {
     $("a").click(function() {
       alert("Hello world!");
     });
   });

  ($.document.`ready (fn ()
    ($!a.`click (fn ()
      (alert "Hello world!")))))

This example works particularly well because the $("a") jQuery selector can be compiled from $!a. A challenge arises with more complex selectors, as in this snippet from the Find Me: Using Selectors and Events tutorial:

  $(document).ready(function() {
     $("#orderedlist").addClass("red");
   });

  ($.document.`ready (fn ()
    ((($ "#orderedlist") `addClass) "red")))

  ($.document.`ready (fn ()
    (.`addClass!red ($ "#orderedlist"))))

  $ mzscheme
  Welcome to MzScheme v4.2.1 [3m], Copyright (c) 2004-2009 PLT Scheme Inc.
  > (parameterize ((current-readtable #f)) (read))
  x`y ; read in as two items
  x
  > y
  > (parameterize ((current-readtable (make-readtable #f))) (read))
  x`y ; read in as one symbol
  |x`y|

This should be mentioned on http://www.arclanguage.org/install

ac.scm:1023:0: ffi-obj: couldn't get "setuid" from #f (The specified procedure could not be found.; errno=127)

  (define setuid (get-ffi-obj 'setuid #f (_fun _int -> _int)))

  (define (setuid x) x)

  http://www.ruby-lang.org/en/
  http://www.python.org/
  http://www.perl.org/
  http://www.erlang.org/
  http://clojure.org/

They're opposing perspectives. As a user of arc I'd throw it into production[1]. At the same time, from PG's perspective I'd want to be conservative about calling it production ready.

I suspect arc will never go out of 'alpha' no matter how mature it gets, just because PG and RTM will not enjoy having to provide support, or having to maintain compatibility.

[1] With some caveats: treat it as a white box, be prepared to hack on its innards, be prepared to dive into scheme and the FFI. And if you're saving state in flat files, be prepared for pain when going from 1 servers to 2.

Yes, this is sometimes a problem for me too, or at least an annoyance. It's one of those things that's a bug or feature depending upon who you ask, though. [1] Whichever way you classify it, the root issue is with Arc, not the compiler, which just conforms to Arc's ssyntax rules.

  (= document.body.innerHTML (document.getElementById "foo" . value))