Lines Matching refs:we

15 language. Once we have a parser, we'll define and build an `Abstract
18 The parser we will build uses a combination of `Recursive Descent
23 the former for everything else). Before we get to parsing though, lets
33 Kaleidoscope, we have expressions, a prototype, and a function object.
52 subclass which we use for numeric literals. The important thing to note
57 Right now we only create the AST, so there are no useful accessor
60 definitions that we'll use in the basic form of the Kaleidoscope
98 For our basic language, these are all of the expression nodes we'll
100 Turing-complete; we'll fix that in a later installment. The two things
101 we need next are a way to talk about the interface to a function, and a
132 With this scaffolding, we can now talk about parsing expressions and
138 Now that we have an AST to build, we need to define the parser code to
139 build it. The idea here is that we want to parse something like "x+y"
149 In order to do this, we'll start by defining some basic helper routines:
180 With these basic helper functions, we can implement the first piece of
187 process. For each production in our grammar, we'll define a function
188 which parses that production. For numeric literals, we have:
228 1) It shows how we use the Error routines. When called, this function
233 they happened: in our parser, we return null on an error.
236 by calling ``ParseExpression`` (we will soon see that
240 of AST nodes themselves. While we could do it this way, the most
293 Now that we have all of our simple expression-parsing logic in place, we
298 primary expression, we need to determine what sort of expression it is:
316 we can assume the state of CurTok in the various functions. This uses
320 Now that basic expressions are handled, we need to handle binary
329 definitions from mathematics, we expect the later parse, because "\*"
336 recursion. To start with, we need a table of precedences:
365 For the basic form of Kaleidoscope, we will only support 4 binary
374 With the helper above defined, we can now start parsing binary
425         // consume it, otherwise we are done.
430 if is too low. Because we defined invalid tokens to have a precedence of
432 stream runs out of binary operators. If this check succeeds, we know
438         // Okay, we know this is a binop.
450 Now that we parsed the left-hand side of an expression and one pair of
451 the RHS sequence, we have to decide which way the expression associates.
452 In particular, we could have "(a+b) binop unparsed" or "a + (b binop
453 unparsed)". To determine this, we look ahead at "binop" to determine its
465 to the precedence of our current operator, then we know that the
467 operator is "+" and the next operator is "+", we know that they have the
468 same precedence. In this case we'll create the AST node for "a+b", and
509 At this point, we know that the binary operator to the RHS of our
510 primary has higher precedence than the binop we are currently parsing.
511 As such, we know that any sequence of pairs whose operators are all
513 "RHS". To do this, we recursively invoke the ``ParseBinOpRHS`` function
521 non-trivial lines), we correctly handle fully general binary expression
526 This wraps up handling of expressions. At this point, we can point the
529 we need to handle function definitions, etc.
583 In addition, we support 'extern' to declare functions like 'sin' and
595 Finally, we'll also let the user type in arbitrary top-level expressions
611 Now that we have all the pieces, let's build a little driver that will
612 let us actually *execute* this code we've built!
638 The most interesting part of this is that we ignore top-level
651 non-blank code), we fully defined our minimal language, including a
674 installment <LangImpl3.html>`_, we will describe how to generate LLVM