On May 4, 2010, at 3:43 PM, Daniel Carrera wrote:
> Craig DeForest <[email protected]> wrote:
>>> ~ $ perldl myprogram.pdl
>>
>> Already been done :-) In fact, the "pdl" executable exists only to
>> chain into perl so you can run pdl scripts from the command line:
>
> Interesting. Two questions:
>
> 1) Why don't you use "perldl"? More command names => Users are less
> likely to find it. I sure haven't seen it mentioned in the docs.
You can't use perldl because the UNIX kernel won't shebang into a
scripted interpreter,
so perldl (which is itself a script) isn't useful as a shebang
interpreter.
> 2) Why does it behave just like the command line? To me it seems that
> it just makes it less useful. You can't use "pdl" as the standard way
> to write PDL applications.
Because perldl can capture a journal of your interactions with it, and
it's useful
to be able to play those journal files back and get the same answer.
> What I was really suggesting was something more akin to a real Perl
> program. My goal was to use "perldl" to write complete programs, so
> that writing:
>
> #!/usr/bin/perldl
>
> ... some stuff ...
>
>
> Is exactly equivalent to:
>
>
> #!/usr/bin/perl
>
> use PDL;
> use PDL::Autoload;
> use PDL::NiceSlice;
Well, if I understand right the current regime happened because (A)
many folks want to write Perl scripts and use the additional features
of PDL (which is, after all, just Perl); and (B) there's a desire to
have an interactive environment with an autoloaded "bag o'
tricks" (hence the recursive-descent AutoLoad searches) like MatLab or
IDL.
> Imagine for a moment that you are a Matlab or IDL user trying out PDL.
> It seems sensible to use the same binary for both the command line and
> the program, and it seems sensible that the code should look basically
> the same. The last thing you want is to spend a couple of hours trying
> to figure out why your program is crashing even though all the
> instructions seem correct when you try them on the command line.
IDL has similar differences between .pro files and command-line
execution: many constructs that work in a .pro file don't work on the
command line, and vice versa, due to syntax shortcuts. I can't speak
to Matlab.
Perhaps perldl multiline constructs should be called out more
explicitly in the user's guide. To execute a
snippet of Perl code at the command line exactly as it would be
executed in a script, you need only enclose it in curly braces:
perldl> {
..{ > $a= 5
..{ > +10;
..{ > }
will set $a to 15, while
perldl> $a=5
perldl> +10;
will set $a to 5.
That is documented but not called out up-front in the intro guide;
perhaps it should be.
> And if people are going to use "perldl" or "pdl" as the standard way
> to
> write complete PDL programs, I don't think we want to be changing the
> character of the Perl language by adopting the Python-like "one line =
> one statement" rule.
No, the one line => one statement rule is just REPL sugar.
> Finally, for users who do come from the Perl world (such as myself), I
> think it is important that PDL program still feel like a Perl program.
Yep, thus the perl shebang / use PDL stuff.
_______________________________________________
Perldl mailing list
[email protected]
http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
