Add Scope Analysis #1

New Issue

haxala1r · 2026-02-05T19:27:31Z

haxala1r commented

2026-02-05 19:27:31 +00:00

Currently the compiler only constructs the core AST out of source code. In order to move forward with compilation, it is necessary to resolve symbol accesses and closures. These tasks are more or less related to each other, and so I think they should be done in one stage.

The closure conversion step should take a tree of Core AST and produce a new tree of objects identical in structure to the Core AST but:

Symbol accesses are replaced with a node that directly says "get the nth free variable in the current closure", "get the nth global symbol", or "get this parameter".
Lambda nodes are annotated with how many free variables they use, and which variables in the outer scope are actually captured.

... and any other information required to compile closures and symbol accesses.

Currently the compiler only constructs the core AST out of source code. In order to move forward with compilation, it is necessary to resolve symbol accesses and closures. These tasks are more or less related to each other, and so I think they should be done in one stage. The closure conversion step should take a tree of Core AST and produce a new tree of objects identical in structure to the Core AST but: - Symbol accesses are replaced with a node that directly says "get the nth free variable in the current closure", "get the nth global symbol", or "get this parameter". - Lambda nodes are annotated with how many free variables they use, and which variables in the outer scope are actually captured. ... and any other information required to compile closures and symbol accesses.

haxala1r self-assigned this 2026-02-05 19:27:31 +00:00

haxala1r added this to the olisp project 2026-02-05 19:27:31 +00:00

haxala1r commented

2026-02-11 20:51:58 +00:00

Upon further consideration, I have decided that this way of handling closures is not appropriate. Reasons for this include:

Flat closures lead to a lot of wasted space when all functions are unary. Flat closures usually work best when multiple arguments can be stored in the same closure object, but since the language is curried (and thus all functions are unary), this leads to calls to functions with multiple functions allocating several closure objects.
Such allocations are expensive.
Flat closures are somewhat more complex to implement.

I have instead decided to implement a simple dynamic linked list approach to environments. This approach is much simpler to implement, and the previous approach practically degenerates into a linked list when all functions are unary anyway.

Upon further consideration, I have decided that this way of handling closures is not appropriate. Reasons for this include: - Flat closures lead to a lot of wasted space when all functions are unary. Flat closures usually work best when multiple arguments can be stored in the same closure object, but since the language is curried (and thus all functions are unary), this leads to calls to functions with multiple functions allocating several closure objects. - Such allocations are expensive. - Flat closures are somewhat more complex to implement. I have instead decided to implement a simple dynamic linked list approach to environments. This approach is much simpler to implement, and the previous approach practically degenerates into a linked list when all functions are unary anyway.

haxala1r changed title from ~~Finish Closure Conversion~~ to Add Scope Analysis

2026-02-11 20:54:14 +00:00

haxala1r moved this to Initial work done in olisp on 2026-02-11 20:55:04 +00:00

haxala1r referenced this issue

2026-02-11 20:56:22 +00:00

Make a new interpreter #2

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: haxala1r/olisp#1