Non-recursive Java machine implementation

[JoshuaGross]

Here's the Java implementation. Note that this includes all of the commits from the other PR - I just separated it so you can review the JavaScript stuff properly. Obviously, the Java implementation is much more verbose (and frankly, not as pretty). Happy to clean anything up or refactor anything you have issues with.

[orlandohill]

Hi Joshua, Sounds great! Sorry, that I haven't been able to properly look at what you have done yet. If you're blocked from moving forward, you could write your own code generation, rather than modify Waxeye's Scheme code. Perhaps using JavaScript, a parser for the grammar language and a JavaScript template engine. The bootstrap parser could be created with the current version of Waxeye.

[orlandohill]

Otherwise, I'll be finished moving on Monday, so will have both a laptop and more time for development.

[nverwer]

Hi Joshua,

The new Java code contains a dependency on Java 8. Specifically, in org.waxeye.parser.RawError.java, line 42:

newList.sort(new Comparator<String>() {

The sort method is not supported before Java 8. It might be useful to modify build/properties to reflect this.

I am very happy with your implementation, and am currently integrating it in my project. I will let you know about my experiences.

[JoshuaGross]

Thanks for the comment @nverwer - if you've been able to update the code generation for Java we'd certainly love to see that too!

I'd prefer to just modify this so that Java 6 is supported, otherwise nobody will be able to use this library on Android.

[JoshuaGross]

I'll update this over the weekend if nobody else gets to it.

[nverwer]

Hello Joshua,

I was traveling and busy doing other things.
It is easy to make RawError.java compatible with Java 6:

    Collections.sort(newList, new Comparator<String>() {
      public int compare (String x, String y) {
        return x.compareTo(y);
      }
    });

It is not clear to me if the your java code supports a non-recursive implementation?
I still get stack overflows. I could look into it, but I am not sure where to begin.

[JoshuaGross]

@nverwer I'm not sure how you're running this, but the Java code generation doesn't currently work with this new Java implementation. I've been waiting for Orlando to finish that step since I don't know Scheme very well. If you've fixed the Java code generation, are using this implementation, and are still seeing stack overflows, could you send a minimal repro case?

[nverwer]

Hello Joshua,
I also don't know Scheme very well, although I did modify some Waxeye code in the past.
At the moment I am too busy on two projects to look at this. One of those needs the non-recursive implementation, and I will try to make some time for this next week.

Update:
I have looked at the old and new javascript implementations.
They are so different, that I find it hard to figure out where to begin rewriting the java code. What must be kept, what can be thrown away...
I am trying to map the old javascript implementation onto the old java implementation, then compare it to the new javascript implementation. In the meantime I hope to get a better understanding of the code-generating algorithm.

[JoshuaGross]

@nverwer I assume you didn't have much luck figuring this out. To be clear, all that needs to be changed to make this work is to update the code generation that's done in Scheme. The generated code will need to look more like the test data in structure. The new generated code for non-recursive machines will look very similar to the original grammar files.

[JoshuaGross]

If Orlando isn't able to look at the code generation soon (before Christmas), I'll probably rewrite the code generators using Javascript. However, this would be a very significant departure from the current structure of the project. If anyone can write a new code generator for Java or Javascript I'm pretty sure I could handle writing the other one.

[nverwer]

@JoshuaGross Indeed I could not figure out how to get this working in Java. I thought I needed to change the Java classes as well, along the lines of the new Javascript code. I started doing that, but it quickly became rather complicated.

My client needed some results, so I ended up tweaking the 'old' parser a bit and changed my grammar so it does not parse the bits that cause the deep recursion. It turned out that this makes the grammar more readable, and the parser is faster. This took away my incentive to work on the non-recursive code generator.
One thing I needed for this is to set eofCheck to false, so I can restart the parser on text fragments. This eofCheck seems to have disappeared in a recent version of your code (c2fc114). What is the reason that this was removed?

[JoshuaGross]

This is written to mirror the Scheme non-recursive implementation, which doesn't have eofCheck. Setting eofCheck to false means you aren't using it, which is the same functionally as deleting it.

[nverwer]

@JoshuaGross: You are right, of course. I think I earlier got the exception that is thrown when eofCheck is true (and I did not parse the complete input). I will have to look at that again. It may have to do with how I instantiate the parser (it is generated and compiled dynamically at runtime using Class.newInstance()).

[glebm]

@JoshuaGross @nverwer If you want to pick this up, I'd be willing to review.

[glebm]

The CoffeeScript was replaced with a new non-recursive TypeScript implementation and there is now a web demo / playground (powered by RacketScript): https://waxeye-org.github.io/waxeye/index.html

[JoshuaGross]

@glebm Thanks for the offer! If you'd like to take this on, go for it - I unfortunately won't be able to work on this anytime soon.

[michael-becker]

@JoshuaGross could you just give an update about the current status? If you guys don't have time, I would try to merge the NR-Java implementation with the current waxeye implementation.

[JoshuaGross]

@michael-becker What would you like an update on? I commented on January that I won't be able to work on this. I haven't looked at it in 5 years. Anyone who wants to pick it up from here should feel free to do so!

[orlandohill]

@JoshuaGross No worries! Thanks again for the time you took to contribute back to the project.

[orlandohill]

@michael-becker I'll be releasing a new version with Java support later this month. If an MIT license isn't a requirement, then you might prefer to use that version.