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