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
110 This just adds lexer support for the unary and binary keywords, like we
112 about our current AST, is that we represent binary operators with full
114 operators, we'll use this same representation, so we don't need any new
117 On the other hand, we have to be able to represent the definitions of
122 as prototypes, we have to extend the ``PrototypeAST`` AST node like
152 Basically, in addition to knowing a name for the prototype, we now keep
156 operators). Now that we have a way to represent the prototype for a
157 user-defined operator, we need to parse it:
216 This is all fairly straightforward parsing code, and we have already
262 The final piece of code we are missing, is a bit of top-level magic:
285 operator, we register it in the precedence table. This allows the binary
286 operator parsing logic we already have in place to handle it. Since we
288 we need to do to "extend the grammar".
290 Now we have useful user-defined binary operators. This builds a lot on
291 the previous framework we built for other operators. Adding unary
292 operators is a bit more challenging, because we don't have any framework
298 Since we don't currently support unary operators in the Kaleidoscope
299 language, we'll need to add everything to support them. Above, we added
301 that, we need an AST node:
317 we need to add the parsing logic. Parsing a unary operator is pretty
318 simple: we'll add a new function to do it:
338 The grammar we add is pretty straightforward here. If we see a unary
339 operator when parsing a primary operator, we eat the operator as a
345 The problem with this function, is that we need to call ParseUnary from
346 somewhere. To do this, we change previous callers of ParsePrimary to
370 With these two simple changes, we are now able to parse unary operators
371 and build the AST for them. Next up, we need to add parser support for
407 As with binary operators, we name unary operators with a name that
409 time. Speaking of, the final piece we need to add is codegen support for
432 It is somewhat hard to believe, but with a few simple extensions we've
433 covered in the last chapters, we have grown a real-ish language. With
434 this, we can do a lot of interesting things, including I/O, math, and a
435 bunch of other things. For example, we can now add a nice sequencing
496 Given the previous if/then/else support, we can also define interesting
522 Based on these simple primitive operations, we can start to define more
549 two-dimensional plane, you can see the Mandelbrot set. Given that we are
551 but we can whip together something using the density plotter above:
570 Given this, we can try plotting out the mandlebrot set! Lets try it out:
709 With this, we conclude the "adding user-defined operators" chapter of
711 ability to extend the language in the library, and we have shown how
720 phase to your front-end. In the next chapter, we will describe how you