Greedy parser enforces instruction order across components

[david-pl]

I have a CircuitInstruction enum which defines gates. Gates are frequently single letter instructions (h, s, x,...). The enum enforces a order.

For example, if I do this

#[derive(Debug, Clone, Copy, PartialEq, Eq, Instruction, Parse)]
pub enum CircuitInstruction {
    ...
    S,
    SAdj,

the crate doesn't compil:

error: token `s` is a prefix of `s_adj` declared after it — reorder so longer tokens come first
  --> crates/vihaco-circuit-isa/src/lib.rs:10:10
   |
10 | pub enum CircuitInstruction {

The fix for the single enum is simple enough, just order them correctly.

However, this can become annoying since it also leads to clashes across components. For example, h conflicts with CPU's halt. So, I have to prefix all circuit instructions with circuit. in order to avoid clashes. This is genuinely okay for this specific component, but might be annoying down the line if we end up having to prefix all kinds of new components to be used with a CPU. Also, it might actually make components incompatible when composing components which haven't been used together before.

[robpatterson13]

choice seems to be greedy; I'm thinking that we might have to sort the tokens based on length and order it that way for the user when we generate their parser (chumsky is a PEG parser, not a CFG parser)

As far as instruction set prefixes, I think that's going to be required, but we should automatically supply it for the user: think about two instruction sets foo and bar, both with an add instruction. We need some way to distinguish them, like namespacing in MLIR

[robpatterson13]

Will be fixed by #40