1. You should make it clear in the README that this uses lazy evaluation, because most Lisps use strict evaluation.
2. `lambda` should have an implicit `begin` around its body to allow multiple forms, e.g.
(lambda ()
(define x 1)
(+ x x))
3. The behaviour of the top-level forms changes when they are wrapped in `begin`. For example, the program
(car 1)
2
4. Since this dialect is pure (no side effects), it should be a syntax error if a non-final form in a `begin` expression expands to some expression which is not a declaration. For example,
(defun f (x)
(g x)
(h x))
In the same vein, you could make it a syntax error if the final form in a `begin` expression is `define` (and likewise for the forms in an `if`).
5. The way `if` handles values other than true/false is backwards compared to most Lisps (and based on the comments in the code I think it's an accident). For example
(if "foo" "first" "second")
This actually teaches me that one thing I should make it clear is this was essentially a weekend experiment from someone who has never used, let alone written a Lisp before.
There's no way it's a production grade software, there are places where the evaluator just borks for valid expressions.
I learned a lot when writing it, so I can probably do a large-ish refactor that would simplify many things and fix the inconsistencies.
> this uses lazy evaluation, because most Lisps use strict evaluation.
The evaluation semantics are pretty weird. It's lazy-ish mostly, but when evaluating there are a lot of places where I unnecessarily force evaluation of things. So I should make the semantics clearer and document them.
> The behaviour of the top-level forms changes when they are wrapped in `begin`
This is a bug, you are right .
> Since this dialect is pure (no side effects)
It's mostly pure. There are a couple of constructs like `assert` and `log` that perform side effects. And also as you mentioned the expressions in a begin can be macros that end up modifying the environment.
> The way `if` handles values other than true/false is backwards compared to most Lisps
You are likely correct and this is a bug!
---
Thanks again of your comments, I'll try to find some time to either rewrite the project, or at least document it better.
Please don't rewrite it on my account (I'd just mention laziness and fix the `if` bug since it's trivial: https://github.com/utdemir/nixlisp/blob/4e0eec383363df72b7b4..., the comment already says the right thing). It would be interesting to see the "bork" examples if you still have them on hand (I'd even put them in the README).
It was fun to play with, thanks for making and publishing!
Perhaps it is pure excepting the top level, where mutations such as define are permitted.
(The only situation where `define` might be considered "impure" is if it was used to redefine a variable that already existed in the same scope; and even then, it could still be considered "pure" as long as it created a new variable instead of mutating the original variable.)
(import ./default.nix).eval {} ''