Too many scanners being created

[ehildenb]

See #2119 (comment)

Many of the scanners are useless, for example we're building scanners for INT but we aren't even importing that.

[radumereuta]

For this module, we get a lot of extra scanners being generated:

module TEST
  syntax Foo ::= foo()
  syntax Foo ::= bam()
  syntax Foo ::= fu()
  syntax Foo ::= "bar" [token]
               | r"ba." [token, prec(3)]

  rule foo() => .K
  rule bam() => .K
  rule fu() => .K
  rule bar => .K
  rule baz => .K
endmodule
$ kompile test.k --backend haskell
...
Outer parsing [50 modules]                                   =  0.723s
New scanner: DEFAULT-CONFIGURATION-CONFIG-CELLS              =  0.116s
New scanner: STDIN-STREAM-CONFIG-CELLS                       =  0.218s
New scanner: STDOUT-STREAM-CONFIG-CELLS                      =  0.219s
Parse configurations [3/3 declarations]                      =  0.532s
New scanner: TEST-RULE-CELLS                                 =  0.119s
New scanner: K-EQUAL-KORE-RULE-CELLS                         =  0.118s
New scanner: K-EQUAL-RULE-CELLS                              =  0.121s
New scanner: INT-SYMBOLIC-RULE-CELLS                         =  0.135s
New scanner: INT-SYMBOLIC-KORE-RULE-CELLS                    =  0.137s
New scanner: BOOL-RULE-CELLS                                 =  0.143s
New scanner: INT-RULE-CELLS                                  =  0.139s
New scanner: INT-KORE-RULE-CELLS                             =  0.143s
New scanner: TEST-RULE-CELLS                                 =  0.156s
New scanner: STRING-KORE-RULE-CELLS                          =  0.186s
New scanner: STRING-COMMON-RULE-CELLS                        =  0.194s
New scanner: K-IO-RULE-CELLS                                 =  0.299s
New scanner: STDOUT-STREAM-RULE-CELLS                        =  0.319s
New scanner: STDIN-STREAM-RULE-CELLS                         =  0.327s
Parse rules [105/105 rules]                                  =  0.573s
...

14 scanners are being generated and we should be able to parse with ~3.
The algorithm that determines this is not that smart but in this case, the penalty is really small since the definition is small and the scanners are easy to generate.
On larger definitions this doesn't tend to be a problem because we're usually importing all these modules in the main module.
So I'm inclined to call this a no-fix. (see next comment)

[radumereuta]

The other problem: we're not including INT but it appears in the list, it's because we are including
K-REFLECTION -> STRING -> INT
Not sure how to handle this^
@ehildenb @dwightguth

[ehildenb]

Why are we importing K-REFLECTION here? https://github.com/kframework/k/blob/b9bbf2b3c1967c8cbe09493498e0254e7f11adc4/kernel/src/main/java/org/kframework/kompile/DefinitionParsing.java#L195

Should we have tighter requirements on it? I guess the same question for the other auto-imports.

[radumereuta]

Apparently K-REFLECTION is being used in the compilation steps: ResolveFreshConstants and ResolveIOStreams.
It is also imported by STDIN-STREAM because it uses #parseKAST
We need to import STDIN-STREAM and STDOUT-STREAM because we don't know if we need them until we parse the configuration.
We also need MAP for configuration parsing.

[ehildenb]

It should be OK to not include K-REFLECTION in the LLVM/Haskell backends. We can do this with module exclusion tags (putting kast on K-REFLECTION), or with an explicit check at teh line above.

[radumereuta]

More findings:
The LLVM backend uses streams: https://github.com/kframework/k/blob/master/k-distribution/tests/regression-new/imp++-llvm/imp.md
Reminder, STDIN-STREAM imports K-REFLECTION because it uses #parseKAST.

The haskell backend uses streams: https://github.com/kframework/k/blob/master/k-distribution/tests/regression-new/issue-1436/test.k

Not sure how to untangle this. @ehildenb @dwightguth

[radumereuta]

Try to remove rule [stdinParseArbitrarySort]:. I don't think it's being used.
This would allow us to remove K-REFLECTION from being included automatically.