CLI signature?
Juerd
would it be possible to give the program a sub-like signature?
I ask this after another painful session of forgetting how things
work, reading Getopt::Long's documentation.
signature (
Rule $pattern,
bool +$help :short('h'),
Int +$verbose :short('v'),
Str *@files = <->
);
With GNU-like parsing, this'd make
@*ARGS = < foo|bar --verbose 2 first second third >;
@*ARGS = < foo|bar -vv first second third >;
result in the lexical variables
$pattern = rx/foo|bar/;
$help = false;
$verbose = 2;
@files = < first second third >;
and
@*ARGS = < foo -- -v --verbose --help forth fifth sixth >;
in
$pattern = rx/foo/;
$help = false;
$verbose = undef;
@files = < -v --verbose --help forth fifth sixth >;
and
@*ARGS = < pattern >
in
$pattern = rx/pattern/;
$help = false;
$verbose = undef;
@files = ('-');
Probably a macro can handle this, but does (will) Perl parse a
signature-like argument list and hand the macro something it can use, or
would this require source-filter like trickery?
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Matthew Walton
Would this actually be any better than the interface provided by
Getopt::Long? I suspect that it's possible, and I also suspect that
Getopt::Long can be written in a much friendlier manner for Perl 6 (not
that I have any particular complaints about how it handles things now,
but it can certainly be better).
I do feel that command-line option parsing should not be built into the
language though - let modules take care of it, then we'll never have to
worry about pushing some built-in mechanism aside when we want to do
something peculiar.
What you want may well be possible with a module though - or something
similar to it.
Ingo Blechschmidt
Juerd wrote:
> This probably goes against everything a shell based platform wants,
> but would it be possible to give the program a sub-like signature?
I like that idea very much, but...
> signature (
> Rule $pattern,
> bool +$help :short('h'),
> Int +$verbose :short('v'),
> Str *@files = <->
> );
...this seems a bit ugly to me.
What do you say about that:
use Getopt::Auto;
run &main;
sub main (
Rule $pattern,
bool +$help :short("h"),
...
) {
...;
}
Getopt::Auto's run-subroutine would then use &main.signature (IIRC) to
parse @*ARGS, exactly as in your posting.
> Probably a macro can handle this, but does (will) Perl parse a
> signature-like argument list and hand the macro something it can use,
> or would this require source-filter like trickery?
With Perl providing &sub.signature, there won't be any need to use
macros or even source-filters :)
--Ingo
--
Linux, the choice of a GNU | Mathematicians practice absolute freedom.
generation on a dual AMD- | -- Henry Adams
Athlon! |
Juerd
> Would this actually be any better than the interface provided by
> Getopt::Long?
I'm not sure if it's *better*. I personally find it easier to read and
much easier to remember.
It would reduce the number of mini languages needed. Passing arguments
is more or less the same thing, whether you pass them to a program or a
subroutine, and this warrants more or less the same syntax - IMHO.
> I suspect that it's possible, and I also suspect that
> Getopt::Long can be written in a much friendlier manner for Perl 6
I'm sure it can: a macro would allow it to introduce lexicals instead of
a hash or globals, without counter-intuitive rw arguments.
> I do feel that command-line option parsing should not be built into the
> language though
Although I agree that it should not be part of the *language*, I do
think it's important enough to consider supplying a standard module for.
And since *practically*, standard modules do make the language, and
because consistency in the standard distribution makes things much
easier for everyone, I think now is not too early for this discussion.
> Let modules take care of it, then we'll never have to worry about
> pushing some built-in mechanism aside when we want to do something
> peculiar.
Agreed. Hence my question about being able to pass a signature as an
argument to a macro.
Juerd
> ...this seems a bit ugly to me.
The "signature" part, or the signature itself? Because you'll encounter
lists like this all over Perl 6 code anyway...
> What do you say about that:
> use Getopt::Auto;
> run &main;
> sub main (
> Rule $pattern,
> bool +$help :short("h"),
> ...
> ) {
> ...;
> }
I dislike "main" routines. Not only because they don't really make sense
to me (subs are for *re*use and structure, and code that by design runs
no more than once needs neither), but also because it means indenting
almost all your code. That may improve readability for that big program
that is structered in lots of subs anyway, but a big left margin does
not add anything to the readability of my simple 200 line script. And I
do not want blocks of more than 24 lines.
Of course, not-indenting is just not an option in curlies :)
I'm very glad "package|class Something;" is there, and could maybe like
your solution if there was also "sub main;", but I think that'd cause
strange readability issues.
> > Probably a macro can handle this, but does (will) Perl parse a
> > signature-like argument list and hand the macro something it can use,
> > or would this require source-filter like trickery?
> With Perl providing &sub.signature, there won't be any need to use
> macros or even source-filters :)
It provides .signature, but that says nothing about how useful this
attribute is. Is it a string? An object? A data structure?
Defining a sub just to retrieve its signature is wrong, IMnsHO. Subs
should be called.
Ingo Blechschmidt
Juerd wrote:
> Ingo Blechschmidt skribis 2005-02-05 17:19 (+0100):
>> ...this seems a bit ugly to me.
>
> The "signature" part, or the signature itself? Because you'll
> encounter lists like this all over Perl 6 code anyway...
I refered to the way the signature is specified, not the signature
itself. signature(...) looks like a function/sub call, while it isn't
one really.
> Defining a sub just to retrieve its signature is wrong, IMnsHO. Subs
> should be called.
That makes sense... Maybe it should be possible to create Signature
objects without creating a sub:
my $sig = Signature.new(Int $a, Str $b);
# and then
Getopt::Auto::parse_args $sig;
# use $a and $b
But this solution has got the same problems as your's -- how does the
parser detect that the argument list to Signature.new is not really an
argument list, but a signature?
--Ingo
--
Linux, the choice of a GNU | Failure is not an option. It comes bundled
generation on a dual AMD- | with your Microsoft product.
Athlon! |
Juerd
> signature(...) looks like a function/sub call, while it isn't one
> really.
Macros can do this to a language :)
macro signature is parsed /<Perl::Signature>;/ { ... }
> Maybe it should be possible to create Signature objects without
> creating a sub
That would answer the question what .signature returns too.
> my $sig = Signature.new(Int $a, Str $b);
I wonder if it's possible to have a macromethod. Macros must be parsed
at compile time, but what Signature::new is is not known until runtime,
is it?
> Getopt::Auto::parse_args $sig;
I like the idea.
Johan Vromans
[Quoting Juerd, on February 5 2005, 16:57, in "CLI signature?"]
> signature (
> Rule $pattern,
> bool +$help :short('h'),
> Int +$verbose :short('v'),
> Str *@files = <->
> );
The actual parsing still has to happen 'somewhere else', exactly like
it is now (in module Getopt::Long). So basically what you are trying
to design is a new way to tell the future Getopt::Ultimate[tm] what
options are expected/allowed.
There seems to be one advantage: the creation of the lexicals.
However, I thing this is a very minor advantage since usually these
lexicals need to be initialized first anyway.
This does not mean that I would not encourage designing a new syntax
for Getopt::Ultimate, a syntax that sticks closely to the native perl6
syntax.
-- Johan