This is the mail archive of the kawa@sourceware.org mailing list for the Kawa project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Questions about SRFI-38


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.




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]