One more thing: right now WrapLabelRule looks roughly like this (I am
simplifying a bit):

```
class WrapLabelRule {
  KLabel label;
  KList apply(KList klist) {
    return new KList(new KApp(label, klist));
  }
}
```

All I propose is the following change to make it return TermCons, until we
complete the refactoring I spoke of:

```
class WrapLabelRule {
  String cons;
  KList apply(KList klist) {
    return new KList(new TermCons(cons, klist.getContents()));
  }
}
```

If there is some deeper complexity required here, I don't see it, so you'll
have to explain for me. This is the only place in the parser where the KApp
class is used, so I don't see how anything could be dependent on the fact
that that class exists in beween the outer KList and the inner List<Term>.
Am I missing some nuance of the domain?
On May 2, 2014 3:15 PM, "Radu Mereuta" <notifications@github.com> wrote:

> In
> src/javasources/KTool/src/org/kframework/parser/concrete/disambiguate/PriorityFilter.java:
>
> >          if (tc.getProduction().isListDecl()) {
> > -            tc.getContents().set(0, (Term) tc.getContents().get(0).accept(new PriorityFilter2(tc, context)));
> > -            tc.getContents().set(1, (Term) tc.getContents().get(1).accept(new PriorityFilter2(tc, context)));
> > +            tc.getContents().set(0, (Term) tc.getContents().get(0).accept(new PriorityFilter2(label, Side.LEFT, context)));
> > +            tc.getContents().set(1, (Term) tc.getContents().get(1).accept(new PriorityFilter2(label, Side.RIGHT, context)));
> >          } else if (!tc.getProduction().isConstant() && !tc.getProduction().isSubsort()) {
> >              for (int i = 0, j = 0; i < tc.getProduction().getItems().size(); i++) {
> >                  if (tc.getProduction().getItems().get(i) instanceof Sort) {
> >                      // look for the outermost element
> >                      if ((i == 0 || i == tc.getProduction().getItems().size() - 1)
>
> I don't know what makes you claim that the current semantics of priorities
> is 'wrong'.
> We chose to implement priorities this way because it is a simple system
> that is easy to explain and easy to implement. The fact that it doesn't
> handle your example doesn't convince me. It's not something that is widely
> used in programming languages. It could be potentially be handled by the
> full general rewrite engine.
> Even so. Now it's not the time to 'fix' this. First of all, we need a
> replacement for SDF, and after that we can think of ways to extend it.
>
> Regarding the concrete syntax trees... I don't know where you got this
> from. All the parsing systems that I've worked with produce abstract syntax
> trees. And for good reasons, it makes everything more complicated. The
> current infrastructure of K has problems handling this format. The latex
> and html backends need to be modified. Also if you want the split that
> Grigore wants between front-end and backend, you will need two versions of
> latex and html...
> I think the better solution here is to solve the problems with labels
> referencing multiple productions. That's what TermCons does (in a weird
> way). I think the best solution for this case would be to have two levels
> of klabels:
> 1. for parsing - maybe derived from the cons field? At this level I will
> solve all the ambiguities (priorities, associativity...)
> 2. for the rest of the compilation steps.
>
> You mentioned the parser returning TermCons. That's kind of hard to do.
> The parser actually creates KLists, and WrapLabelRule only puts a KApp
> with a label on top of that. TermCons has the list of children builtin. It
> would require heavy modifications either for the parser, or for everything
> that uses TermCons.
>
> KApp is more flexible. This is also why I added it to the filters. I want
> to remove TermCons at the same time with the SDF parser.
>
> I hope I'm making sense.
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/kframework/k/pull/406/files#r12246124>
> .
>