|We don't bite newbies here... much|
Perl Automateaching -- part 1: brainstormingby Discipulus (Abbot)
|on Mar 15, 2020 at 17:20 UTC||Need Help??|
I'm away from active perl coding since last june but I have this idea hunting me and, being forced to stay at home, as many others europeans, maybe is a good ocasion to start coding again on this.
The main goal is to produce a module able to ask perl question and evaluate answers given by the user. The code provided by the user will not arrive on STDIN but instead I would opt to a document based approach: the user is provided with a file to edit and the possibility to submit it to be reviewed, multiple time if needed.
The module name will be something like Perl::Tutor or Camel::Tamer or Camel::Trainer or Perl::Teacher or I can use the automateaching word.. but for the moment let's assume the main object will be $tutor for brevity.
The module will provide some general methods to build up the configuration (path to perl executable, folder to save works..), others to ask questions and to read user's input but these are trivial and I dont want to bother you with such details (for the moment ;).
The part where I want to hear from you is the judging process of the provided perl document. I imagine something like this:
And hic sunt leones infact the hard part is how @tests is constructed and how tests are run. This first meditation is about a general brainstorming on which tools to use and how build up the process of judging. My ideas:
1) PPI will be very useful and is the main reason for the $tutor being document oriented. This has also the plus that user will end with a lot or recipes to review. PPI is able to find every kind of statement inside a perl program with PPI::Statement::Variable for example.
2) Perl-Critic which I must confess and didnt love, probably because I dont know it well, can be handy, becuase, if I understand it correctly, $tutor can apply standard and custom policies to the user provided perl program.
3) Simple scripts can be just inspected by the mean of their output and general funcionality: in this light Test::Script can be the right tool.
4) Testing.. I'd love to use the powerfull perl testing framework in its whole but will be problematic being standalone scripts and not modules. This is a problem hunting me since years.. More complex tasks given to the pupil possibly can be modules but not at start. Code provided can be copied into a temporary file and modified to be a Modulino but his seems complicate and fragile solution. Well PPI can be used to extract all subs of a script and to wrap the rest into a main one, but is maybe too much an artificious.
I want to hear from you about the above idea and its possible pitfalls. I still dont know how to implement it: any suggestion will be welcome! Help on Perl-Critic and PPI and on testing implementation in the module will be very welcome!!
updtate automateaching -- part 2: proof of concept is out!
There are no rules, there are no thumbs..
Reinvent the wheel, then learn The Wheel; may be one day you reinvent one of THE WHEELS.