inheritable thread-locals? ouch! java has non-inheritable thread-locals out of the box, but if inheritance is really important it could be done ...
scheme semaphores appear to work much like java's wait/notify ... does anybody know java and scheme well enough to comment? Or where is a good place to find scheme docs?
> In ArcN only 'ssyntax is accessible from Arc-side
I don't understand: ssexpand is also callable from arc. Do you mean the arc-side definition of ssexpand is not necessarily the one used by the base system?
'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.
Does any anarki code depend on the implementation of 'annotate using vectors? Rainbow uses a custom "Tagged" class, and anything that assumes 'annotate returns a vector would break in this case.
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?
Yes.
> 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.
