(lambda) is confirmed working in kaslisp! I decided that I wanted most of my unit-testing code for (lambda) to be written in kaslisp itself, so I ended up also adding (not), (or), (and), (is?), and (set) which were all surprisingly easy to make!

I also decided that I’m no longer going to represent the boolean values true and false as 'true and 'false. instead they’re represented by the Python versions of True and False which simplifies my Python code a fair bit in several places

just implemented (let)! and I actually understand namespaces so well now omg. like I was always kinda fuzzy on what exactly a namespace is in a programming language and exactly how it works, but now having made my own namespace system and thought through all the edge cases, I think I have a really good grasp of them

or at least, I have a really good grasp of how I want them to work lol. who knows if other languages do them differently

@kasdeya do you prefer lexical or dynamic scopes with your name spaces?

@drawnto woah… I just read about dynamic scopes and they are so strange and counterintuitive to me! they seem like a very bad idea to me to be honest, although maybe there are use cases for them. kaslisp uses lexical scopes (which, I didn’t know what that meant either until just now! so I’m glad you mentioned this distinction - thank you) and I actually have some unit-tests to make sure that variable scopes are working correctly (for example, that local variables shadow non-local variables and when you change them the non-local variables are left unchanged)

@kasdeya
They make very much sense if you implement scopes as a stack of dicts from symbol to values you build up and tear down at run time

@drawnto ohh, huh! kaslisp does essentially do this (whenever a new namespace is created, it becomes the child of the previous namespace. then that child namespace gets garbage collected after the scope ends. so it all happens at runtime using a stack-like structure)

but I looked up the behavior of dynamic scopes on StackOverflow and it looks like they work like this:

local x = 0 -- we'll call this x0

function setX(value)
    x = value
end

function setLocalX(value)
    local x = value -- and this is x1
end

print(x) -- prints x0, which is 0
setX(1) -- x0 is now 1
print(x) -- prints x0, which is 0
setLocalX(2) -- x1 is now 2
print(x) -- prints x1, which is 2

and kaslisp doesn’t work that way. instead when setLocalX returns, kaslisp would clean up the namespace containing x1 and revert to x0 instead

so based on that I think that what I’m doing counts as lexical scoping instead of dynamic scoping