leilamoussa/interpreted-pl-env

An end-to-end programming language environment, from high level language to machine language-like code and execution. Group project for CSC 3315.

interpreted-pl-env's Issues

patches to work on when we can

Here, we keep track of what to modify in old deliverables that can be submitted with future deliverables. Add whatever has been bugging you about the old stuff or things we discover to be incorrect/incomplete.

• Debug interpreter with MLcode3
• Debug assembler
• Correct (if needed) & rename AL codes 2 & 3
• remaining assembler issue: when there's exactly one trailing \n in the AL code, fgets() behaves strangely in the end
• Rethink interpreter loop logic: keeping initial AC value intact as opposed to referring back to it
• add optional CL args for assembler
• forward label logic for assembler (high priority if we decide labels are a thing)
• update ML sample programs details
• update AL sample programs details
• make a very good README as a comprehensive e2e documentation (high priority, continue working on this)
• optimize all code we've written
• Decide once & for all: do we need labels?
• low priority, more of an aesthetic todo: .asbl or .asm, .hlpl
• disable interpreter warning or deal with it somehow (low priority)
• Make gcc output interpreter.exe or assembler.exe rather than a.exe (just use -o flag with gcc command)
• make sure C files run in C-free (i don't have it installed -- do you?)
• do the lexer-parser thing (parser imports lexer as a generator object)

lexer todos

• fix inconsistencies with regex/token names
• test basic functionality and output a visible stream
• fix RE order: KWs first
• solve @ and # problem
• handle reserved words (according to our understanding of the prof's expectations)
• populate symbol table (to an extent, but works needs to be done)
• populate literal table (looks good but useless lol)
• symbol table: how to identify the information to be used upon each encounter (what my last email to the prof was about)
• save tables as files when done (easy with python, will probably use json)
• test more
• clean & comment

optional but would be very nice:

• find a way to pipe 2 processes (lexer and placeholder for parser) such that lexer's output stream is parser's input stream, in parallel if possible (EDIT: i found a way to bring the lexer into the parser and get the next token on demand, looks fine, doesn't require any specific command)
• optimization opportunities (we can always come back to this, for all code we write)

Milestone 4 TODOs

Parser

• For while something(): statements (corresponding to {<something>} in EBNF): we need a way to distinguish between rejection on first token or rejection in the middle, i.e. no match vs. bad syntax. I tried using local_position but it's wrong! This is first priority.
• Program with no main function should be wrong, but now is treated as correct because all tokens are consumed ==> just because end of token stream is reached does not mean the program is correct
• [IGNORE THIS] Handle any number of parameters for functions (now we handle only one).
• Settle on representation of parse tree: nodes, as many as the number of language constructs we have
• Add code to build parse tree: bottom up linking of nodes
• Do we want strings & arrays? Otherwise, no need to handle # token ==> blash!

Static semantics

• Representation of AST as a DS: most likely same as CST
• Very important: sketch out how the AST should look for various program structures <--- high priority
• How to get parse tree from parser to analyzer
• type checking: doesn't have to be perfect, just type checking for assignments would be a good start
• declaration/scope checking
• Understand how a postfix traversal (i think that's what we'll do) helps us get the CST (and other static semantics information)

Generator

• Understand how memory will work: global memory, activation stack, data vs instruction, etc. Right now we're clueless
• Corollary: understand how to deal with global var/const declarations ==> make instructions for that ASAP
• Understand how a postfix traversal will help us convert AST to linear sequence of instructions
• handle all remaining language constructs (assign, arithmetic, subprogram call & return, and maybe other things)

Assembler

• handle new instructions, namely POP, PUSH, CALL

Interpreter

• Handle new constructs with an actual stack: requires thinking about where the function definition begin
• finalize ML first! an initial design doc would be nice

things that have been changing between deliverables

We need to take note of all things that have changed in older material to include that in future deliverable reports. Please add anything you have been fixing/introducing as well!

Between deliverables 1 & 2:

• Fixed interpreter looping logic: from one statement to many statements as the loop body ==> allowed to have a better sample programs (MLcodes 2 & 3)
• Added support for command line arguments and verbose flag in the command (to allow for easier running with an input file of choice)
• removed for (int i; ...)

Between deliverables 2 & 3:

• characters now have single quotes, not double quotes
• comments only start with ~ but don't have to end with it
• debugged assembler a bit (but identified an issue when AL codes have exactly one trailing line return)

Milestone 4: the last 2 days :'(

• change assembly for subprograms (small changes, no big deal at all once we agree on the design)
• design ML (do this by writing expected ML for each of the sample programs)
• assembler (handle new AL structure & CALL, RETURN, POP, PUSH) (though i don't think we'll use PUSH in the AL)
• same for interpreter & literal table (i think we definitely need this)
• interpreter (stack stuff)
• type checking
• declaration checking (i'm super sorry but it's been really hard to get around to these)
• selection AST
• loop AST
• Code generation for selection
• Code generation for loop