This may not an issue for you or for your own work environment, but if I continue to publish techniques that people wish to share professionally I'm imagining that some may find the name "Cat Dancer" to be an unnecessary distraction. So I put up another copy here in case:

  arc> (type (coerce "0" 'num))
  int

  (def isa (x y)
    (or (is (type x) y)
        (and (is y 'num) (is (type x) 'int))))

  arc> (isa 34 'num)
  t

  ((eqv? type (ar-type x)) x)

However, using the code from the source file is not always possible as you may have typed it in from the repl, or that file may have changed.

Also, many people may not actually indent their code properly, and 'src presumably should provide some sort of standardization.

The only reason that I can think of for reading the text directly from the source file would be that you would get all of the comments as well, not just the docstrings.

Haven't really thought about it yet... :)

One option that I can think of is to just put it at the top of the file containing the hack.

That would prevent the information from being changed, since a hack (with a particular label) needs to be immutable.

So, another option would be to have the info distributed as a file with the same name as the hack, but a .info extension

For publishing a release, I'd personally use http://website/shader.ppr0.arc for the sake of typing less dots, but http://website/shader.ppr.0.arc is fine too.

Should case be indented like 'if:

  (case
    a
      (b     )
    c
      (d     )
    (e      ))

  (case
     a (b    )
     c (d    )
     (e     ))

  (case
    a-short     (b ...)
    c-very-long (d ...)
                (e ...))

  (case
    a-short
      (b ...)
    c-very-long
      (d ...)
    ; else
      (e ...))

  (each type-frag types
    ; Assemble the ('type name) pairs into two lists, so that we can iterate
    ; through them.
    (case (type type-frag)
      ; If it's a symbol, then we're defining a new name; add a new set of
      ; values, and go.
      sym
        (do
          (zap [cons type-frag _] names)
          (zap [cons nil       _] values))
      ; Otherwise, we're adding a value to an existing variant.
      cons
        ; I changed my mind about the order (now it's (name pred?) instead of
        ; (pred? name)), so I'm reversing it here.
        (zap [cons (rev type-frag) _] (car values))
      ; else
        (err "Invalid member of tagged union declaration.")))

  (def macexn (n expr)
    " Macroexpand `expr' `n' times.  NB: `expr' *is* evaluated!
      See also [[macex1]] [[macex]] "
    (if (and (number n) (> n 0))
      (macexn (- n 1) (macex1 expr))
      expr))

There are some advantages to keeping each library in its own branch:

- It makes the git development history for the library really clear.

- I can propose changes to a library and merge them in to the library branch, without getting messed up by independent merges happening to other libraries.

- If you're using library A and someone commits a change to library B which breaks A, but you can't go back because someone later committed C which you need, what do you do? Make a commit that reverts the B change? But what if someone else is using that B change? Separate branches avoids these kinds of conflicts.

But, of course keeping libraries in separate branches does make using the libraries harder. Instead of just checking out one branch, now you need to use the published versions of the libraries, or checkout a git repository for each library.

I do no longer recommend my idea of having the git commits for a library include their dependencies. That was a good experiment for me to try, and I learned a lot from it, but it turned out not to be useful.

Also, they don't get in the way as you are not forced to read the list, and can choose to track as many or few remote branches as they like.

How about using one branch per library, and tags for versions? That way everyone can track the development and even add things, but the versions are the things that 'lib and others like it go for.

I can think of three scenarios:

1. You're using the public, published version of a library that also happens to be in your git repository.

2. You're using an unpublished version of a library in your git repository: for example, you're testing your code against the latest development version of a library to see if they work together.

3. You're working on a library.

For #3, I presume you'd just be using 'load.

For #2, if you want to for example get the latest version of a file "foo.arc" in the "foo" branch, you can use git for that, e.g.:

  git show foo:foo.arc

I was hoping to use a modified version of 'lib that would allow me to type

  (lib binary)

  (load "lib/binary.arc")