Do not allow capabilities in parsing and syntax check

[patritzenfeld]

This now runs in the Identity Monad. Afterwards the checks continue in IO.

[jvoigtlaender]

Come to think of it, do we actually anywhere (in modelling-tasks, logic-tasks ... any existing custom flex tasks) have a case where the syntax check requires any of MonadCache, MonadLatexSvg, MonadGraphviz, MonadDiagrams, MonadAlloy, MonadWriteFile either?

[patritzenfeld]

Come to think of it, do we actually anywhere (in modelling-tasks, logic-tasks ... any existing custom flex tasks) have a case where the syntax check requires any of MonadCache, MonadLatexSvg, MonadGraphviz, MonadDiagrams, MonadAlloy, MonadWriteFile either?

• composeFormula's flex version has both MonadLatexSvg and MonadCache for the tree images.
• petri-reverse-reach from ba-pei-ching has MonadDiagrams and MonadGraphviz
• MonadAlloy is never used outside the generation
• MonadPlantUml and MonadWriteFile aren't used at all, but this could come up later. They will appear there if we do flex versions of activity diagram tasks.

[jvoigtlaender]

Note that I said:

the syntax check

[jvoigtlaender]

So, for example this: https://github.com/fmidue/logic-tasks/blob/892db4aae14d5b71f5337e14a631b589e5a9ca13/flex/composeFormula.flex#L143-L148 seems to dispute one of your assertions.

[patritzenfeld]

Oh sorry. The syntax check seems to be vanilla OutputCapable in all flex-tasks at the moment. So should this be changed to run in Identity as well?

[jvoigtlaender]

Identity or potentially Either (if throwing/error handling is needed)? Or is error handling never (also not during parsing) surfacing at that level, because it will instead be put into the LangM part?

More invasively, maybe, the FilePath argument of syntax checkers could then be removed.

(Indeed, on a conceptual level, one could say: The syntax checks should be things that in principle could happen on the client side, with form verification / JavaScript. So indeed, they should not have access to files, IO command execution etc.)

[patritzenfeld]

An error could be thrown during parsing if parseInfallibly (which assumes the parse will always work and quits on failure) is used incorrectly. In other cases, the ParseError will be processed and embedded into LangM.

But I think you didn't mean that, but rather some way to communicate the ParseError? Then I think Either won't be necessary.

[jvoigtlaender]

Yes.

In any case, sooner or later the type checker would tell us about our wrong assumption if we now go with Identity but actually something "stronger" like Either would have been needed (since Identity will lack some relevant class instance).

[patritzenfeld]

I replaced the case now after all, because mapM is no longer confusing the reader by ignoring the function's argument.