Initial interpreter structure - #49
Conversation
| Some("eval") => { | ||
| let filename = argv.get(2).expect("fix eval: expected a command file"); | ||
| eval_file(filename); | ||
| } | ||
| Some(other) => panic!("fix: unknown command '{other}' (expected: init | eval <file>)"), | ||
| None => panic!("fix: expected a command (init | eval <file>)"), | ||
| Some("interpret") => { | ||
| let filename = argv.get(2).expect("fix interpret: expected a program file"); | ||
| interpret_file(filename); | ||
| } |
There was a problem hiding this comment.
What's the difference between eval and interpret? I don't think we should keep both syntaxes around if that's what the distinction here is—maintaining one text format is enough work. If this is just for development until the new syntax is complete that's fine, just make it clear in the code that the old syntax must be deleted once the new one is finished (and maybe call them eval and eval-v2 or something so they're clearly a lineage, not a branching choice).
| Statement::Assign { name, expr } => { | ||
| let handle = self.interpret(&expr); | ||
| self.context.insert(name, handle); | ||
| } |
There was a problem hiding this comment.
Our new version isn't going to have statements at all, right? In Scheme (approximately) everything is an expression.
| R ::= &B | &T Ref | ||
| O ::= B | T | R Data | ||
There was a problem hiding this comment.
It would be nice if this grammar were actually used directly by the code, rather than being a documentation file that will inevitably get out of date. Some Rust parsing crates support this, I'm not sure of any of them work in no_std but it's possible. I know chumsky supports no_std but it uses parser combinators instead of an external BNF grammar.
Also I'm not sure handles should be a thing at this level? This seems more like you're using it to mean "any value", which is semantically different than a "handle"; Handles are a concrete 32-byte in-memory "pointer" in the implementation, while values are abstract objects in Fix. (although the meaning of "value" vs. "object" vs. "expression" vs. whatever else has changed a lot over time...)
f21c878 to
a98500a
Compare
a98500a to
8c366b3
Compare
Akshay-Srivatsan
left a comment
Akshay-Srivatsan
left a comment
There was a problem hiding this comment.
Looks good overall, but I think our addblob example should stay simple/straightforward and the other features should be delegated to a specific demo (or a folder of example programs).
| (let ((add @"./target/x86_64-unknown-none/addblob")) | ||
| !*(add *(add ^&2 3) 1)) No newline at end of file |
There was a problem hiding this comment.
While this is a good way of showing off the different features... maybe our primary example shouldn't be doing this in such a complicated way. Could you split this into an addblob.fix which just does *(add *(add 2 3) 1) and a separate (commented, if we have a way of doing that?) demo.fix that demonstrates the different features?
There was a problem hiding this comment.
We added some tests and a small demo.fix. Do you think it is ready to merge?
3 participants
PR Description
Future Work