SearchYC.com

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.

I think the goal for Arc should be to be powerful enough to express all these cases without resorting to expressions (+ - len).

Most obvious improvement - allow negative indices for the second argument. Then you could say:

    (cut s -x)

    s[-x .. -1]

    s[x] ; s[i,j] ; s[i .. j] ; s[i ... j]

    (s x) ; (cut s x) ; (cut s i j)

And to call not supporting unicode "offensive" is missing the point. Only supporting ascii makes the language less powerful. It means you can't use Arc for solving problems involving text manipulation in languages other than English. That's a big space. Only supporting UTF-8 would make more sense.

    # Ruby 1.8
    insertion = new? ? ['new'] : []
    list = ['hello','brave'] + insertion + ['world']

    # Ruby 1.9
    insertion = new? ? ['new'] : []
    list = ['hello','brave',*insertion,'world']

    # Arc now
    (let insertion (if (is-new) (list "new") nil)
      (join (list "hello" "brave") insertion (list "world")))

    # With @ operation
    (let insertion (if (is-new) (list "new") nil)
      (list "hello" "brave" @insertion "world"))