NameCdError: refine input handling and feedback for empty due-to lists

[Copilot]

NameCdError produced confusing feedback when learners submitted an empty relationship list: a “chosen relationships” feedback section with no meaningful content, and a rendered “diagram after removal” that was just the unchanged original diagram.
This change keeps empty selections valid but removes those misleading outputs for the empty-list case.

Additionally, based on review feedback, answer parsing was adjusted so empty quiz input forms are accepted consistently:

• NameCdErrorAnswer now derives FromJSON with the same fieldLabelModifier = upperToDash options as ToJSON.

• Parsing now post-processes decoded input so due-to is treated as [] when it is missing or null.

• This preserves encoder/decoder consistency and avoids hardcoded field-name drift.

• Description

  • nameCdErrorSyntax
    • Guarded relationship-feedback output behind a non-empty dueTo check.
    • Result: no “Hinweis zu gewählten Beziehungen” block when no relationships were selected.
  • nameCdErrorEvaluation
    • Guarded the post-grading “resulting class diagram” explanation/rendering behind the same non-empty dueTo check.
    • Result: no redundant “diagram after removing selected relationships” when nothing was selected.
  • NameCdErrorAnswer parsing
    • Uses derived FromJSON with the same options as ToJSON.
    • Missing or null due-to is normalized to [] before parsing.
    • Result: due-to: [], due-to: null, and omitted due-to all behave as empty selection.
  • Behavioral intent
    • Implements issue option 1 (special-case output handling), not option 2 (reject empty input), preserving compatibility with instances where empty relationship selection is semantically valid.

if null (dueTo x)
  then pure ()
  else
    paragraph (translate $ classDiagramDescription points)
    *> paragraph (image $=<< cacheCd cdDrawSettings mempty Nothing changedCd path)

[jvoigtlaender]

@horriblename, can you check this has the desired behavior; and possibly refactor the if ... then pure () ... stuff using when or unless?

[jvoigtlaender]

There will probably be a remaining issue, that could also be addressed by some special-casing here?

Let's say an instance of this task type actually has as correct answer that there wasn't any error, hence no relationship should be named as problematic. (Such an instance could be a hand-written one.) Now let's say the student claims that there is an error and indeed names some relationships as problematic. The correct answer would be no-change, though. It seems at current the student would nevertheless get some feedback related to how deleting their given relationships affects the class diagram, even though that's irrelevant since the class diagram was actually correct as given originally.

[horriblename]

(I haven't looked at the second comment, will do so later)

[horriblename]

currently in the Quiz version, an empty due-to: is parsed as a yaml null and so we get a syntax error (due-to: [] works though), should I modify the parser to accept null as []?

[jvoigtlaender]

The parser fix seems a good idea.

[jvoigtlaender]

Maybe also the case that students don't give a due-to: at all should be accepted. That is, if they only give reason: and nothing else, then it is interpreted as if they had also given due-to: [].

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: f1603bdcd7

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[Copilot]

Pull request overview

Suppresses misleading output in NameCdError when a learner submits an empty dueTo list: the "chosen relationships" feedback block and the post-grading "diagram after removal" rendering are no longer produced. The diff also makes the due-to field optional in the answer JSON parser (defaults to []).

Changes:

• Guard the relationship feedback paragraph + multipleChoiceSyntax call in nameCdErrorSyntax behind unless (null (dueTo x)).
• Guard the resulting-class-diagram explanation/rendering in nameCdErrorEvaluation behind unless (null (dueTo x) || all not solutionDueTo).
• Replace deriveJSON with deriveToJSON and add a hand-written FromJSON instance that makes due-to optional with default []; add OverloadedStrings and broaden Data.Yaml imports.

[jvoigtlaender]

@copilot apply changes based on this feedback

Do it with the "deriving FromJSON with the same options and then post-processing with a default" suggestion.

[Copilot]

Implemented: NameCdErrorAnswer now derives FromJSON with the same fieldLabelModifier = upperToDash options, and missing/null due-to is defaulted to [] in a post-processing step before parsing. Commit: 4cf8816.

[jvoigtlaender]

@horriblename, can you check whether the changes in the range https://github.com/fmidue/modelling-tasks/pull/640/changes/4e9b14c0d53557837592712ab517bd13939702ba..d0a51bda012ff47ea2314cc147ed841a5fd12e5b achieve the same as you had via the hand-written instance?

[horriblename]

yes, they behave the same