Which reminds me... rocketnia, you mentioned being able to define vau in terms of wart's magical fn. You're mostly right, except... there will be two ways to grab the environment: the env parameter and the implicit global caller-scope. So that's a bit of a leaky abstraction.
On the other hand, it's quite easy to define wart's magical fn in terms of vau... with no leaky abstractions! The only catch is that caller-scope will always refer to the global scope inside vau forms... that could be changed too, by extending/overwriting vau, but I didn't do that:
(= get-current-environment (wrap (vau () e e)))
;; don't define this if you don't want caller-scope at the global level
(= caller-scope (get-current-environment))
;; simple fn, without magical quoted args or caller-scope
(= fn (vau (parms . body) env
(wrap (eval `(,vau ,parms nil ,@body)))))
;; omitting other stuff like afn, no, caris, list, etc.
;; but they can all be defined in terms of simple fn
...
;; makes these variables hygienic
(with (with with
eval eval
let let)
;; this recreates the part of wart that is currently handled in C++
(= parse-fn (fn (parms env)
(if (caris x 'quote)
(list (cdr parms) nil)
((afn (x vars parms)
(if (no x)
(list (rev parms)
(rev vars))
(caris (car x) 'quote)
(self (cdr x)
vars
(cons (cdar x) parms))
(let c (car x)
(self (cdr x)
`((,eval ,c ,env) ,c ,@vars)
(cons c parms)))))
parms nil nil))))
;; overwrite with the complex fn which has quoted args and caller-scope
(= fn (vau (parms . body) env
(w/uniq new-env
(let (parms vars) (parse-fn parms new-env)
(eval `(,vau ,parms ,new-env
(,with ,vars
(,let caller-scope ,new-env
,@body)))
env))))))
I have not run the above code, but it should give the general idea... Basically, what it does is it takes this...
(fn (a 'b . c)
...)
...and converts it into this (where "g1" is a gensym and "with", "eval", and "let" are hygienic):
(vau (a b . c) g1
(with (a (eval a g1)
c (eval c g1))
(let caller-scope g1
...)))
I know the above code looks verbose, but keep in mind that quoted args and implicit caller-scope is currently handled in C++, whereas I recreated it from scratch using vau + simple functions (defined with wrap).
One more caveat: I'm not sure how you implemented caller-scope. If it's hardcoded into every function such that functions can't have an argument called "caller-scope" then the above will work the same way. But if it's a global implicit parameter like in Nu and ar, then you'll need to search the arg list for an argument called "caller-scope", which is doable but would require some more code, especially for handling argument destructuring.
---
Anyways, I'm not saying you should necessarily do it this way in wart, but... I think it's cleaner, conceptually, for functions to be defined in terms of vau, rather than vau being defined in terms of functions.
Of course, as I already said, if you care about cleanliness, I'd suggest just using Kernel, which doesn't support the magical fn like wart, which I consider to be a good thing.
"Which reminds me... rocketnia, you mentioned being able to define vau in terms of wart's magical fn. You're mostly right, except... there will be two ways to grab the environment: the env parameter and the implicit global caller-scope. So that's a bit of a leaky abstraction."
Hmm... yeah, it's a pretty leaky abstraction. It's one of these features with ambient authority:
(if designed like a global variable assigned at the beginning of each
call)
Right now, get the most recently started call's caller's environment.
(if designed like a continuation mark)
Right now, get the deepest-on-the-stack call's caller's environment.
(if designed like a local variable bound by each (fn ...))
Given a non-global lexical environment, its local variables must have
been initially bound by some call, so get the lexical environment
that was used to evaluate that call.
---change of topic--
...Actually, the first two of these designs are broken! Say I define a simple fexpr like this one:
(def idfn '(result)
(eval result caller-scope))
Now if I run the code ((fn () (idfn caller-scope))), the call stack at the evaluation of 'caller-scope looks something like this:
((fn (a) ((fn () (idfn caller-scope)))) 1) ; eval'd in global scope
((fn () (idfn caller-scope))) ; eval'd in local scope of (fn (a) ...)
(idfn caller-scope) ; eval'd in local scope of (fn () ...)
(eval result caller-scope) ; eval'd in local scope of idfn
caller-scope ; eval'd in local scope of (fn () ...)
IMO, the value we get should be the local scope of (fn (a) ...), so that it doesn't matter if we replace ((fn () (idfn caller-scope))) with ((fn () caller-scope)). However, the calls to 'idfn and 'eval are deeper on the stack and their start times are more recent, so we get one of those caller scopes instead.
Does Wart have this awkward behavior, akkartik?
---/change of topic---
To get back to the point, the local-variable-style version of the feature (the only version that works?) doesn't strike me as completely undesirable. It lets the programmer evaluate expressions in arbitrary ancestor stack frames, and that isn't a shocking feature to put in a debugger.
Sure, it makes it almost impossible to hide implementation details and keep privilege from leaking to all areas of the program, but it could be useful in a language where all code that runs in a single instance of the language runtime has been personally scrutinized (or even written) by a single programmer. That's the primary use case akkartik has in mind anyway.
I'm impressed you're managing to keep track of that with mutation. Are you setting 'caller-scope on every entry and exit of a function and on every entry and exit of an expression passed to 'eval?
Oh, Pauan had mentioned 'caller-scope being a "global hard-coded" variable, and I didn't see you disagreeing, so I assumed you were just assigning to it a lot behind the scenes. :-p
It's likely that as I reflect on vau, wart will start to look more like Kernel.
But I don't think it will become Kernel. Kernel seems really elegant as long as you give up quote and quasiquote. I suspect if you bolt them onto Kernel it'll have slid from its sweet-spot peak of elegance. A language that encourages quoting and macros will diverge significantly from Kernel.
One simplistic way to put it: Kernel is scheme with fexprs done right, while wart tries to be lisp with fexprs done right. It's far from that local extremum, though. It's even possible the wisdom of caring about hygiene in a lisp-1 is deeper than I realize. Perhaps quasiquote needs to go the way of dynamic scope.
"I'm not sure how you implemented caller-scope. If it's hardcoded into every function such that functions can't have an argument called "caller-scope" then the above will work the same way."
If you want 'caller-scope to be built into the language and you want to skirt the issue of name collisions, you could devote a separate reader syntax like "#caller-scope" to it and make it a type of its own.
