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

Mehrstufiges Parsen wo angebracht #126

Open
owestphal opened this issue Apr 11, 2024 · 3 comments
Open

Mehrstufiges Parsen wo angebracht #126

owestphal opened this issue Apr 11, 2024 · 3 comments

Comments

@owestphal
Copy link
Member

Durch #125 kann jetzt in den Grading-Funktionen jeweils der verwendete Parser individuell gewählt werden bzw mehere verschiedene Parser stufenweise hintereinander geschaltet werden (siehe Skizze in #83 und partialGrade in LogicTasks.Syntax.TreeToFormula).

Nach dem selben Schema können sicherlich auch in einigen anderen Aufgabentypen die Parserfehlermeldungen verbessert werden.

@jvoigtlaender
Copy link
Member

jvoigtlaender commented Apr 11, 2024

Konkret bereits in LogicTasks.Syntax.TreeToFormula.partialGrade könnte vielleicht tokenSequence noch durch einen Parser ersetzt werden, der zusätzlich bereits "die Klammern zählt", der also mit einer aussagekräftigen Fehlermeldung reagiert, wenn es in einem Präfix der Eingabe mehr schließende als öffnende Klammern gibt, sowie wenn es in der gesamten Eingabe mehr öffnende als schließende Klammern gibt.

@jvoigtlaender
Copy link
Member

jvoigtlaender commented Apr 11, 2024

Das würde natürlich bedeuten, dass in

case parse (fully $ parser @TreeFormulaAnswer) "(delayed input)" ans of
Right f -> partialGrade' inst f
Left err -> reject $ case parse (fully tokenSequence) "" ans of
Left _ -> do
german $ show err
english $ show err
statt der err-Message des "Hauptparsers" doch (auch oder nur?) die Fehlermeldung des "Hilfsparsers" auszugeben wäre.

Das ist ja aber vielleicht sowieso sinnvoll? Also wenn etwa schlicht ein Symbol falsch geschrieben ist (<==> statt <=>), mag bereits der tokenSequence-Hilfsparser vielleicht eine bessere Fehlermeldung haben als der eigentliche TreeFormulaAnswer-Hauptparser?

@jvoigtlaender
Copy link
Member

Oben vorgeschlagene Anpassungen/Verfeinerungen könnten jetzt zumindest teils durch Veränderungen an (oder alternativ verwendeten Funktionen zu) folgendem umgesetzt werden:

complainAboutMissingParenthesesIfNotFailingOn :: Maybe a -> ParseError -> State (Map Language String) ()
complainAboutMissingParenthesesIfNotFailingOn maybeHereError latentError =
case maybeHereError of
Just _ -> do
german $ show latentError
english $ show latentError
Nothing -> do
german $ unlines
[ "Ihre Abgabe konnte nicht gelesen werden." {- german -}
, "Bitte prüfen Sie, ob die Anordnung der Symbole den Regeln zur Wohlaufgebautheit der Eingaben genügt." {- german -}
, "Insbesondere sollten Sie genügend Klammern benutzen." {- german -}
]
english $ unlines
[ "Unable to read solution."
, "Please make sure that the arrangement of symbols adheres to the rules for well-formed inputs."
, "In particular, you should use enough parentheses."
]

und/oder Aufrufstellen wie:

partialGrade = parseDelayedAndThen complainAboutMissingParenthesesIfNotFailingOn (void $ many logicToken) . partialGrade'

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants