Accumulated Feedback on PRI #460

This page is a compilation of formal public feedback received so far. See Feedback for further information on this issue, how to discuss it, and how to provide feedback.

Date/Time: Sun Dec 18 00:13:30 CST 2022
Name: Manish Goregaokar
Report Type: Public Review Issue
Opt Subject: 460

I was recently implementing N0 and I have a couple largely (but not entirely) 
editorial suggestions:


1. BD16 variable naming

In BD16, there are two mutated variables: "a stack" and "a list of
elements". They're named according to their types rather than what they do
and they're somewhat confusable, I think it's worth giving them names
(probably `stack` or `open_brackets` and `result`)


2. BD16 bailout

In BD16 it says "stop processing BD16 for the remainder of the isolating run
sequence". Is this a degenerate case, or is behavior expected to be defined
here? It's unclear *where* this bails out to: BD16 is expected to produce a
result so you have to end up with something. A couple options are to return
an empty list, return the current list, or return the current list, but
sorted.

3. BD16 Empty stack case

"Declare a variable that holds a reference to the current stack element"
 does not handle the empty stack case (i.e. a string that starts with a
 closing bracket). It's kind of obvious from context (just go straight to
 step 5) but it probably could be spelled out explicitly.


4. N0 step c sos handling

The spec inconsistently refers to sos as a strong type in its own right as
well as a useful marker for the start-of-sequence position. I suspect this
could be disambiguated here by saying something like "until the first
strong type (L or R) is found. If none, use the value assigned to _sos_"

5. N0 step c complexity

Step c basically does the following:

 - (c) look for the first strong type s preceding the bracket, falling back to the value of sos if necessary
 - (c 1) If s != e, assign brackets to s
 - (c 2) Else (when s == e) assign brackets to e


(c 1) and (c 2) could be much more succinctly written as just "assign
brackets to s". I'll admit that being overly Gricean is probably not the
best when it comes to reading specifications, but the fact that this was
written out as two steps gave me pause and I had to reevaluate if I had
missed something important.

I think we should do one of:

 - Collapsing (c 1) and (c 2) to a single step that always assigns to the 
   strong type found, and add some non normative text about how this finds 
   established context but falls back to the embedding direction.
 - Add some non normative text saying "this has the effect of assigning 
   to the strong type found" or something so it's clear that the spec is 
   being verbose here.

The main value I see in keeping (c 1) separate is that it is an implicit
definition of the "established context" concept, which is not used in the
spec but might be generally useful.


Feedback above this line was reviewed during or prior to UTC #175 in April, 2023