Bug 24343 – Add support to jsc for -n and -p switches.

• Status: RESOLVED
• Resolution: WONTFIX
• Component: JavaScriptCore

[Gavin Barraclough]

These switches should operate in the same fashion as their perly counterparts, looping over STDIN, and repeatedly evaluating the script provided as an argument with the symbol $_ bound to the current line of input.  In the case of -p the result of the eval'ing the script be printed to STDOUT.

[Gavin Barraclough]

Created attachment 28257 [details]
Teh patch!

[Oliver Hunt]

Comment on attachment 28257 [details]
Teh patch!

mark said -p was a bad idea

[Mark Rowe (bdash)]

Pulling magic variables names like $_ from Perl does not seem like a great idea.  -p seems redundant given you can just wrap your expression inside print(..) and use -n.

[Gavin Barraclough]

An example of how I'm wanting to use this may be helpful:

        0x1002a72c1:	pop    %rcx
        0x1002a72c2:	mov    %rcx,-0x28(%r13)
        0x1002a72c6:	mov    $0x10000000a,%r11

and reformatting back into a slightly different form:

            "pop    %rcx" "\n"
            "mov    %rcx,-0x28(%r13)" "\n"
            "mov    $0x10000000a,%r11" "\n"

With this patch I can trivially do this from the command line, like this:

         pbpaste | ./WebKitBuild/Release/jsc -p '"    \"" + /\w+:\s*(.*)/.exec($_)[1] + "\" \"\\n\""'

[Mark Rowe (bdash)]

Sure, and without -p you can trivially wrap it in print().  It's not a particularly compelling argument for adding an extra argument.

[Gavin Barraclough]

I respectfully disagree with your argument about -p - saying it is redundant is entirely missing the point.  -p is redundant, since you can just use -n and print the output.  -n is redundant since you can just use -e, and write a quick loop calling readline.  -e is also redundant, since you can simple can your script out to a file in /tmp and pass the filename to jsc.  They're not useful because they're letting you do something that wasn't already possible, they're useful because they provide an extremely convenient way of doing something that people commonly want to do.

I'll cite  to reference points as to why I believe there is a strong demand for -p:
    [1] Perl has it – I don't believe it would be there if it wasn't useful, and it is my experience that perl programmers frequently make us of this functionality.
    [2] The only person I know trying to use jsc as a scripting tool right now is me, and I'd find this really useful.  As such I'm going to claim there is a 100% demand from the user base for this feature! :-P

I do agree with you about $_, I just couldn't com up with anything better, and at least people know what that is – there will be some familiarity.  (Though that said, it is a bit unfortunate overloading a known special identifier with a slightly different meaning, since $_ won't automagically update within your code, as it will in perl).

Any suggestions for a better identifier name? – line? LINE? _line_? $line?  The way it is implemented, I could also easy make the currently line be passed as 'this'... ;-)

[Gavin Barraclough]

[typo:] *two reference points.  bah.

[Gavin Barraclough]

[double typo:] *come up with.  double bah.

[Mark Rowe (bdash)]

The difference in convenience between -e and writing to a temporary file is *huge*.  This isn't the case for typing "print".

[Gavin Barraclough]

(In reply to comment #9)
> The difference in convenience between -e and writing to a temporary file is
> *huge*.  This isn't the case for typing "print".

This point is clearly entirely subjective. I respect that your opinion is absolutely valid, but looking at the perl community as a test case I would argue that you are in the minority here in holding it.

The amount of additional code required to implement -p is minimal, so I don't see that as a reason to exclude the switch.  Is your concern about adding too many switches to the jsc interface? - if so, I'd suggest we should consider skipping -n in favour of -p, since I believe -p will likely more useful.

[Mark Rowe (bdash)]

Appealing to  the perl community's sense of design for guidance on what to do in JavaScriptCore doesn't seem sensible.  I also don't buy the argument that because you're the only one currently using jsc in this manner that we should add arbitrary flags to jsc to please you.  You're welcome to build your own tool using the JSC API if you'd like to do crazy shell tricks (jperl?).  We don't have to jam them all in to jsc.

Further, adding -p without -n doesn't seem anywhere near as useful given that you can easily emulate -p with -n, but the reverse is more complicated.

[Gavin Barraclough]

(In reply to comment #11)
> Appealing to  the perl community's sense of design for guidance on what to do
> in JavaScriptCore doesn't seem sensible.  I also don't buy the argument that
> because you're the only one currently using jsc in this manner that we should
> add arbitrary flags to jsc to please you.  You're welcome to build your own
> tool using the JSC API if you'd like to do crazy shell tricks (jperl?).  We
> don't have to jam them all in to jsc.

I'm assuming you're deliberately being obtuse here, but no, I do not want to turn jsc into perl.  That said, this may be getting to the crux of our difference of opinion.  What do you see jsc as being for?  I'm hoping that jsc will grow into a useful scripting shell, which I believe will mean adding a few more features, like support for -e, -n, -p (note: I say 'like', I'm not claiming that we must have exactly these specific features for the shell to be useful).  Do you share this vision? - do you, for example, believe we should retain jsc as a shell primarily or only for the sake of running benchmarks?  If so, that is also a reasonable standpoint, and if we're going to do so then I'd agree with you that it would be useful to fork at this point, and have a second shell for more general scripting uses.

> Further, adding -p without -n doesn't seem anywhere near as useful given that
> you can easily emulate -p with -n, but the reverse is more complicated.

I'll reiterate that I think you are missing the point here.  If we only had -n, and the vast majority of the uses were wrapping the code in a print() (which I'm proposing may likely be the case), then it would be more efficient to have -p in its place.  In the minority of cases that the user wanted -n behaviour, they could use -e, and write the loop explicitly.  The fact that -n can emulate -p is not, in and of itself, a sufficient argument again inclusion of -p support.

Closing the bug whilst we're in the middle of a discussion of what form the change should be submitted in is frankly a little rude.  So far as I am aware we are simply discussing whether -p will be included, and I am under the impression that you agreed or accepted that -n was useful to add.  As such the state "won't fix" is incorrect (on the understanding that, pending the outcome of this discussion, I may remove '-p' from the description).  Please have courtesy to not close this again without discussing this with me first.

[Gavin Barraclough]

Okay Mark, any suggestions as to how we can go forward in agreement on this?  We both seem fairly firmly entrenched in our opinions.  I clearly haven't made a case to your satisfaction that this is beneficial, and you haven't convinced me that it is not.

Do you want to try clarify your concern any further with the inclusion of the -p switch in this patch?  Is it purely the perceived redundancy over the -n switch, and if so what specific harm do you see arising from this?  Is this a statement of a general preference for minimalism in the interface design, since you don't perceive there to be a benefit here, or is there something else you are specifically concerned about?

Or perhaps can we could try to come to some kind of compromise here instead?

The best suggestion for a compromise I can come up with is to perhaps consider a trial period?  We could add the feature with a firm commitment to review this in a fixed period of time, and to remove the switch at that point if it has not proven to be beneficial.  Hopefully this would give us some objective way to assess whether or not the switch has or could prove useful.

What are your thoughts on this suggestion?  Do you have any other ideas as to how we could reach a compromise we're both happy with here?

[Mark Rowe (bdash)]

 I'm not the only one that feels that this is not compelling functionality to add to jsc, given the primary purpose that it currently serves as a tool for testing JavaScriptCore.  I'm also not particularly interested in debating this.

[Gavin Barraclough]

Killing this; since I haven't used this in the last few years, I guess it wasn't that useful after all. :-)