The positive thing about adding a tagged predicate dispatch table, if implemented into "isa", would be the illusion of any object being a particular "type", provided it satisfies the predicate. In reality, the true type of the object would be cons or sym or whatever its value is.

One simple idea: The int/num difference could theoretically be moved into arc codespace via deftag. Primarily leave the number type "num" internally, but deduce if a number is an "int" via the tags table.

Example:

  (deftag int
    (and (isa _ 'num)
         (is _ (round _))))
  
  (isa 1.5 'int) => nil
  (isa 1 'int) => t

Example:

  (deftag class
    (and (alist _)
         (is len._ 3)
         (is car._ 'class:)
         (alist cadr._)
         (>= (len cadr._) 1)
         (is (car cadr._) 'slots:)
         (alist (car:cddr _))
         (>= (len:car:cddr _) 1)
         (is (caar:cddr _) 'methods)))

  (= foo '(class:
            (slots: bar)
            (methods: baz)))

  (isa foo 'class) => t
  (isa foo 'cons) => t
  (type foo) => cons
  (alist foo) => t

Incidentally, anarki does predicate dispatch through defextend:

  (defextend some (test seq) (isa seq 'string)
    (let f testify.test
      (recstring f:seq seq)))

Example:

(deftag posnum (and (isa _ 'num) (> _ 0)))

(isa 1 'posnum) => t

(isa 0 'posnum) => nil

---

Your idea of types is similar to Predicate Dispatch[1]. I believe it's also similar to Racket's contracts[2].

This is an extremely powerful type system in the sense that you can express literally anything with it. However, I believe that a more restrictive type system can actually be better, because it provides more guarantees (especially at compile-time).

---

I don't think it's possible to pattern match on a function's arguments, body, and closure, simply because Racket doesn't expose those things.

I do approve of pattern matching, though.

---

* [1]: http://en.wikipedia.org/wiki/Predicate_dispatch

(More info: http://arclanguage.org/item?id=2556)

I'm having more trouble understanding deftype. (I'd never come across it so far in my common lisp experience.) I couldn't tell what the benefit would be of your ((tags 'posnum) 0) examples over just a simple predicate. Won't it only be useful if arc actually got optional typing like common lisp?

  arc> (def do-func args last.args)
  #<procedure: do-func>
  arc> (mac do-macro args `((fn () ,@args)))
  #(tagged mac #<procedure: do-macro>)
  arc> (time:repeat 1000000 (do-func 1 2 3))
  time: 270 cpu: 270 gc: 6 mem: -4392856
  nil
  arc> (time:repeat 1000000 (do-macro 1 2 3))
  time: 69 cpu: 70 gc: 0 mem: 928
  nil
  arc> (time:repeat 1000000 1 2 3)
  time: 67 cpu: 68 gc: 0 mem: 128
  nil

  (def do args (last args))

I burned a lot of time looking for my (not "the") perfect language, and finally settled on Racket for the dynamic language and OCaml for the statically typed language.

Now I'm trying see which problems are best suited to each of them.

Clojure has a lot of good things, but I've never been able to get past the dependency on the JVM, lack of tail calls, etc., but it's pretty darn concise.

You said this in the HN thread:

"I'm sure Arc is the wrong choice if I want to be as effective as possible in 6 months. If Arc is only the best choice if I want to be as effective as possible in 5+ years someone save me ;)"

The specific language is only one aspect of effectiveness - others include available libraries, an active contributing community, etc. I don't think there's reliable evidence that Arc will change enough in 3 years to fulfill your "effective as possible" goal.

Paul's last submission to his own forum has been over 5 years ago! And his last comment has been over 4 years ago. It would seem that he's not actively involved any more.

I was very excited to hear about Arc over 7 years ago, and I had high hopes that Paul might be the person to create a successful lisp and rally a great community. This has not happened, and I think it would be foolish to think this will change much in the next three years.

In the end, I ended up choosing Racket as my lisp - it made my short list to evaluate in part because Paul chose it to implement Arc :)

If your file is somewhere else, you'll have to specify the full path to it (warning: untested):

  arc> (load "C:\\Users\\Benben\\Documents\\foo.arc")

  arc> (load "foo.arc")