• Home
  • Raw
  • Download

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.
53 subclass which we use for numeric literals. The important thing to note
58 Right now we only create the AST, so there are no useful accessor
61 definitions that we'll use in the basic form of the Kaleidoscope
104 For our basic language, these are all of the expression nodes we'll
106 Turing-complete; we'll fix that in a later installment. The two things
107 we need next are a way to talk about the interface to a function, and a
141 With this scaffolding, we can now talk about parsing expressions and
147 Now that we have an AST to build, we need to define the parser code to
148 build it. The idea here is that we want to parse something like "x+y"
159 In order to do this, we'll start by defining some basic helper routines:
195 With these basic helper functions, we can implement the first piece of
202 process. For each production in our grammar, we'll define a function
203 which parses that production. For numeric literals, we have:
244 1) It shows how we use the Error routines. When called, this function
249 they happened: in our parser, we return null on an error.
252 by calling ``ParseExpression`` (we will soon see that
256 of AST nodes themselves. While we could do it this way, the most
311 Now that we have all of our simple expression-parsing logic in place, we
316 primary expression, we need to determine what sort of expression it is:
338 we can assume the state of CurTok in the various functions. This uses
342 Now that basic expressions are handled, we need to handle binary
351 definitions from mathematics, we expect the later parse, because "\*"
358 recursion. To start with, we need a table of precedences:
387 For the basic form of Kaleidoscope, we will only support 4 binary
396 With the helper above defined, we can now start parsing binary
449 // consume it, otherwise we are done.
454 if is too low. Because we defined invalid tokens to have a precedence of
456 stream runs out of binary operators. If this check succeeds, we know
462 // Okay, we know this is a binop.
475 Now that we parsed the left-hand side of an expression and one pair of
476 the RHS sequence, we have to decide which way the expression associates.
477 In particular, we could have "(a+b) binop unparsed" or "a + (b binop
478 unparsed)". To determine this, we look ahead at "binop" to determine its
490 to the precedence of our current operator, then we know that the
492 operator is "+" and the next operator is "+", we know that they have the
493 same precedence. In this case we'll create the AST node for "a+b", and
537 At this point, we know that the binary operator to the RHS of our
538 primary has higher precedence than the binop we are currently parsing.
539 As such, we know that any sequence of pairs whose operators are all
541 "RHS". To do this, we recursively invoke the ``ParseBinOpRHS`` function
549 non-trivial lines), we correctly handle fully general binary expression
554 This wraps up handling of expressions. At this point, we can point the
557 we need to handle function definitions, etc.
611 In addition, we support 'extern' to declare functions like 'sin' and
623 Finally, we'll also let the user type in arbitrary top-level expressions
639 Now that we have all the pieces, let's build a little driver that will
640 let us actually *execute* this code we've built!
675 The most interesting part of this is that we ignore top-level
688 non-blank code), we fully defined our minimal language, including a
711 installment <LangImpl3.html>`_, we will describe how to generate LLVM