Skip to content
Pannous edited this page Nov 19, 2022 · 1 revision

The unified wasp code / data model can represent a wide variety of data layouts. Different kinds of nodes are reflected via different types.

However since attributes, methods and fields are unified, and comments are not part of the analysis step, extra information such as annotations can at times be stored in the meta field of a node. This is usually only needed if very specific data layout considerations are required, e.g. if an xml file is to be represented not just semantically but verbatim.

The meta field should give the node graph the power to naturally represent almost all kind of data, including cyclic labled graphs via wasp references.

Since the meta field is a node itself, it can store arbitrary data including maps.

Tools using the meta field should assume/enforce it to be a map and add itself (and a potentially existing meta node) as key:

if(not node.meta) node.meta=*new Node();
(*node.meta)["my_annotation"]=my_annotation;

An example would be a node of kind list, where all children represent elements in the list, but extra information other than the type may be stored, such as whether the list is already ordered or whether all elements adhere to a specific class and if this generic template type is enforced and validated.

todo

How to handle tools trying to use the same meta/annotation key?

Home

Philosophy

data & code blocks

features

inventions

evaluation

keywords

iteration

tasks

examples

todo : bad ideas and open questions

⚠️ specification and progress are out of sync

Clone this wiki locally