Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Simplify and allow for sharing of "delayed style" parsing #77

Merged
merged 54 commits into from
Feb 7, 2025

Conversation

patritzenfeld
Copy link
Member

  • Parsing now produces LangM' m Submission value
  • The encapsulated value is shared and fed to the check functions
  • aborts with reject feedback on parse errors
  • Added useParserAnd function to allow for further processing, i.e. with Delayed

@patritzenfeld patritzenfeld linked an issue Feb 4, 2025 that may be closed by this pull request
@patritzenfeld patritzenfeld added the after semester Add after current semester is finished label Feb 4, 2025
@patritzenfeld patritzenfeld linked an issue Feb 4, 2025 that may be closed by this pull request
@jvoigtlaender
Copy link
Member

Oben steht, dieser PR würde #72 schließen. Ich denke jedoch eher, dass er #74 schließen würde. Siehe auch #74 (comment).

@jvoigtlaender
Copy link
Member

I think the useParserWithFallback/parseWithFallBack function should, upon failure, at least optionally display the string it was trying to parse. Because that can be a string deeply nested in the original structure obtained from the HTML form. When, for example, the complainAboutMissingParenthesesIfNotFailingOn hits, then it would be good to display to the user which string it was that had this problem. (In the truth table filling case, it could be any of the column headers or answer formulas. The field number is not available anymore when parseWithFallBack runs. But displaying the offending string should help the student understand where something bad happened. In the Delayed parsing functions in logic-tasks this is not relevant. There, the complaining always concerns the whole input field, because there is only one big input field instead of many small strings each of which is looked at separately.)

@jvoigtlaender
Copy link
Member

There should probably also be a version of the "parser for second phase after input field structuring" without the fallback behavior. That is, something of type

  (Monad m, OutputCapable (ReportT o m))
  => Parser a
  -> (ParseError -> State (Map Language String) ())
  -> String
  -> LangM' (ReportT o m) a

(potentially plus the argument for optional turning-on-the-string-showing)

It's the function one gets from the other function by providing pure () as the fallback parser and ignoring the first argument of the messaging function.

@jvoigtlaender
Copy link
Member

Maybe the "optional-string-showing" should simply be realized by prefixing (String -> ... to the -> ... -> State (Map Language String) ()) functions?

@jvoigtlaender jvoigtlaender merged commit 2c5cd5f into main Feb 7, 2025
19 checks passed
@jvoigtlaender jvoigtlaender deleted the 74-share-parsing branch February 7, 2025 17:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
after semester Add after current semester is finished
Projects
None yet
Development

Successfully merging this pull request may close these issues.

share "parsing/preprocessing work"
2 participants