1) We could add a "fail" continuation which is called upon error. By default the "fail" continuation will be the same fail continuation as the caller, but for forms such as 'errsafe and 'after, we replace the "fail" continuation.
2) Alternatively, we use a global (or thread-local...) variable to store the current fail handler. Then 'errsafe and friends will store the current value of the fail handler in a local, replace it with its own, and then run its subforms; afterwards (whether it returned via fail or normal continuation) it restores the previous value of the fail handler.
Idea: macros
1) We could piggyback off the existing Arc and just use repeated 'macex until we reduce down to 'fn and 'if and function calls.
1.1) Then for metacompilation, we could create two levels of Arc: an interpreted Arc and a compiled Arc. Macros are done in interpreted Arc while full programs are compiled. Basically interpreted Arc would simply be an 'eval for Arc, in Arc.
Idea: Arc built-in library
1) In the sample we already have a "built-in" which is in fact added to the source to be compiled: ccc or call/cc. We could extend/generalize this to include a set of built-ins that are added to the source to be compiled, maybe like so:
; assuming car and cdr are true built-ins
(def-arc2c-builtin map1 (k f l)
(if l
(map1
(fn (rest-v)
(f
(fn (v)
(cons k v rest-v))
(%car l)))
f (%cdr l))
(k nil))
> In the sample we already have a "built-in" which is in fact added to the source to be compiled: ccc or call/cc. We could extend/generalize this to include a set of built-ins that are added to the source to be compiled.
I suppose the set of functions to be included would be those in arc.arc and libs.arc, in which case you would just compile arc.arc and libs.arc before compiling the target file, right?
Basically, ccc is handled by detecting if it is used. If it's not used, it's not inserted. When I was talking about extending this, this is what I was referring to: adding code which is defined as "inserted if used".
Simply inserting the entire arc.arc code will add bloat, because most programs don't even use most of the arc.arc code. Given the level of documentation of arc functions (arcfn.com notwithstanding), it is more than likely that the user will not use arc.arc code. So it's better if we simply insert the code if it is used.
Also, it may be better to use arc2c specific code, to take advantage of certain peculiarities in how code is generated. For example, if you decide to use unrolled lists, map1 and friends are better off allocating the full list and then iterating over the values.
This is fine if the compiler is static like Stalin, but if you omit parts of arc.arc that aren't used, you run the risk of not being able to deal with code known only at run time (e.g. (loop:print:eval:read)).
Come now, if you want real support for eval, you'll also need to include the compiler:
(eval `(fn (x) ,@my-variable)) ;how will it build the function?
The alternative is to punt: if there's ever an 'eval, then add arc.arc completely, make 'eval an interpreter which somehow uses 'symeval to lookup globals (and execute global functions as compiled functions), and when it encounters a function, will build the function as an interpreted function (and obviously allow interpreted code to call compiled functions and vice versa).
Basically you create a virtual function:
(def eval (e (o env))
(if
(caris e 'fn)
(add-attachment
'environment env
(annotate 'virtual-function
(cdr e)))
...))
(defcall virtual-function (f . args)
(with (env (get-attachment 'environment)
(arglist . body) args)
; has to be nondestructive
(zap add-args-to-environment env arglist args)
(each e body
(eval e env))))
For macros, that what I thought too. Anyway, we'll need eval for completeness. I don't know how it will behave with compiled code, though, and I know it's not an easy problem as stalin scheme simply ignored it.
For the other points, I didn't think about it yet :)
