On 4/30/05, Ronald J Kimball <[EMAIL PROTECTED]> wrote:
> On Sat, Apr 30, 2005 at 12:40:18PM +0200, demerphq wrote:
>
> > I think the -X modifier would change other aspects of the behaviour of
> > -e anyway. If something like the following becomes
> >
> > -Xe "#init" -p "#preprocess" -e "#postprocess"
> >
> > #init
> > while (<>) {
> > #preprocess
> > } continue {
> > print ...
> > }
> > #postprocess
> >
> > then obviously the rules for the endings of -e have to change anyway.
> > So automatically adding a semicolon and newline seems to me to make
> > sense. The whole idea for me is to better huffman encode command line
> > usage so making the semicolon optional fits in nicely. And I dont
> > think its that different in terms of expectation, I dont think the
> > style you showed is that common even if it is legal.
>
> Sorry, it's not obvious to me from this example why the rules for the
> endings have to change. Could you clarify?
>
> Perhaps someone would want to do this:
>
> -Xe "#init" -Xe "#init" -p "#preprocess" -p "#preprocess" -e "#postprocess"
> -e "#postprocess"
>
> It really only requires inserting a single semicolon, before the start of
> the while loop.
Ok, im not sure about your example. I was thinking that the -X would
change the behaviour of any following -e, -n or -p so having two
wouldnt matter.
Regarding the example code (not the multiple p's) for the example
above I think youll agree that it needs newlines or the entire code
ends up being a comment. (I suppose you may be lucky enough to use a
shell that allows for embedding newlines, I dont however.)
>
> Being able to break up a single statement across multiple -e's has the same
> advantages as being able to break up a single statement in a regular
> script; you can keep individual lines from getting too long.
Sure, and there doesnt seem to be too much reason not to insist that
that breakup occurs at statement boundaries.
I guess ones view on this will come down to how often one uses
multiple -e's for the purpose you describe. Since I never have my
personal position is that changing the semantics as Merijn described
with adding semicolon newline to each -e is beneficial.
Having said that Id hate to see this idea ignored just because of the
controversy over this issue.
>
> Personally, I'm not sure why someone would do this:
>
> -e 'my $x = 42' -e 'print $x'
>
> instead of
>
> -e 'my $x = 42; print $x'
>
> :)
Heh, I suppose not. But i can see a lot of people forgetting the semicolon in
-e "INIT()" -p"CONVERT()" -e "SHOWCOUNT"
and i think making the above DWIM is better huffman encoded than
breaking expectations from the previous -e behaviour, expectations
that I think are uncommon as I doubt that many people know off heart
the exact rules for how multiples -e's are joined together. I bet
most folks when they see multiple -e's on a command line recheck the
docs to see just what is going on.
Anyway I suppose this is the kind of thing that Larry and the
Pumpkings need to decide on. Personally I plan to look into putting
together an implementation sometime if someone doesnt beat me to it
and then let the powers that be make the call then.
Cheers,
Yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
