1) proper phase-distinction between compilation and evaluation
       - not possible with the way that macros are currently done
    2) if not (1), then there's no excuse for not making macros first-class
       - see how to in: http://arclanguage.com/item?id=842
    3) modules (like everyone :)
    4) Extend the concept of application to data to all data types by making it programmable in arc
       - Currently you can do ((list 1 2 3) 0) and you'll get 1, 
       - why not allow this for all data-types by having a call-back into arc, such that arc-code can switch on the type.
    5) Hygienic macros
    6) Removal of 'nil
       - 'nil does nothing more than '(), and often it breaks (e.g:
            - when printing cyclic structures
            - the fact that not all '()'s are replaced by 'nil). )
       - Seriously, what's the need for 'nil?  Just use '()
    7) That's it for now, if you want unicode, but bleh

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)

The only place I use loops is just the infinite loop that represent single timesteps in which my models run. Arc has

  (mapcar 'length my-strings)

  (loop for s in my-strings collecting (length s))

I enjoyed using the Haskell Parsec library:

  http://legacy.cs.uu.nl/daan/download/parsec/parsec.html

Here's part of a JSON parser I wrote once:

  exponent_part =
    (string "e" <|> string "E")
    `followed_by` (string "+" <|> string "-")
    `followed_by` many1 digit

If you treat strings as lists of characters and have good pattern-matching, this problem mostly solves itself, without something as ugly as regular expressions. You have the rich set of list operations, function-based predicates and, with clause selection by pattern, that's mostly what you need.

Javascript has this notation for hashes with symbol keys: {a: 97, b: 98, c: 99}

Ruby has this notation for lists of strings: %w(monday tuesday wednesday). Ruby also has 5 different ways of writing a string literal, all of which are useful.

The "f:g" syntax is a nice idea for function composition, as is "~f" for negation, but the current syntax and semantics seem like a hack. What if we could do this instead:

  (def f (x y) ...)
  (infix f left)

  <x f y>  ; The compiler would transform this to (f x y)
  <x f y f z>  ; And this to (f (f x y) z) (evaluate from the left)

  (infix f right)

  <x f y f z>  ; And now to (f x (f y z)) (evaluate from the right)

  ; Use in "normal" syntax:
  (= foo <x f y>)  ; --> (= foo (f x y))

  ; So, we could do this:
  (infix + right)
  
  (= foo <1 + 2>)  ; Would evaluate/transform to (= foo (+ 1 2))

  (= foo (+ 1 2 3 4))  ; And we could still use the ordinary function call syntax.

  ; Or maybe even:
  (infix + associative)
  (= foo <1 + 2 + 3 + 4>)  ; Transforms to (+ 1 2 3 4) if the function is n-ary, or 
                           ; some arbitrary evaluation order if not.

  ; And now for the interesting bit.
  (def : (f g) (fn (x) (f (g x)))))
  (infix : right)

  (map <f : g> list)  ; What currently is (map f:g list)

  ; Why not extend the idea?
  (def ~ (f) (fn (x) (not (f x))))
  (unary ~)

  (if (<~ predicate> arg) ...)

  ; No, that doesn't have any benefit over ((~ predicate) arg).

- How do you define precedence levels? Once you are in this swamp, you can't get out. Maybe all infix functions would have the same precedence to side-step the issue.

- Is it possible to do with only the < > notation? But how would you parse the following without the additional information that + is infix?

  <+ + + + +> 

  <x f f y>
  <1 + + 1>
  <1 +>
  <+ 1>
  <+ +>
  <+ ~>
  

This is a big one but a simple solution is possible in a first time. Since Arc is mainly for web apps, why not at least convert non-ascii characters into their url-encoding equivalents ? Arc is already converting those characters, but in a broken way : EUR instead of the euro symbol, for exemple.

If you move unicode to the libraries, you have to move the string type to the libraries too, assuming strings are lists of unicode characters. And if you move the string type to the library, how can you convert a symbol to a string?

That's not an option, so the alternative is that strings are just byte arrays, ignorant of their encoding, and you need libraries to find out what the length of a string is, and you're back in the tar pit where Ruby and PHP were in 1997 and where they pretty much still are today.

Keyword arguments.

Modules.

FFI.

So far, I'm not too keen on = for setf. Mainly for the negative reason that I like = with its comparison of numbers meaning. Perhaps (! a 0) for assignment?

This is one of the most irritating legacies of Perl and no new language should make that mistake. I'm not saying regular expressions have no place, but it's a specific and special problem domain, not a general one.

   <(fn x y) : (take x xs) (take y ys) (assert (pred x y))>

  (def foo ()
    ...
    (make-local bar 'baz) ; macro call
    ,,,)

  (def foo ()
    (let bar 'baz
      ...
      ,,,))

(spliceable (let arglist '(4 5 6) (list 1 2 3 (splice arglist) 7 8 9)))