That said, I did recently write an app which used symbols as de facto strings, and the text file format being used as a configuration/task description file by the user was just an s-expr format. The app wasn't written in Lisp or anything like it, which was why I settled for using symbols as strings (to make it easier on my readerfunction - I just didn't have a separate readable string type).

Given that experience, well, I really must insist that having separate strings and symbol types are better. In fact in the app I wrote it for, the config/taskdesc file was just a glorified association list (where the value is the 'cdr of the list, not the 'cadr)!

About lists of chars. Rather than analyzing lists every time to see if they are strings, what about tagging them? I've mentioned before that I think Arc needs better support for user defined types built from cons cells. Strings would be one such specialized, typed use of lists.

I introduced file-table.arc here: http://arclanguage.com/item?id=3762

The series of "create your own collection":

http://arclanguage.com/item?id=3595 Suggest PG: Settable function objects

http://arclanguage.com/item?id=3698 Create your own collection in Arc: settable functions now implemented on arc-wiki.git

http://arclanguage.com/item?id=3762 Create your own collection: use directories as if they were tables with file-table

http://arclanguage.com/item?id=3858 Create your own collection: bidirectional tables

http://arclanguage.com/item?id=5254 Create your own collection: cached-table

Personally I think memory should be managed by refcounts, and GC only when the cyclic garbage adds up. However adding refcounts is somewhat harder since every state-mutating 'set, 'sref, 'scar, 'scdr, and 'cons needs to decrement the current obj refcount and increment the new obj refcount.

Which brings to mind the Lisp koan (http://www.lisp.org/humor/ai-koans.html):

One day a student came to Moon and said, "I understand how to make a better garbage collector. We must keep a reference count of the pointers to each cons." Moon patiently told the student the following story-

    "One day a student came to Moon and said, "I understand how to make a better garbage collector...

On the opposite, palying with mzscheme's or Lua's FFI is a real pleasure : you don't have to bother with GC. You even have (sometimes) your malloced object collected for you.

But if we can cetnralize the refcount operations in a single (or a very small number) of places, I'm OK... Their talking about stack_push / stack_pop is rather inspiring...

For information : On a GC-relativey-intensive program (mainly calculating (fib 40), which generates a lot of garbage), and with a heap of 50 million possible references, for a total time of 228000 ms, i got the following GC info :

  total time : 177ms, nb cycles : 17, max time : 42ms, avg time : 10 ms

Really? You've tried it? Because docstrings are supposed to be removed by the unused global removal step.

Edit: I just did. This is a bug.

  -#define CAR() { if (TOS() != NILOBJ) {pair * p = (pair *) POP(); PUSH((obj)(p->car)); }}
  -#define CDR() { if (TOS() != NILOBJ) {pair * p = (pair *) POP(); PUSH((obj)(p->cdr)); }}
  +#define CAR() { pair * p = (pair *) POP(); PUSH((obj)(p->car)); }
  +#define CDR() { pair * p = (pair *) POP(); PUSH((obj)(p->cdr)); }

Now I'll introduce to you a special syntax in Stutter. In Stutter, () introduces a data constant called an array, which is just like any other sequential data collection in any other language. So it's possible to do something like this in Stutter:

  set[var  (1 2 3 4)]

  set[var (1 "hello" ("sub-array" 4 ))]

  set[var (hello world)]

The array is just like any other array in any other language. You can concatenate them like so:

  set[var append[(array 1) (array 2)]]
  => now var is (array 1 array 2)

  set[var cons[1 (some array)] ]
  => now var is (1 some array)

  nth[1 (this is the array)]
  => this returns the label "is"

  nil[]

  array["hello"]
  => returns the array ("hello")

They called their Stutter interpreter "lave", because they were hippie wannabes and were tripping at the time they were choosing the name. It was supposed to be "love", but like I said, they were tripping.

Of course, since lave accepted arrays, it couldn't get at the nice f[x] syntax. So they decided that the first element of an array would be the function name as a label. f[x] would become the array (f x).

lave had some limitations. For example, instead of Stutter's nice infix syntax a + b, lave needed (plus a b). Fortunately lave included a plus[x y] function which was simply:

  define plus[x y]
   x + y

  cond[
    { x == y
         ...your then code...
    }
    ;yes, what can I say, Stutter's BDFL is lazy
    { !(x == y)
         ...your else code...
    }
  ]

  (cond
    ( (eq x y)
      ...your then code...)
    ( (not (eq x y))
      ...your else code...))

  if[
    (eq x y)
    (...your then code...)
    (...your else code...)]

It looked like this:

  define if[c then else]
    append[
        (cond)
        cons[c
          array[then]]
        cons[ append[(not) array[c] ]
          array[else]]]

  lave[
    if[ (eq x y)
         (...your then code...)
         (...your else code...)
     ]
  ]

Basically, you could tell lave that certain Stutter functions would be treated specially in their lave-syntax. These functions would have the "orcam" property set in some private data of lave. Instead of just running the function, lave would extract the array components, pass them to the function, and then run whatever array that function returned. So you could simply say:

  lave_set_orcam_property[(if)]
  lave[
   (if (eq x y)
      (...your then code...)
      (...your else code...)
   )
  ]

  define for[s c u code]
    append[ (begin) //begin{} is just a compound statement
        cons[ s
            append[(while)
                cons[c
                    cons[ code array[u]]
                ]
            ]
        ]
    ]

  for[(set i 0) (less i 42) (preincrement i)
    (begin (print i))]

  (begin
    (set i 0)
    (while (less i 42)
       (begin (print i))
       (preincrement i)
    )
  )

  lave_set_orcam_property[(for)]
  lave[
    (for (set i 0) (less i 42) (preincrement i)
        (begin
             (print i)
        )
    )
  ]

Soon after lave's creators added orcam-property-functions, Stutter's BDFL decided to do something about the language. He was always bothered about the bug in Stutter array syntax where something like (hello world) would return, well, the array (hello world), instead of sensibly returning an array with the values of hello and world. So he introduced the `, syntax. An array constant prefixed with "`" would have a special meaning. It would not be completely a constant. Instead, when it saw a "," Stutter would evaluate the expression following the comma and insert that element into the array being created. So `(,hello ,world) could now become (42 54), if hello was 42 and world was 54.

Some of the top ocam-property-function writers realized that Stutter's new `, syntax would really, really help. For example, instead of the kludgy, virtually unreadable if code, you could just write:

  define if[c then else]
   `(cond
        (,c ,then)
        ((not ,c) ,else)
    )

  define for[s c u code]
     `(begin
          ,s
         (while ,c
              ,code
              ,u
          )
      )

Because of this, creating orcam-property-functions became easier and their power skyrocketed. Other languages which automatically evaluated variable labels in their arrays couldn't imitate it (so what was originally a bug - that (hello world) did not evaluate the variables hello and world - became a feature). Worse, those other languages' arrays sometimes couldn't themselves contain arrays, or even have different types.

Their arrays just weren't powerful enough to hold code, so other languages never managed to create a powerful orcam-property syntax.

Eventually, people were writing Stutter programs like so:

  lave[
   (define (fn x)
      (if (less x 1)
          1
          (times x (fn (minus x 1)))
      )
   )
  ]

  while[true]{
    print[ lave[ read[] ] ]
  }