My editor's performance was tanking because of macro interpreter::builtins::builtin!
Temporary solution: move the interpreter into a separate crate
If I intended to keep the interpreter around, in the long-term, it might be an idea to make a proc-macro for builtin expansion.
However, the only reason I need the macros is because the interpreter's dynamic typing implementation is so half-baked. After I bang out the new type checker/inference engine, I'll have to rewrite the entire interpreter anyway!
- Allowed builtins to self-describe
- Broke builtins into their own module
- Created a macro to work with BuiltIns easier
- Uses macro 2.0 syntax, so it requires passing in ALL externally referenced identifiers
- Luckily, this is already a requirement of good, readable macro definitions!
- As a temporary hack, turn overloadable operators into function calls
- This is kind of pointless at the moment, since there can only be one definition of a function per name (no ADL/function overloading/traits/type namespaces yet!)
- This is also pretty slow, but benchmarking shows it's not as slow as I thought (~400x slower in release mode than a native Rust implementation when running `fib.cl`/`fib.rs`. Totally unacceptable for most work, but this is a tree walk interpreter.)
- TODO: Remove this when desugaring from operators to function calls is implemented
- Note: This adds a dependency on Crossterm, to set the terminal into raw mode. This could be eliminated by linking the libraries Crossterm uses directly... Or I could embrace Crossterm, and use it for all escape sequences in the terminal, instead of assuming DEC VT500 compatibility.
- Rewrote the grammar
- Rewrote the AST
- Rewrote the Parser
- Removed pretty printer (now handled by ast::ast_impl::Pretty, a Writer wrapper)
- Added items, and new keywords to go with them
- Syntax is ~maybe temporary, based on Rust syntax
- Remove interpreter struct
- Replace with `Interpret` trait
- This separates concerns dramatically! Yay!
- Implement block scoping via `Frame` abstraction
- TODO: is this the right abstraction?
- TODO: Modules??
- TODO: What environment should be passed into a function call?
ast:
- rename Name.name to Name.symbol (name.name.name.name.name.name.name is very readable, yes yes)
