Abstract syntax tree

Backlinks

• CAN will use remark to process markdown input
  • Remark provides an interface for producing, modifying and extending a markdown AST using itself and unist tooling. This should allow CAN to get off the ground and stay extensible over development.
• A CAN note is stored using its AST
  • Rather than storing plain-text, a note in CAN will be stored using an abstract, semantic representation (an Abstract Syntax Tree). This allows both input and output to be extended easily to use different formats and also allows robust & simple internal tooling.
• Each CAN address is a directory
  • Inside CAN's notebook there should exist a directory for every address present. The directory will be named the hash of the note which lives at this address (CAN will use SHA3-512 digests). Inside the address there'll be an AST file with the content of the note itself and a metadata file alongside the AST.
• When the SCRATCHFILE_PARSED event is fired CAN should hash the AST
  • CAN should fire a SCRATCHFILE_PARSED event. When this happens, CAN should make a digest of the AST. CAN will use SHA3-512 digests and will use multihash to encode digests. For now no check needs to be performed around which hashing algorithm is used, as there's only one implemented.
• Each CAN address will contain an AST file
  • CAN's notebook has a directory for each address, and each note has its own address. Within this address exists a file with the name ast, containing the AST of the note stored here, represented in JSON.
• CAN should parse the scratchfile when it is updated
  • In order to be able to store notes and use content-addressable storage, CAN needs to have access to the note's content. Because of this, CAN should parse the scratchfile whenever it is updated (CAN should fire a SCRATCHFILE_UPDATED event when the scratchfile is updated). Once the AST has been constructed, CAN should ignore 'beneath the fold'.
• Marked does not provide an AST
  • I misunderstood my reading of marked's docs website and believed that it did have an AST. Previously, I planned for CAN to use marked to process markdown input.
• CAN should fire a SCRATCHFILE_PARSED event when the scratchfile is parsed
  • CAN should parse the scratchfile once it has been updated. Once CAN has successfully parsed the scratchfile, the SCRATCHFILE_PARSED event should be fired, with the AST included as an argument. To allow other parts of the software to respond.
• CAN will use marked to process markdown input
  • Marked provides CAN with the flexibility to use its AST in early development while exposing a stand-alone lexer if the parser needs replacing in the future (marked provides a lexer, parser, and renderer for markdown).
• CAN should fully stringify the AST before creating a digest
  • When addressing a note, CAN should make sure that the AST has been stringified in full to avoid lost information.
• CAN should normalise the AST before it is hashed
  • CAN should store and address notes semantically, which means notes with two different structures but the same meaningful content should have the same AST. And the same address.
• CAN's create-note handler should listen for COMMAND_ADD
  • When the COMMAND_ADD event is detected, the create-note handler should take the current scratchfile's AST and store it at the address calculated for that AST earlier within the CAN notebook.