coherence VS fructure

There are a few different tool-sets for producing Java byte code. I'm not sure which one to suggest, because back when I last needed one (end of '96), there were none, so I wrote my own. But I assume that most people use ASM or something similar.

This is one that I like a lot. Years ago (1997 timeframe) I had implemented it in a Java compiler, and a few years later in a Java library (https://github.com/oracle/coherence/blob/4e6e343e1ffd9bbfea3...) that would create an exception on the assertion failure and parse its stack trace to find the source code file name, and read it to find the text of the assertion that failed, etc. so it could build the error message ...

In Ecstasy, we built the support directly into the compiler again:

```

For the debugger (but not required by the runtime), there is an optional table that points to the ranges of ops at which names and types are bound to registers

FWIW - here's an AST for Java that directly emits Java byte code: https://github.com/oracle/coherence/tree/master/prj/coherence-core/src/main/java/com/tangosol/dev/compiler/java

It has been "experimented with" many times. Here's an example from TDE, a component-based development environment from Tangosol (now part of Oracle).

If it helps, here's a Java recursive descent parser that I wrote years ago.

If you want to see an example, here's a Context interface from a multi-language compiler framework (compiling multiple different languages to Java byte-code) that I wrote years ago.

I built an entire Java compiler in four months, from scratch, by myself, over twenty years ago. (Now owned by Oracle; still used today. Thank you, Larry.) But starting from a well written spec for a simple language like Java is orders of magnitude easier than developing a new language, runtime model, and tool-chain from scratch.

As mentioned, the various parsing methods each contribute back an AST node, so on the way down the recursion, they are parsing, and on the way back up from the recursion, they are building the tree. Here's a fairly simple recursive descent Java compiler written in Java that I wrote a few years back, in case you are looking for an example.

If you're curious how some of this can be implemented in a Java compiler, I wrote one years ago. For example, checking that the left side is an l-value:

Even the racket teachpack libraries designed for education are very capable; I was able to make this structured editor with only using teachpack content without external deps: https://github.com/disconcision/fructure

Right, it's fine, and is a pretty basic macro. Doubly linked lists are pretty basic data structures too, even the Rust versions once you figure it out. I like your sibling comment making it look like the CL version. I still want to know in more detail though why you think that doing things this way instead of the CL way is less likely to be "fragile and break down" for the complicated stuff, it would help to have a specific complicated example to showcase. Perhaps the linked https://github.com/disconcision/fructure in another comment would be a good study? The author there claimed they might not have been able to manage with defmacro, maybe someone familiar with both could articulate the challenges in detail. Is it just an issue of some things benefit a lot from pattern matching, and if so, does using CL's Trivia system mitigate that at all (in the same way that using gensym+packages+Lisp-2ness can mitigate hygiene issues)?

see also: fructure