: instead of ' doesn't look so good for quoting lists -

  :(a b c)

My biggest problem with using Unicode is that it's often a pain to type. The Mac gets this the most right of any platform I know, but even so, it's (a) not a standard, and (b) mostly alphabetic. Which is a pity, really, since those do make the most sense.

Agreed. We might be able to add a hook to arc-mode in emacs to make it more convenient, but reminds me even more of APL (which if I recall correctly required a custom keyboard to type).

> + might not be bad, but it's probably a little too common

I like +. While + does get used in symbols occasionally (most notably in arithmetic), I can't think of any cases where it gets used in the middle of a symbol.

But anyway, I still think they're not worth loosing an ASCII character, and using mathematical notation would be very useful. It would make code readable by people a little aware of mathematics. That is, most programers. It would be definitely better than arbitrary characters.

Why should we restrict to ASCII anyway ? I mean, a lot of symbols I use are not ASCII anymore (they are accentuated, I'm French so something like 'year is translated into 'année, not into 'annee). Sure, they're hard to type, but are they any longer than they symbol counterpart ? If you type them often, just make them a vi macro (or whatever in your favorite text editor) and you're done.

  (mac def-ss- rest
    (let pairs (map (fn ((s e)) `(,(string s) ,e))
                    (pair rest))
      `(do (zap [join _ ',pairs]           ssyntaxes*)
           (zap [join _ ',(map car pairs)] ssyntax-strings*))))
  
  (= mac-seval $)
  (def-ss-
    $ (fn lists (apply map R lists))
    $ mac-seval)

  arc> ($car '((1 2) (3 4) (5 6)))
  (1 3 5)

Basically what is done is, it scans linearly through the ssyntaxes* list, and performs the splitting at the time. So if the list is:

  $ prefix
  $ standalone
  :  infix
  ~prefix
  ~ standalone
  . infix
  ! infix

  foo!bar:qux!quux

  {{foo ! bar} : {qux ! quux}}

I'm also biased, because I want to create my own syntax for a message-passing Arc to be used as the object scripting language for a multi-user VR system. (I haven't even started working on a server for it yet -- just the client and the protocol.) So something like:

  (is /parent/owner/id /owner/id)

  (is (msg (msg parent 'owner) 'id) (msg owner 'id))

  /  (msg L 'r)

As an aside, why not <- ? Basically parent<-owner<-id means "send 'id to the result of sending 'owner to parent".

For that matter if an object, such as parent above, is something of very specific type, you can even use the Anarki 'defcall syntax. For example if messageable objects are of type 'messageable, you can do:

  (defcall messageable (o m)
    (msg o m))

  (foo bar) == (msg foo bar), if (is (type foo) 'messageable)

I considered <- (along with a lot of other things), but rejected it because the left-associativity of it seemed counter-intuitive, it didn't stand out as much as slashes, and I want it to stand out because it's inconsistent with symbol syntax, it's confusing with -> which conventionally means type-conversion (and which doesn't break up symbols), and it's three times as much effort to type as /.

Slashes are fairly common in symbols, but not at the beginning (except for / itself), so it's unambiguously parseable, though maybe it won't work with this system, now that I think about it. I don't see how to prevent embedded slashes from meaning anything special without the first slash. I.e., I want foo/bar/nitz to be one symbol, but /foo/bar/nitz to be a symbol and two msg calls. Maybe that's too hairy, but I'd hate to break things like w/uniq.

  (def-all-ss
    #\:  (compose ...)
    ~    (complement R)
    ~    no
    =    (annotate 'mac (fn (_) `(= L ,_)))
    #\.  (...)
    !    (L 'r))

  (if hd
      (= tl (= (cdr tl) (cons o nil)))
      (= hd (= tl       (cons o nil))))

  (if hd
      (tl=:cdr.tl= (cons o nil))
      (hd=:tl=     (cons o nil)))

Are different ssyntaxes be combinable? Could you, for example,

  (if (int?//num? n)
      ; its a number...
      ; not a number...

With proper ordering of the ssyntaxes in 'def-all-ss, yes.

> Do these ssyntaxes currently get optimized away at compile time (i.e. like 'compose does)? Or do they incur a run-time penalty of some sort?

Not yet. The run time penalty should be as small as a function-composition overhead. The optimization away of 'compose is done by the Scheme-side 'ac, so if optimizations for 'orf and 'andf and similar are desired, munging them in the scheme-side is necessary.

Edit: As an aside, the above ssyntaxes are not yet implemented in the ssyntaxes.arc file. For the most popular ones - postfix ?, as well as 'andf && and 'orf //, you can modify:

    (def-all-ss
      //   (orf ...)
      &&   (andf ...)
      #\:  (compose ...)
      ~    (complement R)
      ~    no
      #\.  (...)
      !    (L 'r)
      ?    [isa _ 'L])