Lexical scope possible?

[wboeke]

Is'nt it possible to introduce lexical or dynamic scope for variables? It is standard for normal lisp's, and it would make mlisp so much more useful.

[kiryk]

Hi @wboeke,
thank you for your suggestion, I agree that it would make a nice feature, especially since it would allow for creating closures.

The main obstacle, I think, is the fact that some types (e.g. numbers) are moved around only by being copied, and so they're not even carried by GC. In its time, this idea allowed me to simplify a lot and save some memory, but with lexical scoping we'll want numbers defined in dead scopes to sometimes stay alive.

As you've probably noticed, I don't maintain this repository actively, but I'll try to find free time to figure out how to bypass the GC mechanics or maybe modify it. It might be a good exercise.

[kiryk]

I've implemented basic lexical scoping. I haven't merged it to master yet but the code can be found on simple-scoping branch. It also has a few smaller fixes.

The mechanic is that now lambdas keep a reference to the context of a function in which they were created, and so the context doesn't get GCed when the function exits. The reference is then used when a lambda refers to a variable that wasn't defined directly in it. If the "upper" context doesn't contain the variable, the search continues inductively, up to the global context.

A more memory efficient solution exists for sure, but this one is pretty simple, and in fact the number of objects kept in memory didn't increase dramatically when I tested the implementation.

I'll merge the branch and close the issue if I won't find any bugs or come up with a better implementation.

[wboeke]

Hello kiryq,
This sounds like a good solution.
I played a lot with mlisp. Syntax is like lisp, semantics is more like C. Recursion is often impossible, while loops should be used instead. A simple cdr is costly, whereas in lisp it's very easy. Without lexical scope not much interesting is possible however. I am going to try your new version tomorrow.

[wboeke]

Hi,
This is okay. Things that did'nt work in the past now give good results.
I have a few suggestions:
This is a small project. Why don't you merge all .c and .h files into one? I did it for the former version, the file became only 670 lines. It makes debugging etc a lot easier.
Would it not be a good idea to print all return values from functions during repl? All lisp's do it, very convenient.
This mlisp is very slow, a recursive (fibonacci 30) takes 10 sec on my machine, whereas comparable lisp's take about 2 sec. I figured out that it is because of the method of garbage collection, so maybe this cannot be improved?

[kiryk]

Thank you for these suggestions. I think I want to keep the files separated, but when it comes to printing values in REPL and doing optimizations -- I'll consider these for sure.

You mentioned comparable lisps, I'd be grateful if you told me which ones you mean. Naturally, I'd like to try them out myself.

[wboeke]

Hello kiryk,
I talked about comparable lisp's. That's because I like to investigate different small languages, especially from the lisp family. In the past, there were a lot implementations, some brilliant, others real crap. Via google, if you search for 'lisp github' you will find a lot.
Good, fast, small lisp's:
aquario
aria (2 x)
cisp
fe
femtolisp
flamingo (my favorite, disappeared from the internet)
komplott
lisp9
minilisp
tiny-lisp
And there might be more ...
Some are real lisp's, most are somewhere between scheme and lisp.