But anyway, I still think they're not worth loosing an ASCII character, and using mathematical notation would be very useful. It would make code readable by people a little aware of mathematics. That is, most programers. It would be definitely better than arbitrary characters.

Why should we restrict to ASCII anyway ? I mean, a lot of symbols I use are not ASCII anymore (they are accentuated, I'm French so something like 'year is translated into 'année, not into 'annee). Sure, they're hard to type, but are they any longer than they symbol counterpart ? If you type them often, just make them a vi macro (or whatever in your favorite text editor) and you're done.

I think you hit the nail on the head there. I know pg has said that he does read the posts even when he doesn't reply, but let's face it, it doesn't take too long to post a comment occasionally. If he even took the time to communicate a vision to the "community", that would be helpful. I think people would be more patient if they had a clue about where this was heading.

Although it's certainly fun to pick up a new language, it also takes time and effort, and I'd like to see more evidence that Arc will continue to progress before I invest much time into it (especially since it lacks a couple "must haves" for me currently).

I think the survivability (not popularity) of a programming language is closely correlated with its usefulness to programmers.

here's something from my experiences: a few times i have released things, and not responded to questions/comments about them for some time. not because i didn't care, but actually because i cared too much. to the people, those things were interesting curiousities, but to me they were things that my reputation was attached to. and so i felt that my statements, responses, and actions had to be well-calculated. and i had to consider the things themselves, which even by their lonesome were no walks in the park. it was somewhat daunting, which led to procrastination

not saying this is exactly the case here, but i remember this footnote: http://www.paulgraham.com/startuplessons.html#f2n

http://arclanguage.com/item?id=5522

I mean, arc2 takes 3 sec. to startup (and it cannot even take command line arguments) and arc2c is not meta-circular yet (and lacks a lot of things, including command-line args, but that is easy to add), so a real benchmarks would need both arcs (one to compile, the other to run the compiler). I don't know the precise status of other implementations, but I guess they aren't mature enough either.

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.

  ; Implementation note : mzscheme's #f can be used as the C NULL pointer
  (= NULL* #f)

  (= callbacks* nil)
  (def sqlite3-callback args t)
  (let cb (ffi-callback sqlite3-callback (list cptr cint cptr cptr) cint)
    (push cb callbacks*) cb)

  ; Here, we defined cb as a callback of type cptr cint cptr cptr :
  ; no cstring here, as we have char** and not char *

  (def topcb () (let cb (pop callbacks*) (push cb callbacks*) cb))

  (w/ffi "libsqlite3" ;in mac os x "sudo port install sqlite3"
    (cdef sqlite3-open "sqlite3_open" cint (cstring cptr))
    (cdef sqlite3-exec "sqlite3_exec" cint (cptr cstring cfptr cptr cptr))
    ; Here again, cptr instead of cstring for error : we need a ptr to string
  (cdef sqlite3-close "sqlite3_close" cint (cptr)))

  ; Last warning : 2nd arg to sqlite3-open is a sqlite3**, i.e.
  ;  it returns the address of the actual sqlite3* used by sqlite3-exex & sqlite3-close

  (= &sqlite3 (cmalloc 4)) ; address of the actual sqlite3*
  (= sqltxt "create table bar (id integer primary key, text varchar(255));")
  (= sqlerrormsg (cmalloc 4))
  (= sqltxtptr NULL*)

  (sqlite3-open "test" &sqlite3)
  (= sqlite3 (cpref &sqlite3 cptr)) ; dereference to have an sqlite3*
  (sqlite3-exec sqlite3 sqltxt (topcb) sqltxtptr sqlerrormsg)
  (sqlite3-close sqlite3)

  (def infinite ()
    (cmalloc 4)
    (infinite))

  (infinite)

Arc has a few advantages : it's got a canonical implementation (the fact that code is specification makes it easier), a charistmatic benevolent dictator and it is directed toward a popular and modern concern : web apps.

It could make Lisp popular, but it needs some kind of killer app. The news app is cool, but it won't be enough. Anybody's got an idea ?

...until you realize that nearly every non-pg, non-rtm Arc user prefers to use the non-canonical Anarki, and recommends it because of the sheer number of bug fixes (never mind the new features, such as 'defcall, 'defm, 'p-m:, 'sync, 'thread-local, 'file-table ... etc.)

> It could make Lisp popular, but it needs some kind of killer app. The news app is cool, but it won't be enough. Anybody's got an idea ?

This also means that if Anarki tries to keep full compliance with ArcN in the future, without pg updating ArcN reasonably frequently, eventually (in a year? half a year?) Anarki will either: 1) die out as a source of innovation, because people will simply rather wait for pg's next update rather than push a change that might be overridden by pg in the future, or 2) drift so far away from pg's internal ArcN that when pg releases it, the merge hell will be very, very hot.

Take an example this: http://arclanguage.com/item?id=6138

  arc> (ssexpand 'foo?x)
  (is foo x)

The fact that broken pg's code is specification is a pain in the back and doesn't make anything easier.

The implementation consists in two arrays : one for the keys, the other one for values. When you look for an object, it goes through the keys array and performs 'is comparison until it finds it. It is as scalable as alists, I know, but I'll work on the actual implementation later...

There are a few other new things. Most notably, the functional notation for accessing parts of lists/strings/hash tables is now implemented : ('(foo bar baz) 2) returns 'baz.

I thought it would bring horrible performance : since something at a functional position can be not only a closure, but also a string, a table or a pair, you have to do multiple dispatch every time you call a closure. Ugh... Well, obviously, gcc (with -O3) is very clever, or I'm missing something, because the actual slowdown isn't really significative.

> There are a few other new things. Most notably, the functional notation for accessing parts of lists/strings/hash tables is now implemented : ('(foo bar baz) 2) returns 'baz.

Cool! How'd you implement it?

call* is not implemented yet.

As for keys in hash tables, I admit I didn't really bother yet. It is quite broken in canonical Arc anyway (and in Anarki too for that matter) : it doesn't work correctly with lists and does not work correctly with strings too (if you update a string key, you're dead). If the hash itself is its own key, it breaks, but I don't know if this is supposed to be feasible or not.

  %string-ref
  %list-ref
  %table-ref

  (= call* (%table)) ;or whatever the table-creating primitive is
  (%sref-table call* 'string
    (fn (s i) (%string-ref s i)))
  (%sref-table call* 'list
    (fn (s i) (%list-ref s i)))
  (%sref-table call* 'table
    (fn (s i) (%table-ref s i)))
  ; for compatibility with existing Anarki
  (set ref
    (fn (c i)
      (if (%is (%type c) 'string)
          (%string-ref c i)
          (if (%is (%type c) 'list)
              (%list-ref c i)
              (if (%is (%type c) 'table)
                  (%table-ref c i)
                  ; dummy stub for error message, when
                  ; errors are implemented
                  ())))))

  obj fn = SYM2OBJ("fn");
  obj typ;
  goto initjump;
  jump:
  // most common case, so check it first
  if((typ = type(LOCAL(0))) == fn){
    goto realjump;
  } else {
    memmove(&LOCAL(3),&LOCAL(2), (num_args - 2)*sizeof(obj));
    ++num_args;
    LOCAL(2) = LOCAL(0);
    LOCAL(0) = table_lookup(GLOBAL(CALL_TABLE), typ);
    //possibly add a check here to see if it's a function
  }
  realjump:
  pc = LOCAL(0)[0]; //or whichever it should be
  initjump:
  switch(pc){
    ...

  -#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)); }