Explicit prefix when writing references on MinML

[ranfdev]

I'm implementing a parser for MinML in typescript.
It's mostly done, but it doesn't recognize references containing symbols like - and +.

I could fix that by using backtracking, but I think it would be nicer to keep the parser linear with the ability to lookahead 3 chars.

The following cases, as far as I know, require backtracking to decide how to parse them:
[-[comment]] maps to []
[---] maps to "\u2014"
[----] maps to [----]
[ldquo] maps to some html code.

If references explicitly required a prefix like ., the previous cases wouldn't require backtracking and they would become:
[-[comment]] maps to []
.[---] maps to \u2014
[----] maps to [----]
.[ldquo] maps to some html code.

I feel the brackets are too overloaded and that the syntax .[reference] would bring some clarity.

[bford]

Hi @ranfdev thanks for your working on a typescript parser for MinML, and I'm so sorry that I never managed to see this issue you opened 3 years ago now, because I've mostly had to focus on other things and the matchertext project has been mostly dormant during that period.

But if you're still interested, matchertext and MinML are coming out of dormancy this spring as several new students are working on related projects and we're getting things moving again; that's why I finally noticed the Issue you opened.

In brief answer to your backtracking question, I see the scanning of the single - in the [-[comment]] case, and the --- etc in the others, as basically a lexical-analysis step logically "before" hierarchical parsing in the pipeline, basically producing lexical "tokens" like -, ---, etc. You could implement this lexical analysis with a linear scan either before, or during and combined with, the hierarchical parsing, as usual. But once you treat element tags like this as lexical tokens (which in MinML can consist of practically all printing characters other than matcher pairs and the space-suckers '<' and '>'), there should be practically no backtracking needed at the subsequent parser stage. The first comment example is "left-bracket token, - token, left-bracket token"; ...; the second example is "left-bracket token; --- token; right-bracket token"; etc. All of this should be easy to do with a linear scan and no backtracking other than with at most one-token lookahead, with the right code structure.

Hope this helps, FWIW!