2) If you look at the block surrounding the code you put up:

  (with (items (table)
         ids (sort > (map int (dir storydir*))))
    (if ids (= maxid* (car ids)))
    (noisy-each 100 id (firstn initload* ids)
      (let i (load-item id)
        (push i (items i!type))))
    (= stories* (rev (merge (compare < !id) items!story items!poll))
       comments* (rev items!comment))
    (hook 'initload items))

But there are many instances it has been used on single symbols like !id. How do I interpret that?

You mean whether it's a topic with a URL and no text or a topic with text and no URL, right? Hmm, it looks like 'item-page is responsible for displaying the /item?id=... URL, and that calls 'display-item-text to display the textual content of the post. The implementation of 'display-item-text looks like this:

  (def display-item-text (s user)
    (when (and (cansee user s) 
               (in s!type 'story 'poll)
               (blank s!url) 
               (~blank s!text))
      (spacerow 2)
      (row "" s!text)))

a!b and (!b a) are equivalent:

  arc> (= a (table))
  #hash()
  arc>(= a!b 42)
  42
  arc> a!b
  42
  arc> (!b a)
  42
  arc> (is a!b (!b a))
  t

Would it be possible to do some sort of webcast teleconference? That would make it a lot easier for some of us immobile/distant community members.

To answer the other questions:

2. Same as everyone else - learn more about alternate implementations of arc, with an eye towards doing one myself.

Whenever I see something like a design pattern, I immediately start wondering what kinds of "complete abstraction" could be built out of it, to either make its construction easier, or less likely to be broken by someone new joining the project. As useful for testability as this revelation seems, it also seems like it could be easily broken by someone merely not observing the order conventions.

For example, the rule says that code shouldn't depend on code that comes after it, but then what about recursive definitions? Asking the question leads me to discover things like extend and defrule.

It's really interesting that you start with a simple axiom and end up with something largely overlapping with the principle of separation of concerns.

I say 'overlapping' because I sense you aren't quite using extend in the same way. You're using extend more rigidly (no negative connotation intended) than me, chopping your functions up into finer bits than I do.

Hmm, I find myself focusing on the parallel between overrideable definitions in dynamic languages like arc and ruby, and languages like haskell that permit defining functions in multiple clauses:

  fact 0 = 1
  fact n = n * fact(n - 1)

Yes, I should probably clarify that usually I'm not that rigid either. Most of my Arc programming is exploratory programming (figuring out what it is that I actually want) not engineering (implementing a solution to known goals).

Now the transition from exploratory programming to engineering is an interesting one. If I've created a program (using primarily exploratory programming techniques) and then I want my program to run on Arc-m, that's then largely an engineering effort with an easy to describe goal: I want my program to work the same on Arc-m as it does on Arc-n.

The benefit of keeping tests in a distinct file: you can reason about the final semantics of definitions without thinking about the order in which they are orchestrated. That is a useful simplification except when making large localized changes.

So far none of the macros and higher-order functions that constitute complete abstractions require you to code that way, they just allow you to if you wish. And help you by making the computer do a lot of the heavy lifting.

I'm finding this to be a useful line of inquiry; it's also starting to get too abstract. Are you still thinking about sequential definition, or about design patterns in general?

I use a variation of waterhouse's eval-w/stdout [1] that is essentially the original wrapped in an on-err:

  ; don't especially like name

  (def eval-w/stderr/out (expr)
    (tostring:let result nil
      (on-err (fn (c) (pr "Error: " #\" (details c) #\"))
              (fn ()  (let output (tostring (= result (eval expr)))
                        (unless (empty output)
                          (pr output))
                        (write result))))))

I agree with you and am working on it. The only reason I've hesitated with that feature is that certain errors reveal information about the sandboxing mechanism I'm not sure I want people to have.

  arc> (system "ls")
  subprocess: `execute' access denied for /bin/sh

Other than that, it's really rather cool. Great job!

That was important because you could do things like keyword based arguments to functions, etc. i.e. if you had a function that was defined as

  (defun greet (&key (a "Hello") (b "World")) 
    (print a " " b))

  >(greet)
  Hello World
  >(greet :b "Bob")
  Hello Bob
  >(greet :b "Alice" :a "Yo")
  Yo Alice