| Renato Golin | 1625937 | 2014-03-20 16:08:34 +0000 | [diff] [blame] | 1 | ===================== |
| 2 | TableGen Deficiencies |
| 3 | ===================== |
| 4 | |
| 5 | .. contents:: |
| 6 | :local: |
| 7 | |
| 8 | Introduction |
| 9 | ============ |
| 10 | |
| 11 | Despite being very generic, TableGen has some deficiencies that have been |
| 12 | pointed out numerous times. The common theme is that, while TableGen allows |
| 13 | you to build Domain-Specific-Languages, the final languages that you create |
| 14 | lack the power of other DSLs, which in turn increase considerably the size |
| 15 | and complexity of TableGen files. |
| 16 | |
| 17 | At the same time, TableGen allows you to create virtually any meaning of |
| 18 | the basic concepts via custom-made back-ends, which can pervert the original |
| 19 | design and make it very hard for newcomers to understand it. |
| 20 | |
| 21 | There are some in favour of extending the semantics even more, but making sure |
| 22 | back-ends adhere to strict rules. Others suggesting we should move to more |
| 23 | powerful DSLs designed with specific purposes, or even re-using existing |
| 24 | DSLs. |
| 25 | |
| 26 | Known Problems |
| 27 | ============== |
| 28 | |
| 29 | TODO: Add here frequently asked questions about why TableGen doesn't do |
| 30 | what you want, how it might, and how we could extend/restrict it to |
| 31 | be more use friendly. |