Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New Parser #42

Open
Toyz opened this issue Nov 10, 2018 · 4 comments
Open

New Parser #42

Toyz opened this issue Nov 10, 2018 · 4 comments

Comments

@Toyz
Copy link
Contributor

Toyz commented Nov 10, 2018

The new Parser has a flaw in it's design as turtle graphics support float values and we cannot actually handle those currently...

Also the new way to add commands can be clunky at times and yield some issues with newer people wanting to contribute as there's no comments to what things are

@Toyz Toyz mentioned this issue Nov 10, 2018
@EyLuismi
Copy link
Contributor

EyLuismi commented Nov 10, 2018

Also the new way to add commands can be clunky at times and yield some issues with newer people wanting to contribute as there's no comments to what things are

Yeah, I was thinking the same, what are your thoughts? First, I think maybe moving the commands definitions to another file would be a good Idea, and then in the readme I would explain with examples how you could add a new command arg type, or a command itself.

Also, of course, more description in the code never hurts. I can prepare a PR about this.

@EyLuismi
Copy link
Contributor

@Toyz In order to close this Issue, do you think that we would need to insert in the readme or myabe in some contribution guide, how to insert a new command? I mean, descriptions do help, but I think we could make a straightforward tutorial.

Also now there is something about validators and expressions I want to dig in :P

@Toyz
Copy link
Contributor Author

Toyz commented Nov 14, 2018

We probably show insert into the contributions file regrading it

@rhdunn
Copy link

rhdunn commented Nov 15, 2018

I was thinking of using something like the original part 1 implementation. My rationale for this is that logo is a relatively simple language that requires tokens to be space separated.

Lexer

  1. Split on spaces
  2. If the text is a number parse it to a number object -- this can support float values
  3. Anything else (including "[" and "]") is a string object, and is thus a keyword

There is nothing more complex in terms of tokens in logo.

Parser

  1. Parse the tokens into a command array.
  2. Parse "[" ... "]" into a command array -- so the repeat command will take a command array as an argument.
  3. Each command is an object with a name and arguments (number tokens or a command array ("[" ... "]")), so parsing a command stops at a command name token.
  4. Return the top-level command array as a repeat 1 [ commands ] command.

Interpreter

  1. A commands object where the keys are the command name, and the value is a function taking the argument array.
  2. An interpret helper function for looking up the command and calling it with the given arguments for each command in a command array.

Thus, repeat could be implemented like:

"repeat": function (arguments) {
    let n = arguments[0];
    while (n > 0) {
        interpret(arguments[1]);
        --n;
    }
},

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants