metacircular evaluator?

[namin]

Do we want to be able to write a little metacircular evaluator for Lurk? I think it would be a nice stress test, but it might require adding a few more primitives (perhaps number?, symbol? and others). Is this a good time to do this, or should we first consolidate lang.lisp and eval.rs? I think it might be good to do it now, because it's easy and might help us find more bugs.

[porcuquine]

I think it's definitely a good thing to do — both to flush out bugs and to help uncover the minimal must-haves.

Unless the changes are very minor, I'd rather wait to try to propagate them — since it will only make getting lang.lisp cleaned up harder.

In any case, I don't think it's really necessary to do so yet. You could work on it in a lightweight feature branch (for which a draft PR works fine, I think). If the work completes and it seems easy to propagate the changes, we can. But by default let's assume we will wait to merge until the other work lands.

[namin]

I was thinking of just testing in api.lisp and eval.rs for now.

[porcuquine]

Api.lisp is fine. But I'm suggesting that we only implement there initially and not actually merge the work until we are ready to move it everywhere. I think that's a good development path anyway, which mirrors how we are likely to want to do things moving forward. And it lets us do that without entanglement with the other things that need doing before we add features.

[namin]

OK, makes sense.

[namin]

I played with some basic evaluators that can evaluate factorial: https://github.com/lurk-lang/lurk/compare/meta

I ran into a small issue with letrec, that I had to explicitly expand the lambda, but maybe that's OK.

Otherwise, it works in both api.lisp and eval.rs.

[porcuquine]

Cool!

Maybe we should eventually define letrec- (my proposed rename) to only allow function definitions and remove the explicit lambda completely. So it would look like CL's flet but allow recursion, or labels- (an impaired version of labels).

[porcuquine]

I might also not yet fully understand the issue you encountered. If you have a suggestion for the right way to resolve it (if necessary), let me know.

[namin]

In Scheme, it's possible to use letrec* like this:

                 (letrec* ((f (ev rhs (lambda (x) (if (eq x lhs) f (env x))))))
                   (ev body (lambda (x) (if (eq x lhs) f (env x)))))

where the right-hand side of a definition is not a lambda but a complex expression that contains f guarded.
but in api.lisp (and also eval.rs) this generates an unbound f error, and instead, I have to wrap it inside a lambda:

                 (letrec* ((f (lambda (arg) ...))
                   (ev body (lambda (x) (if (eq x lhs) f (env x)))))

I am not sure it's necessary to resolve.

[porcuquine]

Right. Given that our letrec* (which I want to rename, maybe to letrec-) has behavior defined mostly to be fairly simple to implement, it's probably okay that it be awkward to do some things for now.

[porcuquine]

Otherwise, it works in both api.lisp and eval.rs.

If it also works in lang.lisp without needing changes, then I guess we can merge now. In that case, feel free to PR (but also please rebase if needed).