[Roma.pm] Perl REPL [Was: Re: un saluto a tutti]

[Adriano Ferreira]

On 4/26/07, Flavio Poletti <flavio at polettix.it> wrote:
> Wow, non avevo visto che Shell::Perl era tuo! Sostanzialmente, ho visto
> che la "critica" al tuo modulo è che "uses package variables to persist
> data between lines (think namespaced globals)" (non so se il tuo modulo è
> "easy to extend" o no). Ti va di spiegarci il problema? :-)


Proverò a spiegare il mio punto di vista. Ma devo scusarmi perché non
potrò dire a quello in italiano senza danneggiare ogni altoparlante
italiano qui. Allora risparmierò da tale dolore (a me ed a voi) e
scriverò in inglese.

I will try to explain my point of view. I don't share the idea that
"using package variables to persist data between lines" is such a bad
thing. This is just what you expect from getting together the lines of
code into a script to be fed to the Perl interpreter. The package is a
natural thing, just so the 'main' package is used in a simple script
and the undeclared variables (when using " no strict 'vars' ") end up
as package variables.

The REPL is a tool for experimentation -- it should be handy. And
declarations for one-shot code does not seem handy too me. So by
default Shell::Perl allows:

    $ pirl
    Welcome to the Perl shell. Type ':help' for more information

    pirl @> $a = 2
    2

    pirl @> $b = 2 + $a
    4

    pirl @> __PACKAGE__
    "Shell::Perl::sandbox"

and these variables may be found in the default package Shell::Perl
uses (in this case, "Shell::Perl::sandbox").

What the blogger (Matt Trout) was behind was a more strict REPL, where
he would say


    $ pirl
    Welcome to the Perl shell. Type ':help' for more information

    pirl @> my $a = 2
    2

    pirl @> my $b = 2 + $a
    4

and that works today if you replace "my" by "our". I will introduce a
change so that a user can made that strictness required. For the
reasons I pointed out above, "no strict qw(vars subs)" is used to be
easier to type things into the REPL. But it will not be hard to
replace that with "use strict;" if the user wants to declare every
variable.

But with "our", the variables are package variables yet and if they
make you sad as it seems the case with Matt, you must extend the scope
of 'my' variables beyound the current lines. In the actual
Shell::Perl, it is a feature of eval that the 'my' variables last for
the length of the line and then go away. This is another (optional)
configuration I will introduce (but I have to experiment with it
first): the loop will use Devel::EvalContext to extend the lexical
environment through many input lines. In this case, the lines above
could be typed directly into the shell prompt with the expected
results.

But as I insisted, the REPL is supposed to a very simple way to run
Perl statements interactively and, in this regard, there is nothing
wrong about package variables. And, at least, you can wipe our your
sandbox package with

    pirl @> :reset

    pirl @> \%Shell::Perl::sandbox::
    { "BEGIN" => *Shell::Perl::sandbox::BEGIN }

I don't know how much extensibility I will try to implement into
Shell::Perl. It does a very definite task: reads - evals - prints and
I thing that (at least with respect to this main objective) it may be
quite complete once the module is more mature and very few features
would be necessary or desirable when you consider the trade-offs of
keeping the REPL simple and functional. I don't see many people
interested in extending a Perl REPL once it works ok (that means once
it does a good job reading, evaling and printing Perl
expressions/statements). But the code will always be there as an
open-source project and I will be open to suggestions and
contributions.

I posted a comment in the blog

http://chainsawblues.vox.com/library/post/a-perl-read-excute-print-loop-repl.html#comment-6a00cd971ce84f4cd500d4142e9a006a47

but Matt is really right about the advantage of avoiding typos in
variable names. Nevertheless if you're lazy, you won't try to use too
long variable names in a shell that you can't glance at some
occasional typo.

Well, that's it!


> Ciao,
>
>    Flavio.