Add `ly:undead?' to predicate list.

Add `ly:undead?' to predicate list.

[dak, 2014-06-01 15:10:59]

https://codereview.appspot.com/93660047/diff/1/scm/lily.scm
File scm/lily.scm (right):

https://codereview.appspot.com/93660047/diff/1/scm/lily.scm#newcode728
scm/lily.scm:728: (,ly:undead? . "undead object")
Probably more like an "undead container" as the undead thing (to survive between
sessions) is placed inside.

Won't be helpful information to somebody reading the manual which is the reason
I'm somewhat unenthusiastic including it.  On the other hand, there are lots of
predicates sharing that deficiency.

[Mark Polesky, 2014-06-01 18:09:12]

On 2014/06/01 15:10:59, dak wrote:
> scm/lily.scm:728: (,ly:undead? . "undead object")
> Probably more like an "undead container" as the undead thing (to survive
between
> sessions) is placed inside.
> 
> Won't be helpful information to somebody reading the manual which is the
reason
> I'm somewhat unenthusiastic including it.  On the other hand, there are lots
of
> predicates sharing that deficiency.

I never thought that the tiny predicate docstrings in
lily.scm were so much about documentation; we have 
docstrings in lily/*.cc for that (IR 4: "Scheme functions")
-- and those descriptions can be longer if needed for
clarity.
                                             
I thought that the docstrings in lily.scm are primarily
there for error reporting:
"wrong type for argument ~a.  Expecting ~a, found ~s"

They have the added benefit of a little clarification in the
Notation appendix "Predefined type predicates", but I
wouldn't want the error reporting to be too wordy.
        
In either case, if my pretty-print patch goes through, then
the lilypond-exported-predicates alist will also be used to
define (ly-type? x).  I don't know if an undead container
would ever be the default value of some grob property in the
future, but if it were, I wouldn't want it mistakenly
prepended with a single-quote in the IR, which is what could
happen with my other patch if we leave any predicates off of
the list.  
   
- Mark

[dak, 2014-06-01 18:35:58]

On 2014/06/01 18:09:12, Mark Polesky wrote:
> On 2014/06/01 15:10:59, dak wrote:
> > scm/lily.scm:728: (,ly:undead? . "undead object")
> > Probably more like an "undead container" as the undead thing (to survive
> between
> > sessions) is placed inside.
> > 
> > Won't be helpful information to somebody reading the manual which is the
> reason
> > I'm somewhat unenthusiastic including it.  On the other hand, there are lots
> of
> > predicates sharing that deficiency.
> 
> I never thought that the tiny predicate docstrings in
> lily.scm were so much about documentation; we have 
> docstrings in lily/*.cc for that (IR 4: "Scheme functions")
> -- and those descriptions can be longer if needed for
> clarity.
>                                              
> I thought that the docstrings in lily.scm are primarily
> there for error reporting:
> "wrong type for argument ~a.  Expecting ~a, found ~s"
> 
> They have the added benefit of a little clarification in the
> Notation appendix "Predefined type predicates", but I
> wouldn't want the error reporting to be too wordy.
>         
> In either case, if my pretty-print patch goes through, then
> the lilypond-exported-predicates alist will also be used to
> define (ly-type? x).  I don't know if an undead container
> would ever be the default value of some grob property in the
> future, but if it were, I wouldn't want it mistakenly
> prepended with a single-quote in the IR, which is what could
> happen with my other patch if we leave any predicates off of
> the list.  
>    
> - Mark

You are right about the error message stuff -- didn't think about that.  Undead
containers are only used in session management so we would not be seeing them in
properties.  At any rate, makes probably more sense to go ahead with this patch
rather than not.