{"id":68,"date":"2015-06-05T09:46:14","date_gmt":"2015-06-05T14:46:14","guid":{"rendered":"http:\/\/www.playwithlua.com\/?p=68"},"modified":"2015-06-05T09:46:14","modified_gmt":"2015-06-05T14:46:14","slug":"making-a-toy-programming-language-in-lua-part-2","status":"publish","type":"post","link":"http:\/\/www.playwithlua.com\/?p=68","title":{"rendered":"Making a toy programming language in Lua, part 2"},"content":{"rendered":"

This is part two of my series on writing a toy programming language using LPeg<\/a>. You should first read part one here<\/a>.<\/p>\n

Last time, we made an interpreter for a simple calculator: it would read in mathematical expressions and evaluate them, printing the result. This time, we’re going to add two new features: variables and arrays. First though, we’ll refactor our parser some.
\n<\/p>\n

Cleaning up the parser<\/h2>\n

Here’s the grammar we ended up with last time:<\/p>\n\n

spc =<\/span> lpeg.<\/span>S(<\/span>" \\t<\/span>\\n<\/span>"<\/span>)<\/span>^<\/span>0<\/span>\n \nnumber =<\/span> spc *<\/span> lpeg.<\/span>C(<\/span>\n           lpeg.<\/span>P(<\/span>'-'<\/span>)<\/span>^-<\/span>1<\/span> *<\/span>\n           lpeg.<\/span>R(<\/span>'09'<\/span>)<\/span>^<\/span>0<\/span> *<\/span>\n           (<\/span> lpeg.<\/span>P(<\/span>'.'<\/span>)<\/span> *<\/span>\n             lpeg.<\/span>R(<\/span>'09'<\/span>)<\/span>^<\/span>0<\/span>\n           )<\/span>^-<\/span>1<\/span> )<\/span> *<\/span> spc \/<\/span>\n         tonumber<\/span>\n \nexpr =<\/span> lpeg.<\/span>P{<\/span>\n    "EXPR"<\/span>;<\/span>\n    EXPR =<\/span> (<\/span> lpeg.<\/span>V(<\/span>"TERM"<\/span>)<\/span> *<\/span> lpeg.<\/span>C(<\/span> lpeg.<\/span>S(<\/span>'+-'<\/span>)<\/span> )<\/span> *<\/span> lpeg.<\/span>V(<\/span>"EXPR"<\/span>)<\/span> +<\/span>\n                 lpeg.<\/span>V(<\/span>"TERM"<\/span>)<\/span> )<\/span> \/<\/span> eval,<\/span>\n    TERM =<\/span> (<\/span> lpeg.<\/span>V(<\/span>"FACT"<\/span>)<\/span> *<\/span> lpeg.<\/span>C(<\/span> lpeg.<\/span>S(<\/span>'\/*'<\/span>)<\/span> )<\/span> *<\/span> lpeg.<\/span>V(<\/span>"TERM"<\/span>)<\/span> +<\/span>\n                 lpeg.<\/span>V(<\/span>"FACT"<\/span>)<\/span> )<\/span> \/<\/span> eval,<\/span>\n    FACT =<\/span> (<\/span> spc *<\/span> "("<\/span> *<\/span> lpeg.<\/span>V(<\/span>"EXPR"<\/span>)<\/span> *<\/span> ")"<\/span> *<\/span> spc +<\/span>\n                 number )<\/span> \/<\/span> eval\n}<\/span><\/pre><\/div><\/div><\/div>\n\n
The first annoying thing here is that “lpeg” is repeated everywhere. If we add the lpeg<\/code> table to our environment, we won’t have to do that:<\/p>\n\n
setmetatable<\/span>(<\/span>_ENV,<\/span> {<\/span> __index=<\/span>lpeg }<\/span>)<\/span><\/pre><\/div><\/div><\/div>\n\n
Next is whitespace being matched everywhere. Let’s try to remove a few of those: we’ll say that most patterns can be followed<\/em> by spc<\/code> but that whitespace before them should be matched by whatever token preceded them (in most cases). We’ll also factor out a few helper patterns like digit<\/code>.<\/p>\n
Finally, let’s change where we call eval<\/code>. Right now each nonterminal is sent to eval<\/code>, instead let’s specify that each production<\/em> of a nonterminal will be sent there. That will make it easier to call different functions for different productions later: if we want to send EXPRs that are just one term to a different function than EXPRs that recurse, say.<\/p>\n
With all those changes, the new grammar looks like this:<\/p>\n\n
spc =<\/span> S(<\/span>" \\t<\/span>\\n<\/span>"<\/span>)<\/span>^<\/span>0<\/span>\n \ndigit =<\/span> R(<\/span>'09'<\/span>)<\/span>\nnumber =<\/span> C(<\/span> P(<\/span>'-'<\/span>)<\/span>^-<\/span>1<\/span> *<\/span>\n                digit^<\/span>0<\/span> *<\/span>\n                (<\/span> P(<\/span>'.'<\/span>)<\/span> *<\/span> digit^<\/span>0<\/span> )<\/span>^-<\/span>1<\/span> )<\/span> \/<\/span> tonumber<\/span> *<\/span> spc\n \nlparen =<\/span> "("<\/span> *<\/span> spc\nrparen =<\/span> ")"<\/span> *<\/span> spc\nexpr_op =<\/span> C(<\/span> S(<\/span>'+-'<\/span>)<\/span> )<\/span> *<\/span> spc\nterm_op =<\/span> C(<\/span> S(<\/span>'*\/'<\/span>)<\/span> )<\/span> *<\/span> spc\n \nexpr =<\/span> spc *<\/span> P{<\/span>\n    "EXPR"<\/span>;<\/span>\n    EXPR =<\/span>\n        V(<\/span>"TERM"<\/span>)<\/span> *<\/span> expr_op *<\/span> V(<\/span>"EXPR"<\/span>)<\/span> \/<\/span> eval +<\/span>\n        V(<\/span>"TERM"<\/span>)<\/span> \/<\/span> eval,<\/span>\n    TERM =<\/span>\n        V(<\/span>"FACT"<\/span>)<\/span> *<\/span> term_op *<\/span> V(<\/span>"TERM"<\/span>)<\/span> \/<\/span> eval +<\/span>\n        V(<\/span>"FACT"<\/span>)<\/span> \/<\/span> eval,<\/span>\n    FACT =<\/span>\n        lparen *<\/span> V(<\/span>"EXPR"<\/span>)<\/span> *<\/span> rparen \/<\/span> eval +<\/span>\n        number \/<\/span> eval\n}<\/span><\/pre><\/div><\/div><\/div>\n\n
With all these changes it’s easy to accidentally break one part of the parser while fixing another, so we’ll also write a quick function to ensure we didn’t create a regression:<\/p>\n\n
function<\/span> test(<\/span>expr)<\/span>\n    assert<\/span>(<\/span>expr:<\/span>match(<\/span>" 1 + 2 "<\/span>)<\/span> ==<\/span> 3<\/span>)<\/span>\n    assert<\/span>(<\/span>expr:<\/span>match(<\/span>"1+2+3+4+5"<\/span>)<\/span> ==<\/span> 15<\/span>)<\/span>\n    assert<\/span>(<\/span>expr:<\/span>match(<\/span>"2*3*4 + 5*6*7"<\/span>)<\/span> ==<\/span> 234<\/span>)<\/span>\n    assert<\/span>(<\/span>expr:<\/span>match(<\/span>" 1 * 2 + 3"<\/span>)<\/span> ==<\/span> 5<\/span>)<\/span>\n    assert<\/span>(<\/span>expr:<\/span>match(<\/span>"( 2 +2) *6"<\/span>)<\/span> ==<\/span> 24<\/span>)<\/span>\nend<\/span><\/pre><\/div><\/div><\/div>\n\n
Eliminating recursion<\/h2>\n
Finally, we can now make the parser even simpler by eliminating some of the recursive rules. Instead of saying an EXPR is a TERM followed by an EXPR, let’s say an EXPR is a list of repeated TERMs:<\/p>\n\n
expr =<\/span> spc *<\/span> P{<\/span>\n    "EXPR"<\/span>;<\/span>\n    EXPR =<\/span> V(<\/span>"TERM"<\/span>)<\/span> *<\/span> (<\/span> expr_op *<\/span> V(<\/span>"TERM"<\/span>)<\/span> )<\/span>^<\/span>0<\/span> \/<\/span> eval,<\/span>\n    TERM =<\/span> V(<\/span>"FACT"<\/span>)<\/span> *<\/span> (<\/span> term_op *<\/span> V(<\/span>"FACT"<\/span>)<\/span> )<\/span>^<\/span>0<\/span> \/<\/span> eval,<\/span>\n    FACT =<\/span>\n        lparen *<\/span> V(<\/span>"EXPR"<\/span>)<\/span> *<\/span> rparen \/<\/span> eval +<\/span>\n        number \/<\/span> eval\n}<\/span><\/pre><\/div><\/div><\/div>\n\n
This will also require some changes in eval<\/code>, since it’s going to get a variable-length argument list, instead of rolling up the expression one operation at a time. Instead of eval(2, '+', eval(4, '+', 3))<\/code>, we’re now effectively calling eval(2, '+', 4, '+', 3)<\/code>. So, here’s the new eval<\/code>:<\/p>\n\n
function<\/span> eval(<\/span>...<\/span>)<\/span>\n    local<\/span> args =<\/span> {<\/span>...<\/span>}<\/span>\n    local<\/span> accum =<\/span> args[<\/span>1<\/span>]<\/span>\n    for<\/span> i =<\/span> 2<\/span>,<\/span> #<\/span>args,<\/span> 2<\/span> do<\/span>\n        local<\/span> operator =<\/span> args[<\/span>i]<\/span>\n        local<\/span> num2 =<\/span> args[<\/span>i+<\/span>1<\/span>]<\/span>\n \n        if<\/span> operator ==<\/span> '+'<\/span> then<\/span>\n            accum =<\/span> accum +<\/span> num2\n        elseif<\/span> operator ==<\/span> '-'<\/span> then<\/span>\n            accum =<\/span> accum -<\/span> num2\n        elseif<\/span> operator ==<\/span> '*'<\/span> then<\/span>\n            accum =<\/span> accum *<\/span> num2\n        elseif<\/span> operator ==<\/span> '\/'<\/span> then<\/span>\n            accum =<\/span> accum \/<\/span> num2\n        end<\/span>\n    end<\/span>\n    return<\/span> accum\nend<\/span><\/pre><\/div><\/div><\/div>\n\n
Now we have a much nicer and cleaner-looking grammar.<\/p>\n
Variables<\/h2>\n
So let’s add in variables. Here’s what we’d like to be able to do: we should first of all be able to assign values to variables with =<\/code>:<\/p>\n
a = 5\r\n\r\n<\/pre>\n
Next, we’d like to be able to use variables in expressions:<\/p>\n
b = (a+3) \/ 2\r\n\r\n<\/pre>\n
So to start off with, let’s think about how this will affect the grammar. The most obvious thing is that we’ll need a way to match a variable name:<\/p>\n\n
letter =<\/span> R(<\/span>'AZ'<\/span>,<\/span>'az'<\/span>)<\/span>\nname =<\/span> C(<\/span> letter *<\/span> (<\/span>digit+<\/span>letter+<\/span>"_"<\/span>)<\/span>^<\/span>0<\/span> )<\/span> *<\/span> spc<\/pre><\/div><\/div><\/div>\n\n
This makes variables be some sequence of letters, digits, and underscores, that starts with a letter.<\/p>\n
Next is, right now, we’re matching EXPRs only; we’ll need a new type of statement that can be either an assignment or an EXPR. Let’s call it a STMT:<\/p>\n\n
stmt =<\/span> spc *<\/span> P{<\/span>\n    "STMT"<\/span>;<\/span>\n    STMT =<\/span>\n        name *<\/span> "="<\/span> *<\/span> spc *<\/span> V(<\/span>"EXPR"<\/span>)<\/span> \/<\/span> assign +<\/span>\n        V(<\/span>"EXPR"<\/span>)<\/span>,<\/span>\n    EXPR =<\/span> V(<\/span>"TERM"<\/span>)<\/span> *<\/span> (<\/span> expr_op *<\/span> V(<\/span>"TERM"<\/span>)<\/span> )<\/span>^<\/span>0<\/span> \/<\/span> eval,<\/span>\n    TERM =<\/span> V(<\/span>"FACT"<\/span>)<\/span> *<\/span> (<\/span> term_op *<\/span> V(<\/span>"FACT"<\/span>)<\/span> )<\/span>^<\/span>0<\/span> \/<\/span> eval,<\/span>\n    FACT =<\/span>\n        lparen *<\/span> V(<\/span>"EXPR"<\/span>)<\/span> *<\/span> rparen \/<\/span> eval +<\/span>\n        number \/<\/span> eval\n}<\/span><\/pre><\/div><\/div><\/div>\n\n
STMT is now the first thing we match, and STMTs can’t be part of EXPRs (though EXPRs are part of STMTs). Also, we don’t send STMTs to eval<\/code>, we send them to a new function, assign<\/code>:<\/p>\n\n
VARS =<\/span> {<\/span>}<\/span>\nfunction<\/span> assign(<\/span>name,<\/span> value)<\/span>\n    VARS[<\/span>name]<\/span> =<\/span> value\n    return<\/span> value\nend<\/span><\/pre><\/div><\/div><\/div>\n\n
We’re storing all the variables in a VARS<\/code> table. We return the value on the right-hand side of the assign not because we need it for anything, but because if we don’t return something then LPeg will just produce the next string index (just as if we hadn’t captured anything).<\/p>\n
Now we need a way to reference variables. A variable can be used anywhere a number can, so let’s make them another production of FACT:<\/p>\n\n
FACT =<\/span>\n    name \/<\/span> VARS +<\/span>\n    lparen *<\/span> V(<\/span>"EXPR"<\/span>)<\/span> *<\/span> rparen \/<\/span> eval +<\/span>\n    number \/<\/span> eval<\/pre><\/div><\/div><\/div>\n\n
Notice that what we’re passing name<\/code>s to isn’t a function, but our table of variables: looking up names in a table is a common-enough task that LPeg lets you use a table as a capture handler instead of a function.<\/p>\n
Also, the order of these is somewhat tricky: it only works if name<\/code> goes before number<\/code>. This is because number<\/code> will try to match anything: if it starts with a minus sign or a digit it works, otherwise it fails and fails the entire FACT match<\/em> because LPeg does no backtracking. If you want, you can either use number-name<\/code> (“match number as long as name doesn’t match”) in place of number<\/code>, or change number<\/code> to this, to make the order irrelevant:<\/p>\n\n
number =<\/span> C(<\/span> (<\/span>'-'<\/span> +<\/span> digit)<\/span> *<\/span>\n                digit^<\/span>0<\/span> *<\/span>\n                (<\/span> P(<\/span>'.'<\/span>)<\/span> *<\/span> digit^<\/span>0<\/span> )<\/span>^-<\/span>1<\/span> )<\/span> \/<\/span> tonumber<\/span> *<\/span> spc<\/pre><\/div><\/div><\/div>\n\n
In general you should avoid having a pattern begin with an optional element (any element raised to a negative power), to avoid tricky backtracking issues like this.<\/p>\n
New we can add a few lines into our test<\/code> function to make sure variables work:<\/p>\n\n
stmt:<\/span>match(<\/span>"a=3"<\/span>)<\/span>;<\/span> assert<\/span>(<\/span>VARS.<\/span>a ==<\/span> 3<\/span>)<\/span>\nassert<\/span>(<\/span>stmt:<\/span>match(<\/span>"a"<\/span>)<\/span> ==<\/span> 3<\/span>)<\/span>\nassert<\/span>(<\/span>stmt:<\/span>match(<\/span>"a * 5"<\/span>)<\/span> ==<\/span> 15<\/span>)<\/span>;<\/span> VARS.<\/span>a=<\/span>nil<\/span><\/pre><\/div><\/div><\/div>\n\n
Arrays<\/h2>\n
Having single variables is nice, but we should also allow for arrays. Here’s the syntax we’ll use:<\/p>\n
    \n
  • An array can be specified literally with brackets, like “[1, 2, 3]”<\/li>\n
  • Arrays can be subscripted with brackets, like “arr[2]”<\/li>\n
  • Arrays can be nested inside of arrays<\/li>\n<\/ul>\n
    Let’s add some productions to our grammar. An ARRAY looks like this:<\/p>\n\n
    ARRAY =<\/span> lbrack *<\/span> V(<\/span>"VAL_LIST"<\/span>)<\/span>^-<\/span>1<\/span> *<\/span> rbrack,<\/span>\nVAL_LIST =<\/span> V(<\/span>"VAL"<\/span>)<\/span> *<\/span> (<\/span>comma *<\/span> V(<\/span>"VAL"<\/span>)<\/span>)<\/span>^<\/span>0<\/span><\/pre><\/div><\/div><\/div>\n\n
    (lbrack<\/code>, rbrack<\/code>, and comma<\/code> are simple patterns matching one punctuation character followed by spc<\/code>, just like lparen<\/code> and rparen<\/code> were).<\/p>\n
    We’re adding a new nonterminal VAL that represents a value. These can be either EXPRs or an ARRAY:<\/p>\n\n
    VAL =<\/span> V(<\/span>"EXPR"<\/span>)<\/span> +<\/span> V(<\/span>"ARRAY"<\/span>)<\/span><\/pre><\/div><\/div><\/div>\n\n
    And where we had EXPR as the right-hand side of an assignment statement, now it should be VAL:<\/p>\n\n
    STMT =<\/span>\n    name *<\/span> "="<\/span> *<\/span> spc *<\/span> V(<\/span>"VAL"<\/span>)<\/span> \/<\/span> assign +<\/span>\n    V(<\/span>"EXPR"<\/span>)<\/span>,<\/span><\/pre><\/div><\/div><\/div>\n\n
    So, now we can parse things like “a=[1, 2, 3]”. We’ll need to actually capture things though. LPeg has a function, Ct<\/code>, that packs all the captures of a pattern into a table, and treats it as one capture. We can use that on the VAL_LIST instead of bothering to write a function to capture ARRAYs:<\/p>\n\n
    ARRAY =<\/span> lbrack *<\/span> Ct(<\/span> V(<\/span>"VAL_LIST"<\/span>)<\/span>^-<\/span>1<\/span> )<\/span> *<\/span> rbrack<\/pre><\/div><\/div><\/div>\n\n
    Now when we parse an assignment to an array, it will actually assign something, and we can test that:<\/p>\n\n
    stmt:<\/span>match(<\/span>"a = [4, 5, 6]"<\/span>)<\/span>;<\/span>\nassert<\/span>(<\/span>VARS.<\/span>a[<\/span>1<\/span>]<\/span> ==<\/span> 4<\/span>)<\/span>\nassert<\/span>(<\/span>VARS.<\/span>a[<\/span>2<\/span>]<\/span> ==<\/span> 5<\/span>)<\/span>\nassert<\/span>(<\/span>VARS.<\/span>a[<\/span>3<\/span>]<\/span> ==<\/span> 6<\/span>)<\/span>\nVARS.<\/span>a=<\/span>nil<\/span>\nstmt:<\/span>match(<\/span>"b = []"<\/span>)<\/span>;<\/span>\nassert<\/span>(<\/span>VARS.<\/span>b[<\/span>1<\/span>]<\/span> ==<\/span> nil<\/span>)<\/span>\nVARS.<\/span>b=<\/span>nil<\/span><\/pre><\/div><\/div><\/div>\n\n
    As well as, of course, nesting arrays:<\/p>\n\n
    stmt:<\/span>match(<\/span>"c = [[1,2], [3,4]]"<\/span>)<\/span>\nassert<\/span>(<\/span>VARS.<\/span>c[<\/span>1<\/span>]<\/span>[<\/span>1<\/span>]<\/span> ==<\/span> 1<\/span>)<\/span>\nassert<\/span>(<\/span>VARS.<\/span>c[<\/span>1<\/span>]<\/span>[<\/span>2<\/span>]<\/span> ==<\/span> 2<\/span>)<\/span>\nassert<\/span>(<\/span>VARS.<\/span>c[<\/span>2<\/span>]<\/span>[<\/span>1<\/span>]<\/span> ==<\/span> 3<\/span>)<\/span>\nassert<\/span>(<\/span>VARS.<\/span>c[<\/span>2<\/span>]<\/span>[<\/span>2<\/span>]<\/span> ==<\/span> 4<\/span>)<\/span>\nVARS.<\/span>c=<\/span>nil<\/span><\/pre><\/div><\/div><\/div>\n\n
    Array subscripting<\/h2>\n
    Now to work on how to get values out of arrays. Taking a value out of an array is a lot like reading the value of a variable in general. Let’s make a new nonterminal, “REF,” that will hold a reference<\/em> that we can read or write to. A REF will be a variable name followed by a series of subscripts in brackets. FACT will match a REF, and read its value:<\/p>\n\n
    REF =<\/span> name *<\/span> (<\/span>lbrack *<\/span> V(<\/span>"EXPR"<\/span>)<\/span> *<\/span> rbrack)<\/span>^<\/span>0<\/span> \/<\/span> makeref,<\/span>\nFACT =<\/span>\n    number \/<\/span> eval +<\/span>\n    lparen *<\/span> V(<\/span>"EXPR"<\/span>)<\/span> *<\/span> rparen \/<\/span> eval +<\/span>\n    V(<\/span>"REF"<\/span>)<\/span> \/<\/span> lookup,<\/span><\/pre><\/div><\/div><\/div>\n\n
    The functions to make a REF and read its value look like this:<\/p>\n\n
    function<\/span> makeref(<\/span>...<\/span>)<\/span>\n    local<\/span> indices =<\/span> {<\/span>...<\/span>}<\/span>\n    local<\/span> tbl =<\/span> VARS\n \n    for<\/span> i =<\/span> 1<\/span>,<\/span> #<\/span>indices-<\/span>1<\/span> do<\/span>\n        tbl =<\/span> tbl[<\/span>indices[<\/span>i]<\/span>]<\/span>\n    end<\/span>\n \n    return<\/span> {<\/span>scope=<\/span>tbl,<\/span> index=<\/span>indices[<\/span>#<\/span>indices]<\/span>}<\/span>\nend<\/span>\n \nfunction<\/span> lookup(<\/span>ref)<\/span>\n    return<\/span> ref.<\/span>scope[<\/span>ref.<\/span>index]<\/span>\nend<\/span><\/pre><\/div><\/div><\/div>\n\n
    A REF consists of a table with scope<\/code> and index<\/code> keys. The scope<\/em> is the table in which the variable resides (all variables that aren’t array elements reside in VARS<\/code>, so it’s simple enough to start there) and the index is the place in that table where you can find it. When we parse a REF we call makeref<\/code> to create this object, and when we parse a FACT that is<\/em> a REF we call lookup<\/code> to read its current value.<\/p>\n
    This is the first thing our parser has generated that evaluates to an intermediate object, instead of a number. EXPRs, TERMs, and FACTs all get turned into the numbers they evaluate to when we parse them; a REF has no meaning until it’s evaluated by lookup<\/code>. We’re going to expand on this general idea of an intermediate representation a lot in the next post.<\/p>\n
    Anyway, for now, it’s easy to write a test that shows that we can look up array elements:<\/p>\n\n
    assert<\/span>(<\/span>stmt:<\/span>match(<\/span>"c[4\/2][1]"<\/span>)<\/span> ==<\/span> 3<\/span>)<\/span><\/pre><\/div><\/div><\/div>\n\n
    Assigning to arrays<\/h2>\n
    You may be wondering, why not combine makeref<\/code> and lookup<\/code>? Why not have makeref<\/code> go one step further down the chain of indices and return the final value?<\/p>\n
    It’s because we also want to support assignments; REFs as lvalues<\/em>. Lua doesn’t let us take a reference to a number, numbers are always passed by value, so we have to store the table and the index to write to instead. By making one function to create that, we can use it in both FACT (with lookup<\/code>) and in assignments, with what we’re about to write.<\/p>\n
    Let’s change the grammar for STMTs:<\/p>\n\n
    STMT =<\/span>\n    V(<\/span>"REF"<\/span>)<\/span> *<\/span> "="<\/span> *<\/span> spc *<\/span> V(<\/span>"VAL"<\/span>)<\/span> \/<\/span> assign +<\/span>\n    V(<\/span>"EXPR"<\/span>)<\/span><\/pre><\/div><\/div><\/div>\n\n
    Now, change the assign<\/code> function to expect its first parameter to be a REF instead of a name:<\/p>\n\n
    function<\/span> assign(<\/span>ref,<\/span> value)<\/span>\n    ref.<\/span>scope[<\/span>ref.<\/span>index]<\/span> =<\/span> value\n    return<\/span> value\nend<\/span><\/pre><\/div><\/div><\/div>\n\n
    With this one change, now we can assign to elements of arrays:<\/p>\n\n
    stmt:<\/span>match(<\/span>"c[3] = 5"<\/span>)<\/span>\nassert<\/span>(<\/span>VARS.<\/span>c[<\/span>3<\/span>]<\/span> ==<\/span> 5<\/span>)<\/span><\/pre><\/div><\/div><\/div>\n\n
    Next steps<\/h2>\n
    Our little calculator from part 1 now understands variables, arrays, and even nested arrays. It’s starting to become a more complete language. However, we’re still missing a lot of concepts: there are no conditional statements or loops, both of which are needed to make variables and arrays useful (what good is a variable if it can’t affect program flow; what good is an array if you can’t loop over it?). We are also reaching (and edging past) the limits of the evaluate-as-you-parse model. We’ve already seen how it doesn’t work for assignments to arrays.<\/p>\n
    So, next week, we’re going to do a major overhaul of how this language gets run, and then use that new design to implement some features that would be impossible with this one: conditionals and looping.<\/p>\n
    The complete code to this post is available here<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":"
    This is part two of my series on writing a toy programming language using LPeg. You should first read part one here. Last time, we made an interpreter for a simple calculator: it would read in mathematical expressions and evaluate them, printing the result. This time, we’re going to add two new features: variables and […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[1],"tags":[],"_links":{"self":[{"href":"http:\/\/www.playwithlua.com\/index.php?rest_route=\/wp\/v2\/posts\/68"}],"collection":[{"href":"http:\/\/www.playwithlua.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/www.playwithlua.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/www.playwithlua.com\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/www.playwithlua.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=68"}],"version-history":[{"count":0,"href":"http:\/\/www.playwithlua.com\/index.php?rest_route=\/wp\/v2\/posts\/68\/revisions"}],"wp:attachment":[{"href":"http:\/\/www.playwithlua.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=68"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/www.playwithlua.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=68"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/www.playwithlua.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=68"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}