The apply function takes a function, any number of arguments, and a list, to wit (apply f x0 x1 x2 ... xN args). This is the same as (f x0 x1 x2 ... xN args.0 args.1 args.2 ... args.M). This allows you to construct argument lists at runtime, which can come in very handy.
> gotta remember that that the non-consing version of APPEND is not NAPPEND but NCONC, for example
Ah, consistency: yet another thing lacking in Arc. Take 'afn and 'acons, for example. Or 'acons and 'number. Or 'number and 'string. Or 'string and 'sym...
> a let just to bind one local at the head of a function really bugged me, so I would use &aux to avoid it.
> Of course I try not to use LET (I think there is a tax on it)
In Cadence Skill, the lisplike we use in the office, 'let does have a tax to it when using lexical bindings; environments were pretty hefty objects and using 'let in a loop would generate a lot of them as garbage (the language implementation doesn't even have tail call opts!). I ended up using @optional (approximately equal to &optional) for some variables in time-constrained code, which helped reduce environments.
Heck no. We can do this ourselves. Remember, the textual transformation to transform let's is just that: a textual translation. It should be possible to create an automated translation tool (based off raymyers' treeparse) that will handle this for us.
Let the old version of 'let be Arc2Let, and the proposed new let be Arc2.7Let. Let the old version of 'with and 'withs be Arc2With and Arc2Withs, respectively. We need to determine if each Arc2Let in the source is composed of a single expression in the body. If it is, we leave it as-is. If it isn't, we simply replace it with Arc2.7As.
For each Arc2With we determine if the body is composed of a single expression. If it is, we replace it with Arc2.7Let, removing the parens around the Arc2With bindings. If it isn't, we leave it as-is. Ditto for Arc2Withs, replacing it with Arc2.7Lets.
We define an expression simply as a sequence of whitespace, base-expression, and whitespace. We define whitespace as being either a comment (either #||# or ;) or ordinary whitespace.
A base-expression is simply a symbol, a number, a character, a string, a quote-expression, a comma and comma-at expression, or a list. A quote-expression is simply the ' quote or ` backquote character followed by maybe whitespace, followed by an expression; comma and comma-at are defined similarly. A list is composed of an opening parenthesis followed by many expressions, followed by a closing parens.
We can determine if a 'let form has several expressions by defining two variants of a 'let form. An Arc2Let is composed of ( <maybe whitespace> let <whitespace> <expression> <expression> <expression> [many <expression>]), and that we have to transform to Arc2.7As (by filtering out the let expression using treeparse 'filt). An Arc2.7LetCompatible is composed of just (let <expression> <expression> <expression>), which we do not transform.
----
Of course, this does represent a veritable fork of the Arc code ^^.
I would leave with and withs alone, so that we have the option of the implicit do (also because it makes it easier to implement given/Anarki-let :P). And why not use a code-tree-walker if we want to do this—isn't that the point of Lisp?
Right, comments. Just a little important, aren't they? :P
You raise a good point... it's the same number of parentheses either way. But in that case, why not just have let and lets (as given(s)), and be done with it?
Edit: as an aside, given that pg has said that he'll modify Arc as if there's nobody else programming in it, and that he does not appear to be using Anarki, eventually when Arc3 does come around, it is very possible that Anarki will be incompatible with Arc3. We may very well need to build a converter program in the future to transform Arc2-base Anarki to Arc3-base Anarki, so my abstract nonsense may very well be necessary in the future.
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:
1.
defcall
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)
; else
(let handler ((arc-symeval 'call*) (arc-type hd))
(if handler
(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 (old)
(set sref
(fn (c v . i)
(if (is (type c) 'thread-local)
(thread-local-set c v)
(apply old c v i)))))
sref)
So, yes, for full Anarki compatibility your first priority is the call* table/defcall.
3.
ssyntax
ssexpand
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
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.
