feature/new parser on kore

**please review** @dwightguth 

A bit of context:
take textual full K outer definition ( with KAST inner)
->
KIL outer + bubbles
-> via KIL-to-KORE
KORE outer + bubble
->
parse KAST bubbles with new parser using a KORE outer definition of KAST (from kore.k)
->
complete KORE :-)

@radumereuta, this is the work we did last week. I fixed some tests and cleaned up a bit. have a look and adjust as you see fit.
Here's my suggested solution: move the preexisting Poset class into the
kore package.

On Mon, Dec 22, 2014 at 1:03 PM, Cosmin Radoi <notifications@github.com>
wrote:

> In kore/src/main/scala/org/kframework/POSet.scala
> <https://github.com/kframework/k/pull/1264#discussion-diff-22183466>:
>
> > @@ -0,0 +1,76 @@
> > +package org.kframework
>
> I agree I should add more javadoc and comments here.
>
> Just adhoc Scala code
>
> I take pride in my code. I'm not claiming perfection but, aside from the
> lack of documentation, could you please explain what is ad hoc about this
> code?
>
> which could have just as well be Java
>
> Actually, not easily. We needed the Poset for the subsorts exposed by a
> Module. We initially tried to use the existing poset implementation, but
> it is not that easy. The problem is the kore classes are separated from the
> rest of the code base. The kernel module depends on the kore module. This
> means that we cannot use any existing Java code from within the KORE
> classes. They can be used by other classes but not the other way around.
> So, the options were to either implement a POSet, or create an interface
> and add a poset factory as a parameter to the Module class. The latter
> would basically means adding a lot of abstraction machinery for a very
> simple thing. So I chose to simply implement the POSet by the KORE class.
> Other classes in KORE will likely need it (we'll need also a labels POSet
> soon) so this is keeping complexity down overall.
>
> I don't know about others, but I am personally tired of having this
> discussion over and over again. This slows us down and we've got lots of
> things to do. You got the maximum you can get wrt Scala for now.
>
> I am not asking for anything more regarding Scala. I'm just trying to
> implement things in the fastest cleanest manner possible, while making sure
> that anything I do will be very usable for developers trying to use the
> KORE classes from Java. I'm not taking here about names, which can be
> easily changed (e.g., for the POSet we'll need aliases for the <, >, and ~
> methods as Java doesn't allow method names like that), but higher-level
> decisions regarding how things are put together.
>
> So far this means I've implemented in Scala everything related to KORE
> classes and their supporting infrastructure (visitors, underlying data
> structures, etc.). I use Java for everything that uses the KORE classes for
> a specific purpose, e.g., compiler passes.
>
> Is this different from our understanding? I'm really doing my best here
> and these discussions slow me down also.
>
> We may re-evaluate the situation after we have a clean, KORE based
> implementation that works well. Maybe K 5.0.
>
> I was hoping K 5.0 would be implemented mostly in K.
>
> In any case, if you prefer a specific different solution for this specific
> issue, let me know and I'll implement it.
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/kframework/k/pull/1264/files#r22183466>.
>