1.1 --- /dev/null Thu Jan 01 00:00:00 1970 +0000
1.2 +++ b/docs/wiki/Roadmap Sun Apr 26 22:59:15 2020 +0200
1.3 @@ -0,0 +1,50 @@
1.4 += Roadmap =
1.5 +
1.6 +There are plenty of potential improvements that could be made to the software.
1.7 +These could potentially constitute a roadmap of sorts.
1.8 +
1.9 +== Better Error Handling ==
1.10 +
1.11 +Errors are not very informative and could be reported and handled better.
1.12 +
1.13 +== Better Input Validation ==
1.14 +
1.15 +The code generally assumes that some forms of input will make sense in the
1.16 +output. Moreover, some characteristics of the output might result in deficient
1.17 +program behaviour. For instance, where the opcodes of individual interfaces
1.18 +combined into a compound interface conflict, the resulting code will not be
1.19 +able to deliver messages to all of the conflicting operations, and the tool
1.20 +should really be detecting such conditions.
1.21 +
1.22 +== Tidier Code Generation ==
1.23 +
1.24 +Having written the software in C, very basic techniques have been used to
1.25 +generate code, and these have also had some impact on the output itself.
1.26 +Ideally, more sophisticated templating would be used to make the workings of
1.27 +the code generation more obvious.
1.28 +
1.29 +== Reimplementation in Another Language ==
1.30 +
1.31 +It might be interesting to reimplement the tool in Python and to use a similar
1.32 +parsing toolkit. [[http://www.dabeaz.com/ply/|PLY]] would be a potentially
1.33 +usable candidate.
1.34 +
1.35 +== More Integrated Compound Interfaces ==
1.36 +
1.37 +Having compound interfaces supported at the command level helps to avoid
1.38 +difficult issues introduced by supporting them at the language level, but it
1.39 +would arguably be more elegant to support them using a form of interface
1.40 +inheritance, even though this introduces some awkward issues of its own.
1.41 +
1.42 +== Consolidation of Output Files ==
1.43 +
1.44 +Currently, the `_interface.h`, `_interfaces.h` and `_interface_type.h` files
1.45 +generated for compound interfaces are all created because individual
1.46 +interface details are written incrementally to different output constructs,
1.47 +and such constructs are most easily maintained using distinct output streams.
1.48 +However, the details of the individual interfaces are readily available from
1.49 +the processed command options.
1.50 +
1.51 +Thus, interface type information (`_interface.h` and `_interface_type.h`)
1.52 +could be written out completely without involving the individual interface
1.53 +code generation in the production of these files.