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

Rekursion in Einreichungen #18

Open
jvoigtlaender opened this issue Jan 7, 2025 · 3 comments
Open

Rekursion in Einreichungen #18

jvoigtlaender opened this issue Jan 7, 2025 · 3 comments

Comments

@jvoigtlaender
Copy link
Member

... könnte erkannt und unter Umständen (konfigurierbar) "bemängelt" werden.

Beispiel: Wenn in etwas wie der valid/summer-Aufgabe aus Versehen etwas Rekursives aufritt, liegt wahrscheinlich ein Missverständnis vor, auf das Studierende hingewiesen werden könnten.

anderes Beispiel: Wenn bei der sub-via-add-Aufgabe doch eine der vorab bekannten rekursiven Lösungen für sub eingereicht wird, könnte das zurückgewiesen werden.

Sinnvoll wäre wohl ein Parameter, mit dem man als Aufgabensteller je nach Wunsch folgende Dinge ausdrücken kann:

  1. Ob Rekursion verwendet wird, ist egal.
  2. Wenn Rekursion auftritt, sollte darauf hingewiesen werden, dass die Aufgabe keine Rekursion benötigt (aber das alleine führt noch nicht zu einem Zurückweisen, sofern nicht auch irgendein Test fehlschlägt).
  3. Wenn Rekursion auftritt, sollte die Einreichung zurückgewiesen werden (selbst wenn die Testsuite erfolgreich durchläuft), mit einem Hinweis, dass Rekursion gerade verboten ist.
  4. Wenn keine Rekursion auftritt, sollte darauf hingewiesen werden, dass es sinnvoll wäre, die Aufgabe mit Rekursion zu lösen (aber die Abwesenheit führt nicht zur Zurückweisung, wenn die Testsuite erfolgreich durchläuft).
  5. eventuell auch: Wenn keine Rekursion auftritt, ist die Einreichung zurückzuweisen (mit entsprechendem Hinweis), selbst wenn die Testsuite erfolgreich durchläuft.
@jvoigtlaender
Copy link
Member Author

Die Rekursionserkennung (syntaktisch) müsste sich dabei auf die gesamte Einreichung beziehen, also nicht nur ein einzelnes Prädikat prüfen. Damit etwa das "Verbot", sub rekursiv zu definieren, nicht einfach umgangen werden kann durch:

sub(U,V,W) :- subRek(U,V,W).

subRek(U,z,U).
subRek(s(U),s(V),W) :- subRek(U,V,W).

Andererseits sollte sich die Erkennung nur auf die Studierendeneinreichung beziehen, nicht auf die versteckten Definitionen der Aufgabenkonfiguration. Also wieder etwa in der sub-via-add-Aufgabe sollte nicht bemängelt werden, dass das (versteckte) add-Prädikat rekursiv definiert ist.

@jvoigtlaender
Copy link
Member Author

Alternativ wäre vielleicht auch denkbar, die Konfigurierbarkeit feinkörniger zu machen, indem angegeben wird, welche Prädikate rekursiv sein sollen oder nicht sein sollen. Aber das ist möglicherweise Overkill bzw. den Aufwand nicht wert.

@jvoigtlaender
Copy link
Member Author

Die Erkennung sollte auch mutual recursion erfassen (was den Ansatz, einzelne Prädikate als rekursiv/nicht-rekursiv zu deklarieren, wahrscheinlich noch weniger attraktiv macht).

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

1 participant