Re: [lmi] InputSequence questions

[Greg Chicares]

On 2010-03-24 14:12Z, Vadim Zeitlin wrote:
> 
>  Anyhow, I don't know if LMI has a significant set of "power users" but IME

There are fairly few, but they are quite influential.

> some people do like to enter (even complicated) expressions directly
> instead of using such UI helpers.

Yes, some people will prefer that that. Among other advantages,
it's faster.

Yet the popup editor can be valuable even to them, because it
provides an alternative view of the same sequence. They might
enter a complicated expression and want handy confirmation of
its meaning, for instance.

This brings up an interesting question. Let's use "expression"
to mean the string in a single textcontrol, which today is the
only way the GUI represents sequences. Suppose a sequence is
entered through the new popup dialog. What should the resulting
expression be? This is important because the expression is
primary: it's what gets stored in the input file.

We have three /.*_representation/ functions that return a string:
    std::string element_by_element_representation() const;
    std::string mathematical_representation() const;
    std::string natural_language_representation() const;
For this testcase:
   90 issue age
   95 retirement age
  100 maturity age
  "7, retirement; 4"
they return
  7 7 7 7 7 4 4 4 4 4             | element by element [yick]
  7 [0, 5); 4 [5, maturity)       | mathematical
  7 from 0 to 5; 4 from 5 to 10;  | natural language
which are all unacceptable as documented here:
  // TODO ?? This loses the variable nature of retirement age e.g.;
  //   do we want enumerators e.g. for such tokens?
IOW, the retirement age can be changed independently, causing
the expression to be reparsed, yielding an altered meaning.

Well, I was making a tacit assumption that the popup editor
would edit an InputSequence object's internal representation,
and I guess that assumption must be discarded. Then exactly
what does the editor edit? An "expression" string? Even in
that case, we'll need a function to convert the contents of
the editor's controls to a single string, and none of the
functions above is adequate. At least we can try to describe
what the output might look like; possibilities include:

  7 from year 0 until retirement; 4 from year 5 until maturity;
Nice and readable, but it violates the grammar.

  7 [0, retirement); 4 [5, maturity)

If I were the only user, that would be okay.

  7, retirement; 4, maturity

That's probably best. It follows the
  [implicit beginning, explicit end)
paradigm that underlies much of our discussions.

> VS> * There's the problem with "until" that you mentioned yourself; it's not
> VS>   clear whether the interval is closed or open. I hope that this can be
> VS>   fixed by better wording alone (any ideas?).
> 
>  Might "up to" be more clear?

"Up to" is about as good as "until". To me, it has a slightly
more "directional" nuance. OTOH, "until" is the preposition
I think end users would more naturally fill in here:
  "Pay two thousand dollars a year ____ retirement"
when speaking. (They might instead say "through", but they
wouldn't mean "including", even though "through" generally
does mean "including".) "Up to" might also have a slightly
stronger connotation of non-inclusion to some native speakers;
I'm not really sure. Yet "until" seems more natural for points
in time, whereas "up to" is better for spatial relationships.

> VS>   [+Add] adds a new row to the end of editable rows, i.e. just above
> VS>   the last line, "until maturity".
> VS> 
> VS> * The ability to enter invalid data (overlapping intervals, incomplete
> VS>   sequences) is much reduced.
> 
>  It would be nice if a new row could be added automatically when you
> complete the previous one. IME (and I use such dialogs quite often in
> Mahogany myself) having to press "Add" when it's "obvious" that you need
> another row is often aggravating.

I present an idea like this in a later context, below.

> VS> * For completeness, here's the list of "When" phrases needed
[...]
> VS>   Note that "until maturity" is not needed, it's always the implicit
> VS>   last row.
> 
>  This is nice as it prevents the user from entering something invalid
> completely AFAICS. Do I understand correctly that the control starts in
> this state:
> 
>           Value  |  When
>     
>         [     ]     until maturity              
>                                                 [+Add]

I think so. Would "Value" be filled with a default value?
Practically speaking, this question would probably be answered
by other design decisions, with due regard to how the underlying
tabbed-dialog GUI already behaves.

> ? And that "until maturity is used as the default value for a new row, e.g.
> after modifying the first row and clicking "Add" (or, again, automatically,
> if possible) it'd become
> 
>           Value  |  When
>     
>         [ 1000]     until retirement            [-Remove]
>         [     ]     until maturity              
>                                                 [+Add]
> 
> ?

I'm trying to simulate this in my mind, and now I wonder whether
an "Add" button is truly needed. If I start with a single row:
  [  ?  ]     until maturity
and then fill it in this way:
  [ 1000]     until retirement
then as soon as the "until retirement" control loses focus, it's
evident that a new row must be added.

>  The only other important point is about the text control with the full
> sequence representation. Greg will know better, of course, but I think
> removing a way to enter/delete/copy/paste sequences directly would be a
> mistake.

Yes, I think we all agree on that point.