Arc Forum | I have to admit this is all somewhat theoretical at this point. For all I know, ...

Arc Forum

3 points by fallintothis 5135 days ago | link | parent

I have to admit this is all somewhat theoretical at this point. For all I know, this pattern never occurs in lisp programs.

Not enough that ambiguities wouldn't still need to be resolved with list anyway. Most of the time, you're not building up a literal tree of elements that you know will be atoms -- you're using variables. E.g.,

  (def enq (obj q)
    (atomic
      (++ (q 2))
      (if (no (car q))
          (= (cadr q) (= (car q) (list obj))) ; call to list here
          (= (cdr (cadr q)) (list obj)        ; call to list here
             (cadr q)       (cdr (cadr q))))
      (car q)))

You couldn't change (list obj) into just (obj), since (a) Arc doesn't like lexical bindings replacing macros, so (obj) would eval to an empty hash table; (b) even if that was fixed (it's easy to do, but vanilla Arc's still bugged), what if you're enqueuing a function, list, string, or hash table? (obj) would eval either to an error (not enough arguments) or would call your function, which is surely a bug. Thus, you need list.

  (def pair (xs (o f list))
    (if (no xs)
         nil
        (no (cdr xs))
         (list (list (car xs)))      ; calls to list here
        (cons (f (car xs) (cadr xs))
              (pair (cddr xs) f))))

could only be changed to

  (def pair (xs (o f list))
    (if (no xs)
         nil
        (no (cdr xs))
         (list ((car xs)))           ; since ((car xs)) would be a list
        (cons (f (car xs) (cadr xs))
              (pair (cddr xs) f))))

which isn't really clearer, and runs into the same problems if (car xs) happens to be a string, list, function, or hash table.

Even

  (def split (seq pos)
    (list (cut seq 0 pos) (cut seq pos))) ; call to list here

couldn't be changed, since seq should be a list or string.

See also the definitions in arc.arc of insert-sorted, reinsert-sorted, defsets of car/cdr/caar/cadr/cddr, setforms, a lot of macro expansions (like obj, though that's arguably replaceable under the proposed scheme), and commonest. That was my point about list making the presence of literal lists explicit.

Places where you could safely use this scheme aren't really big wins anyways. You get to change

  (def queue () (list nil nil 0))

  (def queue () (nil nil 0))

  (let record (list (seconds) ip user)

in app.arc to

  (let record ((seconds) ip user)

It's rare you'll have to type out a big enough tree literally (i.e., without variables that will cause the problems we've seen) to make it worthwhile, and it doesn't simplify much code that currently uses list anyway.