jshell tool: what should the interactive output look like?

[Brian Goetz]

Here are some (subjective) goals for the UX:
  - Output should not be too verbose (current default is too verbose).
  - Result of evaluating an expression should be placed 
front-and-center; this is the essence of REPL.
  - Results from the user program and results from the REPL application 
should be distinguishable.

So, for example:

0: |Stream<String>$11 : java.util.stream.ReferencePipeline$Head at 51016012
    |  Added temporary variable $11

seems to violate at least one of these goals -- the result of my 
evaluation and the diagnostic about side-effects on the REPL state are 
both expressed with the same formatting metaphor.  (I also think that 
the variable and type information is "in the way" of the more important 
information -- the result.)

I propose we start with a data model, based on the taxonomy from my 
6/26/2015 message; define an intermediate data model that describes all 
the possible kinds of output, and then define formatting rules from 
that.  Reproduced below:

> 1.  Expression results.  (If the input was an expression, we probably always want to print this; if its not an expression, there's nothing to print.)
>
> 2.  Text sent to System.{out,err}.
>
> 3.  Diagnostics either from compiling the input or from executing a REPL command.
>
> 4.  Runtime exceptions produced during execution.
>
> 5.  Side-effects on the REPL state (vars/methods/classes declared/invalidated/dropped/changed state.)
>
> For (5), there are sub-categories:
>  a) a new temporary variable was created
>  b) a new variable was created (var declaration)
>  c) a new method/class was created
>  d) a variable/class/method was invalidated
>  e) a variable changed its value (assignment to existing var)




On 1/24/2016 10:36 PM, Robert Field wrote:
> Below I list interesting snippet and command input, with the current
> default ('d:') and concise ('c:') feedback, Brian's proposal ('b:) and
> some other (numbered) alternatives
>
> COMPLEX EXPRESSION
>
> -> Math.sqrt(Math.PI)
>
> d: |  Expression value is: 1.7724538509055159
>     |    assigned to temporary variable $3 of type double
>
> c: |  $3 : 1.7724538509055159
>
> b:  => 1.7724538509055159
>     (assigned to temporary $3 of type double)
>
> 0: |  double $3 : 1.7724538509055159
>     |  Added temporary variable $3
>
> 1: |  double $3 : 1.7724538509055159
>
>
> -> Arrays.asList("Hello", "World!", "How", "Are", "You").stream()  //
> another example
>
> d: |  Expression value is: java.util.stream.ReferencePipeline$Head at 5f5a92bb
>     |    assigned to temporary variable $11of type Stream<String>
>
> c: |  $11 : java.util.stream.ReferencePipeline$Head at 51016012
>
> b:  => java.util.stream.ReferencePipeline$Head at 51016012
>     (assigned to temporary $11 of type Stream<String>)
>
> 0: |Stream<String>$11 : java.util.stream.ReferencePipeline$Head at 51016012
>     |  Added temporary variable $11
>
> 1: |Stream<String>$11 : java.util.stream.ReferencePipeline$Head at 51016012
>
>
> VAR CREATE (initial value)
>
> -> double x = Math.sqrt(Math.PI)
>
> d: |  Added variable x of type double with initial value 1.7724538509055159
>
> c: |  x : 1.7724538509055159
>
> b: (declared variable x of type double)
>
> 0: | doublex : 1.7724538509055159
>     |  Added variable x
>
> 1: | doublex : 1.7724538509055159
>
> 4:  => 1.7724538509055159
> (declared variable x of type double)
>
>
> VAR CREATE (no initial value)
>
> -> double x
>
> d: |  Added variable x of type double
>
> c: |  (NO OUTPUT)
>
> b: (declared variable x of type double)
>
> 0:|  Added variable x
>
> 1: | doublex : 0.0
>
>
>
> ASSIGNMENT
>
> -> k = Math.getExponent(Math.random())
>
> d: |  Variable k has been assigned the value -2
>
> c: |  k : -2
>
> b: (NO OUTPUT)
>
> 1: |  int k : -2
>
> 4:  => -2
>
>
> VAR QUERY
>
> -> x
>
> d: |  Variable x of type double has value 1.7724538509055159
>
> c: |  x : 1.7724538509055159
>
> b: => 1.7724538509055159
>
> 1: | doublex : 1.7724538509055159
>
>
> METHOD DECL (class, interface, enum, too similarto show)
>
> -> void m() { }
>
> d: |  Added method m()
>
> c: (NO OUTPUT)
>
> b: (defined method m())
>
>
> DROP
>
> -> /drop m
>
> d: (NO OUTPUT)
>
> c: (NO OUTPUT)
>
> b: (dropped method m())
>
> 1: |  Dropped method m()
>
>
> MISC COMMANDS
>
> Currently display in default but not concise.
>
> | Editor set to: %s
> | Path %s added to classpath
> | Feedback mode: %s
> |  Prompt will (not) display.
>
> -----
>
> My vote for new default is '1' (where it is shown, and current default
> otherwise).  This is mostly like concise feedback but adding the type
> which is often important information. A variation would be to use '='
> instead of colon, but since then it would be valid code (and in simple
> cases will be the same as the input) I think that would be confusing.
>
> I think it is important to set the feedback off from the user's output.
> Brian proposes parenthesis, which make it clear they are parenthetical
> and presumably not shown in concise feedback, but parenthesis are likely
> to occur in the user output and is very likely to occur in the feedback.
> The pipe symbol is currently used (to quote-off) the feedback -- I think
> it works well -- is visually clean.
>
> I like the clean division of what goes away in a concise mode. Option
> (0) shows one choice for this (which also is more symmetric with
> methods, classes,...).  Expressions are probably the most important
> snippets to have crisp output, and unfortunately, this adds pure noise
> in this case as soon as the user understands that expressions create
> temporaries which are named with a dollar sign.
>
> "Added" vs "defined": I like "defined" better, but "Added" is used to
> differentiate it from "Modified" and "Replaced".   We could use
> "Defined", "Modified definition", and "Replaced definition".
>
> I'd like to hear everyone's opinion.  Including what options I did not
> list.
>
>
> Thanks,
> Robert
>