Issue 3935: Use (pretty-print) for some IR props.

This patch uses (pretty-print) instead of (display) to show some IR properties, such as alists and vectors, that are really hard to read as it stands.

It increases the internals.pdf page-count from 638 to 651, but I believe the increase in legibility is worth it.

View some examples at:
http://code.google.com/p/lilypond/issues/detail?id=3935

[Mark Polesky, 2014-05-30 07:31:03]

Here's a new patch to tidy up the IR a little bit.  Please review.

- Mark

[dak, 2014-05-30 08:38:23]

https://codereview.appspot.com/95710044/diff/20001/scm/documentation-lib.scm
File scm/documentation-lib.scm (right):

https://codereview.appspot.com/95710044/diff/20001/scm/documentation-lib.scm#...
scm/documentation-lib.scm:112: (or (vector? val) ; vector is an ly-type
Comment makes no sense.

https://codereview.appspot.com/95710044/diff/20001/scm/documentation-lib.scm#...
scm/documentation-lib.scm:138: (lambda (port) (pretty-print val port #:display?
#t))
Wouldn't #:display? #t show a partial value of "string" as string without
quotes?  The examples in the issue report don't contain strings, so it's hard to
guess.

https://codereview.appspot.com/95710044/diff/20001/scm/documentation-lib.scm#...
scm/documentation-lib.scm:144: (string-regexp-substitute "\n " "\n  " str)))
pretty-print has a key #:per-line-prefix.  Would that be easier to use?

[Mark Polesky, 2014-05-30 09:11:57]

https://codereview.appspot.com/95710044/diff/20001/scm/documentation-lib.scm
File scm/documentation-lib.scm (right):

https://codereview.appspot.com/95710044/diff/20001/scm/documentation-lib.scm#...
scm/documentation-lib.scm:112: (or (vector? val) ; vector is an ly-type
On 2014/05/30 08:38:23, dak wrote:
> Comment makes no sense.

Would this pseudocode suffice?
  ; (ly-type? vector) => #t

The problem is that we need to make sure that most LilyPond internal "datatypes"
don't get displayed with @verbatim, since (pretty-print) doesn't work on them,
and they'll sail right past the page/screen margin.  I'm not sure what else to
call them; I'm referring to things that look like #<Mom > or #<simple-closure >
etc.

So this prevents that problem:
  (not (ly-type? val))

but causes another problem, namely that vectors would end up not getting
(pretty-print), which is the point after all.  Hence the conditional:
  (or (vector? val) ...

If the pseudocode I proposed above is still too abstruse, I welcome your
suggestions.

https://codereview.appspot.com/95710044/diff/20001/scm/documentation-lib.scm#...
scm/documentation-lib.scm:138: (lambda (port) (pretty-print val port #:display?
#t))
On 2014/05/30 08:38:23, dak wrote:
> Wouldn't #:display? #t show a partial value of "string" as string without
> quotes?  The examples in the issue report don't contain strings, so it's hard
to
> guess.

That's correct, no quotes, hence the added quotes a few lines below:
  (string-append "\"" str "\"")

An example is in the BarLine node, which after processing looks like this in
internals.texi:
  @item @code{glyph} (string):
  @code{"|"}

https://codereview.appspot.com/95710044/diff/20001/scm/documentation-lib.scm#...
scm/documentation-lib.scm:144: (string-regexp-substitute "\n " "\n  " str)))
On 2014/05/30 08:38:23, dak wrote:
> pretty-print has a key #:per-line-prefix.  Would that be easier to use?

Yes, thank you.

[Mark Polesky, 2014-05-30 09:41:51]

On 2014/05/30 09:11:57, Mark Polesky wrote:
>
https://codereview.appspot.com/95710044/diff/20001/scm/documentation-lib.scm#...
> scm/documentation-lib.scm:144: (string-regexp-substitute "\n " "\n  " str)))
> On 2014/05/30 08:38:23, dak wrote:
> > pretty-print has a key #:per-line-prefix.  Would that be easier to use?
> 
> Yes, thank you.

I spoke too soon.  I don't think #:per-line-prefix will work with my code
structure here.  The regex substitution is there for items prepended with a
single-quote, which might not end up using pretty-print.  Plus then we'd have to
remove the first space anyway (or replace it with the quote).  Unless you have
some clever way of making it work, I think I'll leave it as is.

[dak, 2014-05-30 10:45:36]

https://codereview.appspot.com/95710044/diff/20001/scm/documentation-lib.scm
File scm/documentation-lib.scm (right):

https://codereview.appspot.com/95710044/diff/20001/scm/documentation-lib.scm#...
scm/documentation-lib.scm:112: (or (vector? val) ; vector is an ly-type
On 2014/05/30 09:11:57, Mark Polesky wrote:
> On 2014/05/30 08:38:23, dak wrote:
> > Comment makes no sense.
> 
> Would this pseudocode suffice?
>   ; (ly-type? vector) => #t

That's rubbish.  None of the given types in ly-type? should trigger for a
vector.  And indeed it would appear that the definition of ly:music-list? is
broken and returns #t for anything that is not a list.

Instead of trying to work around obvious bugs when one finds them, they should
be reported and fixed.

I'll do so, but of course your patch will then depend on mine.  I'll try to
fast-track it.

https://codereview.appspot.com/95710044/diff/20001/scm/documentation-lib.scm#...
scm/documentation-lib.scm:138: (lambda (port) (pretty-print val port #:display?
#t))
On 2014/05/30 09:11:57, Mark Polesky wrote:
> On 2014/05/30 08:38:23, dak wrote:
> > Wouldn't #:display? #t show a partial value of "string" as string without
> > quotes?  The examples in the issue report don't contain strings, so it's
hard
> to
> > guess.
> 
> That's correct, no quotes, hence the added quotes a few lines below:
>   (string-append "\"" str "\"")

But you'd get ("x" y") to print as (x y) then, wouldn't you?
> An example is in the BarLine node, which after processing looks like this in
> internals.texi:
>   @item @code{glyph} (string):
>   @code{"|"}

[Mark Polesky, 2014-05-30 21:16:19]

On 2014/05/30 10:45:36, dak wrote:
>>   ; (ly-type? vector) => #t
> 
> That's rubbish.  None of the given types in ly-type? should trigger for a
> vector.  And indeed it would appear that the definition of ly:music-list? is
> broken and returns #t for anything that is not a list.

Your new commit still leaves this situation:
  (ly:music-list? '()) => #t

Is that intended?

> Instead of trying to work around obvious bugs when one finds them, they should
> be reported and fixed.

Well, in my defense, I didn't realize it was a bug, but thanks for the speedy
fix.

>> That's correct, no quotes, hence the added quotes a few lines below:
>>   (string-append "\"" str "\"")
> 
> But you'd get ("x" y") to print as (x y) then, wouldn't you?

Yes, I hadn't noticed that.  I had added `#:display #t' because without it, even
slightly long lines would get wrapped, even when (pretty-print) was given a
large value of #:width:

'(...
  (-1 . "accidentals.flatflat")
  (3/4
   .
   "accidentals.sharp.slashslash.stemstemstem")
  (1/4 . "accidentals.sharp.slashslash.stem")
  ...)

Is that a bug with (pretty-print #:width ...)?  Or am I misunderstanding
something?  Anyway, you are right; as it stands, my patch drops the
double-quotes with these strings:

'(...
  (-1 . accidentals.flatflat)
  (3/4 . accidentals.sharp.slashslash.stemstemstem)
  (1/4 . accidentals.sharp.slashslash.stem)
  ...)

What would you suggest?  Should I recurse into the prop-values to put quotes
around all those inner strings?  Or just accept the needless line-wrapping
(which is ugly to me)?  Do I need to file a guile bug?  For now, I'll remove the
`#:display' since it's not right.

I've uploaded a new patch that incorporates your new commit and other things,
including a more maintainable definition of `ly-type?'.  Please check it out.

Thanks!
- Mark

[dak, 2014-05-31 07:13:05]

On 2014/05/30 21:16:19, Mark Polesky wrote:
> On 2014/05/30 10:45:36, dak wrote:
> >>   ; (ly-type? vector) => #t
> > 
> > That's rubbish.  None of the given types in ly-type? should trigger for a
> > vector.  And indeed it would appear that the definition of ly:music-list? is
> > broken and returns #t for anything that is not a list.
> 
> Your new commit still leaves this situation:
>   (ly:music-list? '()) => #t
> 
> Is that intended?

Most definitely.  Since when is an empty list not a list?

[dak, 2014-05-31 07:13:17]

https://codereview.appspot.com/95710044/diff/150001/scm/lily-library.scm
File scm/lily-library.scm (right):

https://codereview.appspot.com/95710044/diff/150001/scm/lily-library.scm#newc...
scm/lily-library.scm:948: (define (ly-type? x)
Is this significantly different from
(define (ly-type? x)
  (any (lambda (p) ((car p) x)) lilypond-exported-predicates))

[Mark Polesky, 2014-05-31 20:17:33]

On 2014/05/31 07:13:17, dak wrote:
> https://codereview.appspot.com/95710044/diff/150001/scm/lily-library.scm
> File scm/lily-library.scm (right):
> 
>
https://codereview.appspot.com/95710044/diff/150001/scm/lily-library.scm#newc...
> scm/lily-library.scm:948: (define (ly-type? x)
> Is this significantly different from
> (define (ly-type? x)
>   (any (lambda (p) ((car p) x)) lilypond-exported-predicates))

No, but you didn't reply to the latest patch set there, where I had already
addressed that (although your way is still better).  By the way, I submitted a
bug report to guile on the (pretty-print #:width ...) question:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=17657

- Mark