# Discussion
Discussion of external and internal api.

Clearly describe the program's four APIs and justify your reasoning for the design of each:

overall flow: view sets up the stage, event handles etc. viewcalls controller on user action. Controller uses backend external, backend external call the model/tell model what to do internally. model executes and directly communicates with frontend external(functional interfaces). view does appropriate action with this information(eg drawing the lines and movuing turtle)

External: between the two separate sub-groups (users of the services) all external methods need to be public.
("public" packages that are expected to be imported and contain primarily interfaces or abstract classes,)

How you plan to separate the graphical interface from the interpreter and how you plan to let them communicate when necessary

- We plan to seperate the graphical interface from the interpreter by having controller.
- So controller will be the middle man between the UI(frontend external) and the model(backend external). Sending UI events to the model

## Frontend external
- Event handler for when model updates

class Model {
    public void setOnUpdateTurtle(UpdateTurtle callback);
    public void setOnUpdateVariable(UpdateVariable callback);
    // ...
}

class View {
    public View() {
        model.setOnUpdateTurtle( (e) -> {
            // update view stuff here
        });
        
        model.setOnUpdateVaraible( (e) -> {
            // update view stuff here
        });
    }
}


@FunctionalInterface
interface UpdateTurtle {
    public void execute(TurtleInfo e);
}

@FunctionalInterface
interface UpdateCommand {
    public void execute(UpdateEvent e);
}

@FunctionalInterface
interface UpdateFunction {
    public void execute(UpdateEvent e);
}

The function passed to the setOnUpdate method is an API for updating the turtle, the variable/function table etc.

## Frontend internal

create everything to do with view. on button

## Backend external

- receive command string
- send results (tutle position and orientation, variable/function table) to view (through controller?) once commands are executed

(methods that the controller calls from the model)
-eg controller is passed a string controller then calls model.execute(etc)

## Backend internal

- parser passes parsed abstract syntax tree (AST) to command executioner
- update information about turtle

What objects will be used for communication, making it clear
- how needed information will get where it is needed
- what information will be immutable
- what data will be encapsulated
- what errors may be thrown
- error parsing for incorrect variable names.(print which character caused error-Jiyang proposes)
- comment in between tokens not supported.
-

Internal: between each sub-group and its future programmers (maintainers of the services)
How you plan to provide paths for extension through abstractions for new features you might reasonably expect to be added to the program such that, as much as possible, the External API is not impacted
What subclasses or implementing classes will be used to extend each part to add new features, making it clear:
what parts of your code you expect to be closed to modification
what freedom future coders will have in choosing how to implement new features
what kind of code someone will be expected to write to implement new features
what errors may be thrown
Note, while some of these methods may be public, many may be protected or package friendly

Front End:
- Text Box to enter commands
- Turtle starts at center (track as 0,0 on the backend)
- Send Errors to the GUI(meaningful translation of error not just text)
- choose background color
- Turtle image LOGOOO. User can choose turtle image.
- Set color for turtle path
- See commands previously run (maybe a box alongside the display screen)
- See variables in environment (how specific should it be)?
- **User-defined commands (functions?)**
- Created with TO.(User creates a function essentially)
- has to be displayed along with variables.
- Translate commands
- Controller has to translate commands
- Help for commands. (Command interface)
- Probably in the same language user picked
- Each command already enforces a specific structure (so find a way to
- display to the user)
- can be a clickable reference page/or integrated into the gui

Back End
- NON CASESENSITIVE (.toLowerCase)
- Throw errors for bad variables
- Any number of lines (remove line breaks)
(When see one token wait for another to stop)
.split()
- Note multple command names (FD, FORWARD)
- Return double of last command executed
- Parameters can be anything defined in the backend table.
- Order of operations is left to right
- once we parse a token, we know how many parameters it takes so we dont need parenthesis/opereator precedence.
- So if you see the parameter of a token is a variable/number, just use it.
- if it is another token, call that token(recursive calling) and the result of that token is the parameter
- Define Variables
- Ignore comments # (line must start with comment)
- forward 50 # Move forward should thrown an error
- Parser sends off complete statements to be executed (TREE)
- Command classes/