33 lines
1.6 KiB
Plaintext
33 lines
1.6 KiB
Plaintext
Implement special-purpose Markdown processor. This way it can be intelligent
|
|
about connecting seperated doc-blocks that should be a unit, can process thing
|
|
like link references on a whole-document basis, and can be more intelligent
|
|
about indentation, line numbers for doc blocks.
|
|
|
|
Consider building up common, generic AST nodes for code parsers so that most of
|
|
the work of integrating a new language is already done in the common code,
|
|
leaving only the very specific behavior to be implemented. For starters:
|
|
|
|
CodeUnit
|
|
: Supports things like classes in OOP, modules, even files if that is a
|
|
common organizational unit for the language.
|
|
|
|
Callable
|
|
: Supports methods, functions, subroutines, closures, anything that takes
|
|
parameters and returns a value.
|
|
|
|
Structure
|
|
: May be a useful abstraction for pure data objects (Erlang record
|
|
definitions, C/C++ unions and structs, enums, etc.).
|
|
|
|
Make Directives completely configurable. Do not hard-code an enumeration of
|
|
possible values. Make the actual directive text just another field on the class.
|
|
This allows language-specific implementations to extend the built-in Directives
|
|
easily. It also has the benefit of allowing unknown or invalid directives
|
|
through the parser without causing the source file to fail to parse. This gives
|
|
us a better way to warn the user of unknown directives. To this end it may be
|
|
good to assemble a list of defined directives at runtime, but this would not
|
|
happen in the parser itself.
|
|
|
|
Add back the @doc directive to return to private implementation notes within a
|
|
block that has so far been marked public with an @api directive.
|