Adding_a_language - hpgDesigns/hpgdesigns-dev.io GitHub Wiki

The EDL parser, while based on JDI, stores code in a standard syntax tree and is designed to promote modularity in export formats. That being the case, adding a language is relatively easy; this page will document the process and highlight key points to keep in mind.

Parsing

Each language module is responsible for populating a JDI context with a set of definitions for ENIGMA to utilize. These are C++-format, since EDL's syntax most closely resembles C++. Other languages will simply map applicable reference types to those of C++ (and therefore of EDL). Should a change be made later to accommodate referencing features of other languages (such as "safe" versus "unsafe" function references), this specification will be revised.

Pretty Printing

• The EDL parser does not rename variables which conflict with the host language, as the host language is unknown to it. It is up to the code exporter to ensure that identifiers do not conflict with its language.
• The EDL parser stores out-of-scope references nonchalantly as pointers to their description. If a reference is made to objects from another namespace, class, or function, it falls on the pretty-printer to qualify it. For example,
  • If they choose to use a namespace called "boost", the C++ pretty printer must qualify identifiers from that namespace with boost::.
  • If they choose to use the JavaScript Math namespace, the JavaScript pretty printer must qualify identifiers from that namespace with Math..
• Arrays in GML are two-dimensional, and are accessed as a[b,c]. This will parse as SUBSCRIPT(a, COMMA(b,c)). You must check for this and handle it appropriately while pretty-printing.

Things you don't have to consider

• Some pieces of the specification that are independent of the target language do not need handled by the language plugin. These include the following:
  • Enumeration constants are assigned at lex time by the parser.