Lines Matching refs:we

12 LLVM <index.html>`_" tutorial. At this point in our tutorial, we now
23 is good or bad. In this tutorial we'll assume that it is okay to use
26 At the end of this tutorial, we'll run through an example Kaleidoscope
33 The "operator overloading" that we will add to Kaleidoscope is more
37 chapter, we will add this capability to Kaleidoscope, which will let the
42 Thus far, the parser we have been implementing uses recursive descent
49 The two specific features we'll add are programmable unary operators
80 library in the language itself. In Kaleidoscope, we can implement
115 This just adds lexer support for the unary and binary keywords, like we
117 about our current AST, is that we represent binary operators with full
119 operators, we'll use this same representation, so we don't need any new
122 On the other hand, we have to be able to represent the definitions of
127 as prototypes, we have to extend the ``PrototypeAST`` AST node like
159 Basically, in addition to knowing a name for the prototype, we now keep
163 operators). Now that we have a way to represent the prototype for a
164 user-defined operator, we need to parse it:
224 This is all fairly straightforward parsing code, and we have already
275 The final piece of code we are missing, is a bit of top-level magic:
298 operator, we register it in the precedence table. This allows the binary
299 operator parsing logic we already have in place to handle it. Since we
301 we need to do to "extend the grammar".
303 Now we have useful user-defined binary operators. This builds a lot on
304 the previous framework we built for other operators. Adding unary
305 operators is a bit more challenging, because we don't have any framework
311 Since we don't currently support unary operators in the Kaleidoscope
312 language, we'll need to add everything to support them. Above, we added
314 that, we need an AST node:
331 we need to add the parsing logic. Parsing a unary operator is pretty
332 simple: we'll add a new function to do it:
352 The grammar we add is pretty straightforward here. If we see a unary
353 operator when parsing a primary operator, we eat the operator as a
359 The problem with this function, is that we need to call ParseUnary from
360 somewhere. To do this, we change previous callers of ParsePrimary to
387 With these two simple changes, we are now able to parse unary operators
388 and build the AST for them. Next up, we need to add parser support for
424 As with binary operators, we name unary operators with a name that
426 time. Speaking of, the final piece we need to add is codegen support for
450 It is somewhat hard to believe, but with a few simple extensions we've
451 covered in the last chapters, we have grown a real-ish language. With
452 this, we can do a lot of interesting things, including I/O, math, and a
453 bunch of other things. For example, we can now add a nice sequencing
514 Given the previous if/then/else support, we can also define interesting
540 Based on these simple primitive operations, we can start to define more
567 two-dimensional plane, you can see the Mandelbrot set. Given that we are
569 but we can whip together something using the density plotter above:
588 Given this, we can try plotting out the mandelbrot set! Lets try it out:
727 With this, we conclude the "adding user-defined operators" chapter of
729 ability to extend the language in the library, and we have shown how
738 phase to your front-end. In the next chapter, we will describe how you