Questions about SRFI-38

[Charles Turner]

On 12/05/2011 01:22, Per Bothner wrote:
 > OTOH you could argue this is a symptom of my penchent for 
micro-optimization

Heh, I'd appreciate your concerns when such issues crop up. I'm fresh 
out of the dreaded first-year university Java course, where development 
of efficiency intuition wasn't done at all. I suppose at some point I 
should check out the JVM specification from the library to get a feel 
for what's costly and what isn't. I've heard it's a pleasant read for a 
specification.

> On 05/11/2011 03:06 PM, Jamison Hope wrote:
>> Per, a comment near the top of gnu.text.PrettyWriter mentions that it's
>> based upon SBCL's pprint.lisp; how slight is that connection at this 
>> point?
>> Would reading the analogous Lisp source help Charles to understand 
>> what's
>> going on, or just confuse him more?
>
> I guess it might.  I don't remember how well-commented pprint.lisp is -
> probably not any better than PrettyWriter.java.  It also depends on 
> how fluent
> Charles is on reading Lisp as opposed to reading Java.

As I understand new parts of the pretty printer, I'm documenting my 
understanding heavily. Almost to the point where it might be a bit too 
much for a source file I fear. I could maybe create a separate document 
describing how the data structures are used (hopefully at some point 
this will be a possibility :-)) that's disjoint from the source code. A 
poor man's Literate Program.

I did investigate the pprint.lisp file from the sbcl source. The are no 
further comments in that file than Per's port, the port to Java is still 
very similar to the current pprint.lisp file in use with sbcl. The 
comments are mostly copied verbatim to Java. I did try understanding how 
the Lisp version worked, but unfortunately I couldn't follow it 
precisely enough to get my head around how the data structures are used 
(I am making some progress now with the Java version). I don't yet 
understand how CL's structures work, or how macro's work (I haven't done 
much with macro's in Scheme either I'm afraid). Basically, it was 
different enough to Scheme to take the air out of my sails. It's 
worrying how much trouble I'm having reading the Java version when Per 
just went through the Lisp version and seemingly translated it to Java 
without any trouble. :-P

>> Will the output of the first pass be saved somewhere for the entire
>> contents of the ReplDocument, or will the pretty printer just take
>> the document contents as previously displayed (i.e. one huge String),
>> remove all the line breaks, and insert new line breaks appropriate for
>> the new width?
> The problem is this ties us to Swing, which is rather old and not
> super-portable: We want to able to pretty-print when outputting to
> a terminal/console, to a webpage, to swt, and so on.

I haven't got this far yet. I'm still trying to figure out how to add 
the extra formatting tokens into the pretty printer's data structures. 
My proposals time line has changed a bit in lieu of SRFI-38 being my 
top-priority, so I hope to finish the integration and re-breaking 
feature by the midterm evaluation. Thanks for the information though.
>
>> I suppose my real question is: what information is there in the output
>> of the first pass which is lost by the time s-expressions (or whatever)
>> are written to the Document?
>
> The logical structure (grouping).  Also, the different kinds of spaces
> and newlines.
And hopefully at some point back references and position makers for 
print-circle notation.

 > Note "non-ragged paragraphs" is the goal of "justification".  We're not
 > attempting that - just "line-breaking".
 >
 > Also note that enforcing a minimal width isn't really possible unless
 > you also support something akin to "hyphenation".
 >>
 >> Ugh, even if Kawa supported such a thing, I think I would rather 
leave words
 >> intact. Just have the pretty printer adjust white space; if 
some-really-long-symbol
 >> extends beyond the desired width, either move the whole thing to the 
next
 >> line, or just make sure the next token is on the next line. (Of 
those two
 >> options, the second is probably simpler, as you might otherwise end up
 >> attempting to insert an infinite number of newlines before an 
81-character
 >> symbol...

Sorry, I realise I used completely the wrong terminology here, but at no 
point was I considering worrying about justifying Scheme :-). My point 
on the minimum window width (and by window I'm referring to a Swing 
pane) is to limit how small in the horizontal direction a user can 
resize to, but I suppose there's no knowing how long a symbol might be 
even in a miser printing. I'm no longer sure why DrRacket does this now. 
I suppose there's really no getting around the fact that in certain 
situations, the pretty printer won't be able to make the output pretty.

Side note: It seems that other Lisp system have dispatch tables for 
their pretty printers, which allows users to supply pretty printing 
information for custom structures. This seems like a nice feature, I 
wonder if it would be wanted in Kawa? I was perusing the Allegro 
documentation when I came across that idea.