Skip to content

Revised SyntacticHeap Specification #109

@DavePearce

Description

@DavePearce

RFC#0014 defined the initial format for syntactic heaps. However, I'm starting to wonder whether a revised specification might be beneficial. Some points:

  • (Operands). To make the format more efficient, operands can be organised following a stack-based model. This means we would not need to explicitly denote operands in the binary file, rather they are implied by the stack.
  • (Interning). It makes sense for certain datatypes to be provided "as is" and which the system automatically interns (i.e. ensure uniqueness of). For example, interning strings representing the same variable name makes obvious sense. Somehow this is being manually managed in various places (e.g. AbstractSyntacticHeap).
  • (MetaData). The specification could provide more concrete details around common forms of meta-data. For example, mapping from tree nodes to spans in the original source file. Likewise, caching references from names to their declarations. Finally, representing warning / error markers.
  • (Equality). The current implementation suffers quite badly due to problems around the meaning of node equality. Its actually pretty broken in various ways (e.g. equality of nodes in different heaps, or equality of recursive nodes, etc). Clarifying this would be helpful.
  • (Schema). Potentially, it might be useful to say something about the notion of schemas for heaps, and perhaps about versioning. What do we need from a schema? Can we embed schemas?
  • (Delta). Perhaps a long shot, but thinking about deltas might be helpful for future work in incrementalisation.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions