It's not linked to at all yet, you have to be "in the know" so to speak.
As an aside, I think someone mentioned that rainbow has "true" local macros, but ArcN and Anarki does not: i.e. macros that are shadowed by 'let, 'with, or function parameter names are overridden. Since "true" local macros would be difficult to compile except with a full data flow analysis, we might expect you to reverse this otherwise desirable behavior to be more ArcN/Anarki compatible.
Basically macroexpansion will have to be done before actual evaluation, using only global bindings for macros, which is how ArcN does it (and, of course, which is the "spec", hahaha).
Some features in Anarki that will require modification of the base set:
This is implemented by using an Arc-accessible hashtable. Basically your 'apply function has to lookup the type of the object being applied in this hashtable, and use the function you get, unless it's a 'fn:
(def arc-apply (hd args)
(case (arc-type hd)
fn (apply-function hd args)
(let handler ((arc-symeval 'call*) (arc-type hd))
(apply-function handler hd args)
(err "Call on inappropriate object")))))
Note that 'arc-type above is different from the arc-side type ^^. The arc-side 'type can be redefined from Arc, but we don't expect you to use the redefined 'type (redefining 'type is used to fool Arc code, i.e. to create 'file-table that quacks like a 'table, but it depends on the base call* system actually working properly)
Note that you (or we could implement it, for that matter) could possibly use the 'defcall system to transform (java-field object 'field) to (object 'field) - you just have to give a good type code for java objects. We can then redefine (sref ....) to accept (sref object value 'field), where object is a java object, as a call to (java-field object 'field value)
thread-locals are boxes whose contents are settable per-thread. Currently child threads inherit the contents of the parent thread's thread-locals. thread-local objects are accessible via thread-local-ref and thread-local-set in the base system, but arc.arc helpfully redefines 'sref and adds an entry to the call* table:
(sref call* thread-local-ref 'thread-local)
(fn (c v . i)
(if (is (type c) 'thread-local)
(thread-local-set c v)
(apply old c v i)))))
So, yes, for full Anarki compatibility your first priority is the call* table/defcall.
In ArcN only 'ssyntax is accessible from Arc-side; 'ssyntax simply returns a boolean which determines if the symbol has ssyntax, while ssexpand (not on ArcN!) performs the actual expansion. Note that ssexpand may return symbols with ssyntax (i.e. it's assured of expanding only once).
In Anarki, the base system actually uses the Arc-side 'ssyntax and 'ssexpand. By default they are defined in 'ac.scm, but they can be redefined in Arc-side: http://www.arclanguage.org/item?id=6370
Err, this is just what I defaulted it to. Normally underlying scheme doesn't default to inheritable, but I thought it might be useful.
Note that as of now there are zero applications/libs which make use of thread-locals, and there are zero applications that require inheritability. In theory, you could still safely modify Anarki's thread-locals away from that default, but then what if...
> scheme semaphores appear to work much like java's wait/notify
Being a complete JAva noob, I wouldn't actually know. However in the mzscheme docs a semaphore is a synchronized up/down counter. A wait (via 'sema-wait) on a semaphore will wait for the counter to be nonzero. A post (via 'sema-post) on the semaphore will wait for the counter to be nonzero, and then decrement it. So it's really a generalization of a mutex (which is just a flag).
I'm building a shared-nothing message-passing processes library which depends on the "counter" behavior (specifically the semaphore contains the number of messages that the process has received that it hasn't put into its own mailbox yet.)
> > In ArcN only 'ssyntax is accessible from Arc-side
> I don't understand: ssexpand is also callable from arc.
This is correct. My bad ^^
> 'ssexpand appears to be invoked at the same time as macro-expansion - is this correct?
> I'm guessing that the base system should invoke the ssexpand defined in arc in order to expand symbols correctly.
For Anarki compatibility.
As an aside, this feature is currently unused in Anarki because of the severe slowdown in macroexpansion.
> Does any anarki code depend on the implementation of 'annotate using vectors?
Yes, lib/settable-fn.arc . However, take note that this was written before defcall, and in fact 'defcall was written in response to this. lib/settable-fn2.arc is a rewrite which uses 'defcall.