<div dir="ltr"><div dir="ltr">Am Di., 26. Juli 2022 um 21:43 Uhr schrieb Brian Goetz <<a href="mailto:brian.goetz@oracle.com">brian.goetz@oracle.com</a>>:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

  
  <div>
    <br>
    <blockquote type="cite">
      <div><span style="font-size:11pt" lang="EN-US">To be more specific about the actual classes:<u></u><u></u></span>
        <p class="MsoNormal"><span style="font-size:11pt" lang="EN-US">Mapping accepts only fragments, because it must
            render as single line and for example in XML it renders as
            single element with attributes.</span></p>
      </div>
    </blockquote>
    <br>
    OK, so this unearths a previously unstated requirement: that we be
    able to turn certain maps into attributes, rather than embedded
    elements, when converting to XML.  Does this requirement correspond
    to anything in other formats?  Do we gain anything by dropping this,
    and formatting always to elements, and/or using other heuristics to
    determine when we can get away with this format optimization?  <br>
    <br>
    In general, I'd like to unearth more of this sort of requirements. 
    Looking at the current hierarchy, I can't help but feel we've not
    yet "hit bottom"; it doesn't feel factored into separate concerns
    yet.  But I'm optimistic we can get there.  <br>
    <br>
    Here's a naive decomposition, which looks a lot like the JSON spec
    if you squint: <br>
    <br>
        Value = SimpleValue(ConstantDesc) | ListValue(List<Value>)
    | MapValue(Map<String, Value>)<br>
    <br>
    Converting to this form is useful separate from formatting -- it
    provides a basis for query/traversal using simple string keys.  But
    it's not good enough for getting good formatting yet, because you
    need formatting hints to determine how to lay out / indent, right? 
    So let's consider how we might add these in as hints, that are more
    transparent. [...]</div></blockquote><div><br></div><div>If it's a question of prettyprinting where indentation and line breaks<br>are added automatically, then there is the option to layer all<br>whitespace manipulation on top of the printed data.  I use this to<br>prettyprint Clojure data structures, which closely resemble your<br>`Value` production above.<br><br>The key idea goes back to the 1980 paper "Prettyprinting" by Oppen and<br>boils down to a single decision how to insert line breaks.  Given a<br>delimited group<br><br>  <start><elem><line><elem><line>...<elem><end><br><br>where <start> and <end> are usually literals, <elem> arbitrary data,<br>and <line> is eventually a single whitespace or a line break.<br>Determine the width of the group assuming that all <line> (both in the<br>group itself and as part of elements) are of width one.  If the<br>group's width fits within the page width remaining, then print each<br><line> as a single whitespace, otherwise the group's <line> separators<br>as line breaks.<br><br>The "one line width" flows naturally from the leaves to the root.<br>Combine this with indentation tracking, and the result is a simple but<br>capable prettyprinter targeting a given page width as a soft target.<br>Building on this, I print colorized side-by-side diffs of lists of classfiles.<br><br>-- mva<br></div><div><br></div></div></div>