err, it's not a library, it's a full implementation of Arc.
I'll probably also include some method of locking the global (and only the global) but only with a lot of big warning signs around the locking function, saying that this should be used only if efficiency is a real concern. Also, my intended lock is a true lock: no redefinition of the <edit>global</edit> at all.
Also, ssyntax could potentially help with the apparently long symeval!foo form; say: <>foo maybe?
What's so bad about generating function values? The function code is already precompiled, the only thing that (fn ...) does in run time is capture non-global free variables. So 'really-hard-working-optimizing-compiler just needs to output a compileable s-expression, and it will be compiled just once.
I'm speculating here, but maybe I'm in a hurry and I want to use something in my macro without taking the time to rewrite it so that it produces an s-expression.
I actually don't know if having a macro expand into a function value would be useful for anything; I just noticed a way to do it and posted the solution in case it would be useful to somebody someday. (Not realizing that apparently this has been fixed in Anarki already).
The lack of the ability to subclass has been galling. Take a look at the "Create your own collection" series, for example. Each of them emulate tables, but they need to do a lot of background hackery just to emulate tables. And it's hard to determine which subclass of tables it uses.
So I introduce "zen typing". You wear a blindfold (i.e. ignore the type) and just code as if the existing functions will work. Let the functions fight over how to exactly implement them ^^
Eh, but the problem is the assumption that the world itself cannot be modelled as part of the tape that the Turing Machine eats.
From a quick glance through the paper and the LtU comments it seems that its point is that interactive I/O cannot be modelled by the Turing Machine.
But as I've learned in Haskell, I/O can itself be mathematically treated, specifically by monads: the world-before-i/o-event is the monad that is input to a function, and the world-after-i/o-event is the monad you return. And I'm pretty sure that monads themselves can be modeled by TM: they can be represented by a part of the tape that the TM gets to and modifies, just like any function-to-TM mapping.
The problem is that the paper uses words like 'model' and 'function-based' rather vaguely. You can model I/O with a TM, but you can't actually do it, which is what they're getting at.
Really? Can you list the lisps (common lisps, schemes, whatever) that let you do this kind of stuff? And tell me why the ones that don't aren't "serious", according to you?
So, according to you, Python isn't "general-purpose" and Haskell isn't "serious"? I could list many more languages here, of course, but my point is obvious.
It's useful to be able to do lowlevel bitflipping stuff, that I don't deny; and I am suitably impressed by the number of lisps that have put thought into allowing this. But just because a language lacks such capabilities doesn't mean I'd rather use C, or even Lisp! And often, if I'm really interested in lowlevel stuff, I'm also intimately concerned with things like speed and memory usage that I can't necessarily address even in a highly optimized lisp. For example, all lisps need GCs (what if I want to write a GC? I'd rather not have my GC itself need GC, and I'm not learned enough concerning the implementation of eg. SBCL to, like the writers of T, write a GC in it such that the GC needs no GCing), and any Common Lisp necessarily comes with a huge standard library attached.
Edit: as an aside, $ is a "reserved" variable in SNAP; I intend to use it as a sort of "implementation-specific" variable, so any use of $ should be attached very tightly to the implementation of Arc.
Now you would expect every function that references car to use your new version. If you can't trust basic functions such as car, data-flow analysis becomes very hard. I'm not an expert and I have only a vague idea of what data-flow analysis is, but I think this could be the problem. This is only what I think, so I could be completely wrong.
2. Try using the Anarki repository http://arcfn.com/2008/02/git-and-anarki-arc-repository-brief... . I believe this issue is related to the "date bug", where PG used a MacOS(?) specific system call to get the date. Have you tried looking if there are messages on the terminal where you ran Arc?
3. There isn't any. In fact arclanguage.com has indeed been visited by spam.^^
Note by the way that this is the problem that macros in arc2c face: in a single compilation unit, a function defined earlier must be callable from a macro actually used later ^^. Also, to preserve as much of Arc's semantics as possible, a macro could be redefined in a single compilation.
^^
SNAP would sidestep this largely by simply using bits of arc2c only as part of eval - basically eval is simply:
... where arc2b-compile is the bits of arc2c modified to emit the bytecode as a list of symbolcodes, bytecode-compile accepts that list and returns an opaque abstract bytecode-sequence object, and to-free-fun creates a free function (one without any closed variables, i.e. all free variables are globals).
So SNAP will compile expressions one at a time.
However arc2c reads the entire compilation as one big expression, hence the difficulty. It may be possible to modify it so that it compiles files one expression at a time though; possibly this could be done by targeting to a bytecode, and then writing a bytecode-to-c transformer, but it loses some global optimizations (oh well).
Although it might be better to make a thread pool, where each Arc-side thread is a "task" (which will reschedule itself until it ends), much like how Erlang does it and how SNAP will eventually do it. This will allow you to easily launch and destroy thousands of Arc-side threads on a machine with far fewer cores.
Of course there's the minor problem of I/O then... you'll have to use nonblocking I/O in the VM and emulate blocking I/O on the Arc-side by setting up a poll for the Arc-side task.
