Architecture

Overview

There are several parts which each custom language shall have: lexer, parser, PSI (Program Structure Interface).

The Neon problem

There are actually two Neon's: a) (raw) Neon and b) Neon config.

• "Raw" Neon is simple data serialization format (like JSON)
• Neon config defines a structure of raw neon, which is used for configuration. It is also the most common use of (raw) Neon.

So here comes a question: which of these shall we support?

First, we decided to parse Neon config directly, which was wrong and just did not work.

Therefore we decided to for the right approach: first, parse (raw) Neon and then process its individual parts to parse out the Neon config. Actually, it makes more sense than the earlier scenario. But it makes more classes to be implemented.

Lexer

So far we have three lexers (classes):

• NeonLexer - uses JFlex to lex (raw) neon
• NeonLexer2 - uses Java's regular expressions to lex (raw) neon
• HighlightingNeonLexer - wraps a raw lexer and using some genial logic, it provides more specific token types. It still understands only the raw neon.

I think we'll have more lexers for the Neon config, e.g. to parse class names, services, parameters etc.