Syntaxbaum zu Formel: Parserdefekt

[KaroBo2409]

wenn eine doppelte Negation vorkommt, steht sie in der Lösung ohne Klammern da. Wenn man aber versucht das so hochzuladen, bekommt man einen syntaktischen Fehler

Eingabe: --C /\ ((B /\E) \/ (-D \/ A)) -> wirft einen Fehler vorgeschlagene Lösung: ¬¬C ∧ ((B ∧ E) ∨ (¬D ∨ A))

vielleicht darauf hinweisen, dass in solchen Fällen eine Klammerung benötigt wird

[jvoigtlaender]

@owestphal, ist das eine Regression nach der Parser-Umstellung?

Diese Klammern sollten eigentlich nicht nötig sein. Nur bei den binären Operatoren dürfen bei dem Aufgabentyp keine Klammern weggelassen werden.

Und in der Tat ist das Verhalten auf verschiedenen Ebenen merkwürdig.

So wird dies akzeptiert:

¬¬C ∧ ((B ∧ E) ∨ (¬D ∨ A))

und auch dies:

(--C) ∧ ((B ∧ E) ∨ (¬D ∨ A))

und sogar dies:

- - C ∧ ((B ∧ E) ∨ (¬D ∨ A))

aber nicht dies:

--C ∧ ((B ∧ E) ∨ (¬D ∨ A))

Zusätzlich merkwürdig ist auch noch, dass bei letzterer Eingabe nicht etwa eine Syntax-Fehlermeldung mit Hinweis kommt (wie bei anderen Fehlern, also Klammer weggelassen oder gänzlich unbekanntes Symbol o.ä.), sondern einfach die Behauptung:

[owestphal]

Die Formelparser sind (leider) nicht das Problem. Die Ursache ist, dass Autotool in Eingaben leading Haskell-whitespaces filtert. Das führt dazu, dass eine Eingabe, die mit -- beginnt, als Kommentar und damit whitspace behandelt wird und deshalb verschwindet.

Das Problem ist grundsätzlich in allen Autotool Aufgaben vorhanden, scheint aber bisher nicht aufgefallen zu sein, weil es keine Überschneidungen in der Syntax mit -- oder {- gab.

Ich sehe gerade keine andere (pragmatische) Lösung außer einem Hinweis in der Legende, dass die Eingabe nicht mit zwei direkt aufeinander folgenden, als - notierten, Negationen beginnen darf.

[jvoigtlaender]

Wäre nicht ein anderer "Hack", der das Problem aber auch löst, bei Aufgaben, wo eine Formel als Antwort erwartet wird, im Generator einen Test (suchThat) drinzuhaben, der schlicht ausschließt, dass eine richtige Lösung mit -- anfangen kann?

[jvoigtlaender]

Wir könnten natürlich auch - aus der Legende rausnehmen und nur noch ~, nicht, not erlauben.

[owestphal]

Wäre nicht ein anderer "Hack", der das Problem aber auch löst, bei Aufgaben, wo eine Formel als Antwort erwartet wird, im Generator einen Test (suchThat) drinzuhaben, der schlicht ausschließt, dass eine richtige Lösung mit -- anfangen kann?

Das ginge. Dann bleibt aber immer noch der Fall, dass jemand (aus Versehen) eine Lösung mit -- am Anfang einreicht und einen nicht sehr hilfreichen Fehler bekommt.

Dann müssten wir den Hinweis ins Feedback schreiben. Also sowas nach dem Motto "Ihre Abgabe ist leer, falls sie mit -- beginnt fügen sie bitte ein Leerzeichen ein."

[owestphal]

Wir könnten natürlich auch - aus der Legende rausnehmen und nur noch ~, nicht, not erlauben.

Ich hatte das Gefühl, dass das die beliebteste Notation war im letzten Semester. Wäre schade wenn wir die aus (kleineren) technischen Gründen wieder fallen lassen würden.

[jvoigtlaender]

Ich wäre im Moment für eine Lösung, die sich deployen lässt, ohne dass irgendwelche schon zugeteilten Instanzen ungültig werden. Bei Verwendung von extraText wäre das ja wahrscheinlich der Fall. (Und die Idee mit suchThat während der Generierung löst das aktuelle Problem natürlich auch nicht, sondern hilft höchstens bei künftigen Instanzen.)

[owestphal]

Nach Absprache mit Marcellus scheint es eine einfache Möglichkeit zu geben die extra Behandlung von Kommentarsyntax (vorrübergehend) ab zu schalten. Sollte dann spätestens morgen irgendwann deployed sein.

[owestphal]

Das Problem ist jetzt im Autotool behoben.

[jvoigtlaender]

Das Problem ist jetzt im Autotool behoben.

Dauerhaft?

[owestphal]

Die Änderung ist noch nicht im Autotool Repo. Die notwendige Änderung am Code ist minimal (1 Zeile), aber es ist nicht ganz klar, ob es evtl. Teile des Autotools gibt, die das vorherige Verhalten benötigen (bei unseren Aufgabentypen ist das nicht der Fall). Wie das dauerhaft und vorallem mit Leipzig kompatibel umzusetzten ist, ist daher noch offen.