I'm going to suggest making it not Perl. Instead make it JavaScript. The languages are similar enough that she should be able to transfer her expertise over, but being able to use a browser for your interactive GUI is more likely to excite a teacher. She'll just have to get used to using Firefox and getting her debugging information in the error console. (You can find that in the Tools menu.)

A reasonable project might be to write a web page that will put up an $n*$m grid of squares that are black or white. If you click on one, it will flip the color of that square and the one to the north, south, east and west. Also have a button that says "Find Solution". Then once found it will say how many moves are left, will ask you if you wish to see it, and then can proceed to step you through that solution.

If you wish to tackle that project you may wish to peek at 5x5 Puzzle. If she can learn how to use closure-based callbacks in JavaScript and can port that code, she'll have the solution part of that project. If she can understand how to programatically tie closures to event handlers in JavaScript, then she should be able to create that GUI interface. Of course working out the details should take her a lot of work. And she'll learn a lot in doing it.

Now what the heck are closures? Well closures are just functions that keep a reference to the environment that it was created in. If you want to twist your brain, try to figure out how Re (tilly) 1 (perl): What Happened...(perils of porting from c) works. If you figure it out, then you probably understand closures.

Now I've given you lots of examples of closures in Perl. To do one in JavaScript is similar. Here is a code example:

var x = "hello "
var my_closure = function (y) {
  alert(x + y);
}
my_closure("world");
[download]

Now translating that Perl into JavaScript will cause you to encounter one very, very confusing piece of behavior. In Perl the following creates an array of closures over different variables:

for (@some_array) {
  # Declaring this in the loop creates a new variable per
  # instance of the loop.
  my $x = $_;
  push @closures, sub {
    # Do something using x.  I'll just return it.
    return $x;
  };
}
# We now have one closure per array element.
[download]

Unfortunately in JavaScript all variables are scoped to the nearest function call. So a literal translation does something very different:

for (var i = 0; i < some_array.length; i++) {
  // Declaring this in the loop creates a one variable for
  // all instances of the loop.
  var x = some_array[i];
  closures.push(function () {
    // Do something using x.  I'll just return it.
    return x;
  });
}
// All closures now point at the last element.
[download]

How annoying. You need to arrange to have a function call. The ugly, gross, but effective syntactic trick to do the right thing looks like this:

for (var i = 0; i < some_array.length; i++) {
  // This declares and immediately calls a function, and x
  // is scoped to that function call.
  (function (x) {
     closures.push(function () {
      // Do something using x.  I'll just return it.
      return x;
    });
  )(some_array[i]); // And here is where we bind the value.
}
// We now have one closure per array element.
[download]

Blech. Double blech. Ick. Double ick. But it works. And thanks to me you don't have to learn it the hard way.

You could try the same project without using closures. However doing so is probably a good way to find out why I recommended using closures. :-)