[m-rev.] for post-commit review: fill in most of the grade modifiers section

[Zoltan Somogyi]

For review by anyone.

Three subsections remain empty.

The first is for .par. I don't think I can write this section because
.par is actually two separate grade modifiers that share a name,
one for LLDS grades and one for MLDS grades, and while I know
what the LLDS one does (or would do, without an old crippling bug),
I don't know what *exactly* the MLDS one does. Can someone please
either fill me in deeply enough to enable me to write this subsection,
or volunteer to write it himself?

And do you guys have any opinion about stopping the name sharing,
i.e. having the LLDS and MLDS grade modifiers having separate names?
The changeover would be slightly disruptive, but it would eliminate
a source of confusion for all affected users from now on.

The second is for .c_debug. The issue here is a contradiction.
It is clear that this grade component is for MLDS grades, but for
which targets? The name says it is for C, compile_target_code.m
says it is for C (i.e. the code for compiling Java and C# files does not
consult the option representing it), but the code that computes grades
accepts its presence when targeting Java or C#.

I can see two ways to resolve this contradiction. One is to stop accepting
java.c_debug and csharp.c_debug grades. The other is to rename the
modifier to .target_debug, and make compile_target_code.m pay attention
to it when compiling Java and C# files. I think the second way is preferable,
*provided* that there is a single, at-least-relatively-stable way to enable
debuggability of Java and C# code. However, I know next to nothing about
the Java/C# ecosystems, so I cannot answer that question for myself,
and internet searches give me only SEO crap. So this is something
that you guys should decide. I do need a decision, though not necessarily
its implementation, before I can write this subsection.

The third is the compatibility subsection, which I will write after the above two
issues are resolved.

By the way, the old grade documentation also had a (partial) map
from grade components to the option values that they imply.
Should we include the completed map in the grades chapter as a new
section? I would be fine with both "yes" and "no".

Zoltan.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DIFF.gm
Type: application/octet-stream
Size: 41438 bytes
Desc: not available
URL: <http://lists.mercurylang.org/archives/reviews/attachments/20250807/d8a1829d/attachment-0001.obj>