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")

A server would effectively be an http folder with a list of arc files and folders in it. There could be a file in the directory with a standard name that the tool would look at first to see what libraries where available, and where they were located.

Then the files wouldn't even have to be located on the same server, they could be anywhere else on the internet, as long as some server has a reference to them.

Every release of a library should have a globally unique name: the publisher (we can use our Arc forum username), the name of the library, and the release number. An example of the full name of my toerr library would be "catdancer.toerr.3"

Every release of a library has to be immutable. Once I publish "catdancer.toerr.3", I must never change it. The reason for this is meta-data about a libraries, conflicts, and dependencies; I might say Fred's foo library release 19 doesn't work with my toerr release 3, but there's no way to know if this meta-data is valid if Fred or I are changing our released versions.

I can unpublish a release if I need to; if "catdancer.toerr.3" has a horrible bug I can remove it from my server and publish a fixed version "catdancer.toerr.4". But I must never reuse "catdancer.toerr.3" for a changed version.

The release number is used internally by the tools. A new release number doesn't mean that the version is better. Compared to "catdancer.toerr.2", "catdancer.toerr.3" may be an alpha version or a release candidate or broken in some way.

If you want to have a meaningful version number for your library, make it part of the library name: "foo0", "foo1", "foo2". That way you can release a fixed version of "foo2" if you need to.

We should also be able to publish meta-data about my libraries. For example, I should be able to publish that "catdancer.toerr.3" is, in my opinion, the best available version of the catdancer.toerr library. Unlike a particular library release, which can be deleted but must never change, meta-data can be updated. I can later say that "catdancer.toerr.4" is now better.

The tools should naturally let me abbreviate library names. If I say (load "toerr.arc") or the equivalent, and there's only a "catdancer" toerr library available (or maybe I have "catdancer" first in my search list), and my meta-data says that "4" is the best one, then it should load "catdancer.toerr.4" for me. But if I want to explicitly load "fred.toerr.19", I should be able to do that.

Every library should be available at an http location by username. For example, if you're using git and github, you can publish your repository using the github Project Page feature (http://pages.github.com/).

Now we'll have a list associating usernames with http locations:

  (("catdancer" "http://hacks.catdancer.ws/")
   ("fred"      "http://fred.github.com/arcstuff/"))

I think that the naming system should use "user/libname/version" so that it can be reflected in the directory structure of the lib folder of arc where they will be downloaded, and can be easily turned into a path. I'd prefer to make it a 'sym instead of a 'string for less typing ;)

Thus the library loading code would be effectively:

  (use libname)

We can also have other functions that fetch the libraries, or make 'use fetch them automatically. In that case it will need to know how to find them. To that end I propose we add a file to the lib folder called something like "server-list" or something. The file is merely a list of http locations, such as hacks.catdancer.ws, and fred.github.com/arcstuff. Each location will be a folder that contains a file named "libs.arc" or similar, which contains all of the metadata necessary to find the libraries belonging to that server.

Possible meta-data: Name of library, file name and location, date updated, author, dependencies etc.

In theory the package system can determine by reading these files which version of the library is newest, (by version number and date) or if given more particular criteria, find an older version.

I'm basing my ideas off of the debian package system, which I have found very useful. The nice thing about it is that anyone can host a package server, and a package can be located on any server. They aren't tied to a particular server by their name, for instance. It also automatically downloads prereqs, which can be very handy.

Summary:

1) Library is named by symbol which can be easily converted to a path: catdancer/erp/0

2) Servers which have meta-data on finding packages, a la debian packages/yum/gems, etc. for ease in hosting and finding packages.

I'd prefer that slashes not be included in the library name, so that it doesn't have to be stored in different directories.

I'll also be able to more easily upload a library to an HTTP directory if I don't need to create subdirectories.

I was also hoping of making a version of your 'lib hack to manage the libs already in the lib folder, instead of just those on the web.

  (lib binary)

  (load "lib/binary.arc")

On a side note, how hard would it be to selectively reload individual functions?

  (reload example-fn)

I think that a good system for version numbers (and who doesn't love copying good systems?) is to have two "latest" versions always available -- a stable version, and an alpha/beta version. The stable versions are the odd version numbers, and the alpha/beta are the evens. Obviously that could be switched, but everybody should use the same convention, and I think this one makes sense because a project starts at version 0, and then the first stable version would be 1.

If this system were used, than only the odd-numbered versions would be required to remain constant. The even-numbered versions could vary as the dev(s) fixed bugs or added features. Odd-numbered versions which depended on other libraries would have to depend on odd versions of those libraries. An even version could depend on any library.

I like the idea of using forum nicknames, because they're unique. URLs are (not entirely, thanks to Internet Explorer...) case-insensitive, so maybe pg should change the forum so that two usernames can't be case-insensitively equal? (If that's the case already, scratch what I just said...)

Meta-data can come in a separate file, named the same as the library. It should probably be some form of alist:

  File arc/keystones/foo.xyzlib/3/meta.arc:
  ((devs   ("John Foo"
            "Bob Baz"
            "Oscar Frozzbozz"))
   (stable T)
   (note   "This library does xyz.")
   (needs  ("catdancer.toerr.3"
            "rntz.pass-to-compiler.1")))

Also, some form of standard directory structure could be good. Each person would be able to customize where their lib/ directory would be, and what it would be called (in the example, my directory is arc/keystones/). However, within that directory, I think there should be some convention of how libraries would be organized. I think one that makes sense is that each library would have a directory, within which each version would have a separate directory. If this is nested too deeply, it could instead be a wide nesting -- arc/keystones/foo.xyzlib.3/

I'm not sure that odd/even version numbers is such a good idea. It could be very confusing that way. I think that CatDancer's requirement of libraries to be static is a much more reliable concept. Otherwise like he said you'd need to check periodically for updates.

Libraries should also be able to depend on whatever they want. That's the author's decision. If they need the beta version, but they've tested it and know that what they have written is stable, then they should be allowed to publish it that way. They can always make a new version if they need a bug fix.

Dependencies should actually be managed outside of the libraries themselves. For example, I have a library foo that depends on bar. Later a new version of Arc comes out that implements what bar did. Now foo doesn't need bar any more. But foo itself hasn't changed, so I shouldn't have to release a new version of foo just to say that it doesn't need bar with this new version of Arc.

Instead we publish dependency information about libraries. For example, I can say that foo needs bar 0 and arc 3, or just arc 4... something like:

  (needs (foo 0) (or ((bar 5) (arc3 0)))
                     ((arc4 0))))

the version numbers should make a definite statement that "catdancer.toerr.3" is an inferior predecessor to "catdancer.toerr.4"

There's a difference between a release number and a version number. A version number, as you say, can be used to indicate that a later release is better, or indicate the stable vs. alpha/beta status of a release, etc. The release number merely identifies releases.

For example, pg had several releases of arc3. Under my naming system, they would have been named "pg.arc3.0", "pg.arc3.1", "pg.arc3.2", etc.

Regardless of the alpha/beta/stable status of a release, two releases of a library should never be released with the same name and release number for several reasons:

- If I'm telling you about a bug in your library, then I can tell you which release if saw the bug in. If you change your library without giving it a new release number, then we won't know if I'm talking about your old release or your new release.

- It's clear when a tool such as my "lib" library which downloads a library from a URL needs to download a new release. If there's a new release number, and I want that new release, then "lib" knows it needs to download the new release. If the release can change at the same URL, then "lib" has to periodically check to see if the file at the URL has changed.

Anarki, as the github fork of arc is called, is a very popular version, as it comes with several libraries and tools which can be very helpful. Basically, when anyone creates an addition to arc and can't wait for pg to adopt it, they put it in Anarki. Currently it's a little bit out of date, because it hasn't caught up to the new arc3, but it's getting there.

The closest thing to the CPAN equivalent would be github, using something like CatDancer's lib function. Unfortunately, while that makes it easy to share libraries, it doesn't make it so easy to find them. That's why many of the libraries are just pushed into the lib folder in Anarki.

So if you want your library foo.arc to land in Anarki in the lib directory, create a patch to Anarki that adds foo.arc to the lib directory in a single commit.

  (mz.function args)
 

  (mz:function __args)

  (def len (x (o c 0))
    (if (isa x 'string) (mz:string-length x)
        (isa x 'vec) (mz:vector-length x)
        (isa x 'table) (mz:hash-table-count x)
        (and atom.x x) (+ c 1)
        acons.x (len cdr.x (+ c 1))
        c))

I think the reason that lists are usually flat lists is that a flat list is homogenous -- each car is data, and each cdr is the next element, or nil. Dotted lists add another case which you'd have to handle. It's just simpler to deal with flat lists.

  arc> def
  #3(tagged mac #<procedure:.../arc/arc.arc.scm:151:11>)

Switching over the entire master branch is essentially impossible, as has been discussed before... although there aren't many incompatible changed between arc2 and arc3, there are enough, and moreover, there are enough differences between arc2 and anarki that integrating the changes to arc3 wholesale into anarki is difficult. Anarki simply has so much in it - bugfixes, hacks, additions, libraries, pet projects, and even reimplementations.

I wouldn't mind helping you with the help/documentation stuff as I wrote some of it (src and the current version of fns), and it's probably my favorite part as well. Right now I'm a bit busy working on a new and improved ppr so that the src function actually returns reasonable looking source code ;)

I have been thinking about a new way to do the source code storage for src. I noticed that every time scheme makes a lambda, it remembers where in the code it was created. That means that the information about where the source is is associated with the lambda object, not the name. What if we modified the way that ac-fn worked, so that it associated each fn with its source code? That way all procedures, macros included, would have their source code available for inspection.

  (each (k v) mytable
    (prn "my key is " k)
    (prn "and my value is " v))

  (copy (obj a 1)
    'b 2
    'c 3)

If the lines after the first line don't fall into their own group, then I'll line up the arguments:

  (+ '(a b c d)
     '(e f g h)
     '(i jk))

  (map (fn (x) ...)
       (generate-my-list ...))

Function calls are indented with all the arguments starting at the same column, for example:

  (calculate-fn-of arg1
                   arg2
                   arg3)

  (while (< x 10)
    (prn x)
    (++ x))

  (with (var1   val1
         thing2 val2
         var3   expr3)
    (do
      (stuff)
      (with-vars)))

  (if (test1)
       (response1)
      (test2)
       (response2)
      (response3))

  (if (test1) (response1)
      (test2) (response2)
              (response3))

  (if (test1)
      (response1)
      (test2)
      (response2)
      (response3))

  (if
    (test1)
      (response1)
    (test2)
      (response2)
    (response3))

  (if a b
      c d
        e)

  (if a
      b
      c
      d
      e)

arc code or scheme code?

However, in this case I agree with Adlai: pg had even planned on getting ppr to "properly indent long ifs". I presume that means to implement the wavy feature. It's also the convention for Anarki, according to the CONVENTIONS file.

So, here's what I'm thinking should be done for ifs:

1) If you only have three expressions, if-then-else, use:

  (if a
      b
      c)

  (if a b
      c d
      ...
        e)

  (if (a       )
        (b       )
      (c       )
        (d       )
      (e       ))

Another question:

How do people indent do, and, or, etc.:

a)

  (do abc
      bcd
      cde)

  (do
    abc
    bcd
    cde)

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))

  (cond ((condition1)
         (result-code1))
        ((condition2)
         (result-code2))
        (default-code))