fslang-suggestions VS coherence

Trying to extend this https://github.com/fsharp/fslang-suggestions/issues/1089 to have two generics:

Basically, what I've made in Spiral. There is even a F# issue to improve the syntax.

Not currently supported but it's an open language suggestion that's likely to end up in F#. https://github.com/fsharp/fslang-suggestions/issues/506

Re: the argument accessor shorthand, there seems to be a proposal for exactly that (using _ instead of &): https://github.com/fsharp/fslang-suggestions/issues/506#issu...

I found this post (https://github.com/fsharp/fslang-suggestions/issues/975) which is about the same thing, but I'm confused as to what the final resolution was. There was mention of a taskSeq, but I can't find much info on that.

An issue in FSharp suggestions

F# doesn’t currently seem to support source generators.

"Blessed" literals: only FSharp.List and System.Array have a built-in collection syntax in the language ([ ] and [| |]). Only FSharp.List has a special pattern matching constructor (::). The language itself shouldn't favor a particular type over another: it should be possible, at the library level, to write the same code but using different collection types (related discussion here).

I mostly write F# so I can only speak for F#, but if you want you can create a module which extends Seq to add the OCaml names. I suspect the same is possible in OCaml. The authors are not trying to impede compatibility, but compatibility is not a goal. If you value compatibility, or adhering to ML norms, and you use F#, I recommend you (kindly) advocate for it in relevant issues on the F# language discussion repo. https://github.com/fsharp/fslang-suggestions/issues

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: