(def dump-out (port l)
    (map [wrie _ port] l))

  (unless (has-a a 'scanner)
    (err "type error"))

  (mac type-declaration (a typ)
    `(unless (has-a ,a ,typ)
       (err "type error")))

  (def dump-out (port l)
    ; a completely optional declaration
    ; for:
    ; (1) an non-optimizing interpreter, so that
    ; you have some chance of checking errors, and
    ; (2) the optimizing compiler, so that it can
    ; do some shortcuts.
    (type-declaration l 'scanner)
    (map [write _ port] l))

You can then trivially redefine type-declaration as:

  (= type-declaration
     (annotate 'mac nilfn))

Oh and yeah: type checking is plenty in-place, if you're building a library. If the library's interface functions simply passed the object to library-internal code without checking, the error will pop up as coming from some code deep in your library, where your user might be less inclined to trace (because it might be your bug, not theirs). At least if you do the check on the interface functions themselves you have proof that the bug is in the user's code.

  This function accepts a list of ordinal types

  (type-declaration a 'Scanner)
  (type-declaration (car a) 'Ordinal)

  {- merge used for mergesort -}
  merge :: Ord a => [a] -> [a] -> [a]
  {- The "Ord a" above asserts that the type "a"
     should be an "Ord"inal, i.e. it should support
     < <= > >= == methods
  -}
  merge [] [] = []
  merge a []  = a
  merge [] b  = b
  merge a:as b:bs
        | a < b     = a:(merge as b:bs)
        | Otherwise = b:(merge a:as bs)
  {- Of course, I haven't programmed Haskell in a while,
     so the above code might be wrong. -}

  (def merge (a b)
    (unless (and (has-a (car a) 'Ord)
                 (has-a (car b) 'Ord)
                 (is (type a) (type b)) )
      (err "Type error, needs Ord"))
    (if
      (no a)
        b
      (no b)
        a
      ; now we're assured < works
      (< (car a) (car b))
        (cons (car a) (merge (cdr a) b))
        (cons (car b) (merge a (cdr b))) ))

  (type-check (list a b)
     (Ord a) ((a . as) (a . as)))

This is where I assume Arc will end up building its type system, if it ever does embrace a single type philosophy[1]. Even if it doesn't have a message-passing model, its dynamism makes the implicit has-a model a good fit.

The only language I've seen that embraces explicit checks for has-a relationships, as opposed to expressing them as is-a or making them implicit, is Javascript. This is mostly because you're dealing with objects that have an inherently variable and ill-defined interface that you don't know a lot about at compile-time. I think most JS developers view it as an annoying necessity, though, so I'm inclined to believe it's the least pleasant way of dealing with has-a (despite being the most explicit).

However as is it's possible to use p-m: or kennytilton's dsb (which should really be ds-b: and put on the arc-wiki.git) for destructuring scanners.

Also the syntax for creating scanners should really be neater. Possibly this might help:

  (mac scanner args
    (let (a d) nil
      ( (afn ((opt val . args))
          (if
            (iso opt ''car)
              (= a val)
            (iso opt ''cdr)
              (= d val)
              (err:tostring:pr "Unknown option - " opt))
          (if args (self args)))
        args)
      (w/uniq (a-v d-v a-valid d-valid)
        `(let (,a-v ,d-v ,a-valid ,d-valid) nil
           (make-scanner
             'car (fn ()
                    (if ,a-valid ,a-v
                                 (= ,a-valid t
                                    ,a-v ,a)))
             'cdr (fn ()
                    (if ,d-valid ,d-v
                                 (= ,d-valid t
                                    ,d-v ,d)))))))) 

  (def inf-iter (f c)
    (scanner
      'car c
      'cdr (inf-iter f (f c))))

  (def foo args
    (apply (last args) (cut 0 (- (len args) 1))))
  arc>(foo 1 2 3 +)
  6