For instance, if you look at arc.arc, you'll see the first two macros are defined without the use of the macro mac. Using

   (set foo (annotate 'mac some-function))

I want:

    a) The ability to define within arc what happens when a list is 
         used as function, instead of it being predefined in scheme
    b) The ability to do this for any type and custom types.
 

    c) For annotated values to be able to do this per-object, 
        by storing an extra field in there that is the getter, 
        where the default value is the one for the type.

    E.g:  (annotate 'blabla value getter)

http://forum.java.sun.com/thread.jspa?threadID=594475&me...

I'd kinda like to see Arc grow some sort of module system - even a very simple dictionary-based system like Python's or JavaScript can go a long way towards making larger programs tractable. Come to think of it, I think you could emulate JavaScript's system with closures and hashtables. Just wrap every module in a closure, which binds a hashtable to the module name and inserts each function into the hash table:

  ([do
   (set My-Module-Name (table))
   (= (My-Module-Name 'foo) (fn (arg1 arg2) ...))
   (= (My-Module-Name 'bar) (fn (arg) ...))
   (= (My-Module-Name 'baz) (fn () ...))
  ] 'ignored)

  (module My-Module-Name
     (private my-private-method (arg1 arg2) ...)
     (public my-public-method (arg1 arg2) ...)
     (public my-other-method (arg1) ...))

  (mac module (name . spec)
    (with (car-is (fn (sym) [is sym (car _)])
           public-forms (keep (car-is 'public) spec)
           private-forms (keep (car-is 'private) spec)
           make-public [`(= (,name ,'(cadr _)) (fn ,@(cddr _))]
           make-private [`(,(cadr _) (fn ,@(cddr _)))])
      `([(do
          (set ,name (table))
          (with ,(mappend make-private private-forms)
             ,@(map make-public public-forms)))] 'ignored))

  (= my-module
     (let obj (table)
       (= (obj 'rem-xs) (fn (s) (rem #\x s)))
       ...
       obj))

  ((my-module 'rem-xs) "abcxdefxghi") ;; => "abcdefghi"

  (def rem args
    nil)

  ((my-module 'rem-xs) "abcxdefxghi") ;; => nil

  (aload 'my-module)

  (let rem (fn args nil)
    ((my-module 'rem-xs) "abcxdefxghi"))

  ;; => "abcdefghi"

  (let rem (fn args nil)
    (aload 'my-module)
    ((my-module 'rem-xs) "abdxdefxghi"))

  ;; => nil

  (= my-module
     (with (rem rem
            table table
            fn fn
            obj (table))
       (= (obj 'rem-xs) (fn (s) (rem #\x s)))
       ...
       obj))

  ((my-module 'rem-xs) "abcxdefxghi") ;; => "abcdefghi"

Of course the ignored caveat is this: so many bloggers are up in arms over this point, it's presupposed that being able to change core library functions is a defacto terrible thing--at work, where we have a massive C/C++ codebase running on some unmaintained, sourceless, legacy APIs, being able to (for example) add/fix methods in some of the base classes would be a significant time-saver.

I think Arc as-is makes it a bit too easy to shoot yourself in the foot; however, I'm firmly in the camp that being able to update core functionality should be allowable.

(module::function args)

  (quasiquote (a b (unquote-splicing args) (unquote x)))

  $('body').append('<input id = "myInput" /><input type = "submit" />')
    .find('input[@type=submit]').click(function() {
       val = $('#myInput').val();
       $('body').html('<a href = '#'>click here</a>').find('a').click(function() {
          $('body').html('You said: ' + val);
       });
    });

<input id="in" type="text" /><input type="submit" onclick="window.result='You said: '+document.getElementById('in').value; document.body.innerHTML='<a href=\'#\' onclick=\'document.body.innerHTML=window.result;\'>click here</a>'" value="Submit"/>

  (sort (fn (x y) (< (coerce x 'string) (coerce y 'string))) (keys sig))

  ;(aload "libs.arc")

    (sort (compare < [coerce _ 'string]) (keys sig))

  (sort < (keys sig))