Re: type-check list in NR 6.1.1 (was: Time to retire Dynamic_engraver?)

[Carl D. Sorensen]

On 6/29/09 12:50 PM, "Mark Polesky" <address@hidden> wrote:

> 
> 
> Neil Puttock wrote:
>>> 1) I'd like to have all of type-p-name-alist listed in NR 6.1.1
>>>   Overview of music functions (programming-interface.itely, line
>>>   76). Any objections?
>> 
>> None here, as long as you automate it (perhaps use a markup command to
>> extract and prettify the list entries).
>> 
>> BTW, there are a few LilyPond-specific predicates missing, since
>> they're not currently used for any properties (e.g. ly:skyline?).
> 
> Neil,
> I regex-grepped ly:[-\x21-\x7E]+\?
> 
> then copied the output to a file,
> then made the following search-and-replaces:
> "\""  --> " "
> "ly:" --> " ly:"
> "?"   --> "? "
> "\?"  --> "?"
> 
> then stored the whole thing as a string and
> then did this:
> 
> ________________________________
> 
> 
> (use-modules (srfi sfri-1))
> 
> (define (delete-adjacent-duplicates lst)
>   (fold-right
>     (lambda (elem ret)
>       (if (equal? elem (first ret))
>           ret
>           (cons elem ret)))
>     (list (last lst))
>     lst))
> 
> (define (display-ly-predicates str)
>   (for-each
>    (lambda (x) (format #t "~a\n" x))
>    (delete-adjacent-duplicates
>     (map string->symbol
>      (filter (lambda (x)
>               (and
>                (string=? "?" (string-take-right x 1))
>                (< 2 (string-length x))
>                (string=? "ly:" (string-take x 3))))
>       (sort
>        (string-tokenize str)
>        ;; this is my own sort; string-ci<? also works.
>        ly:string-ci<?))))))
>  
> (display-ly-predicates my-string)
> 
> ________________________________
> 
> 
> Then I grouped the meaningful portion* of the output into 4
> categories:
>   NULLARY
>   UNARY TYPE-CHECKS
>   UNARY STATUS CHECKS
>   BINARY
>   DEPRECATED
> 
> *(I removed "ly:class-bla::foo-bar[?")
> 
> So for NR 6.1.1, we want UNARY TYPE-CHECKS.
> Here are the categorized lists:
> 
> NULLARY (1)
> ly:command-line-verbose?
> 
> UNARY TYPE-CHECKS (36)
> ly:box?
> ly:context?
> ly:dimension?
> ly:dir?
> ly:duration?
> ly:font-metric?
> ly:grob?
> ly:grob-array?
> ly:input-location?
> ly:item?
> ly:iterator?
> ly:lily-lexer?
> ly:lily-parser?
> ly:moment?
> ly:music?
> ly:music-function?
> ly:music-list?
> ly:music-output?
> ly:otf-font?
> ly:output-def?
> ly:page-marker?
> ly:pango-font?
> ly:paper-book?
> ly:paper-system?
> ly:pitch?
> ly:prob?
> ly:score?
> ly:simple-closure?
> ly:skyline?
> ly:skyline-pair?
> ly:source-file?
> ly:spanner?
> ly:stencil?
> ly:stream-event?
> ly:translator?
> ly:translator-group?
> 
> UNARY STATUS CHECKS (3)
> ly:parser-has-error?
> ly:score-error?
> ly:stencil-empty?
> 
> BINARY (8)
> ly:duration<?
> ly:grob-pq<?
> ly:in-event-class?
> ly:moment<?
> ly:pitch<?
> ly:position-on-line?
> ly:prob-property?
> ly:prob-type?
> 
> DEPRECATED (2)
> ly:paper-def?
> ly:verbose?
> 
> ________________________________
> 
> 
> questions:
> 0) I assume that's all of them?

I would assume so, but I don't know any way to thoroughly check that.

> 1) Did I make any mistakes?

None that I can see.

> 2) Can all of the TYPE-CHECKSbe meaningfully passed to a
>    music-function?

Well, yes and no.  Any of the TYPE-CHECKs can be passed to a music function,
but many of them aren't available from the input stream and music functions
work on the input stream, as far as I can tell.

So it's unlikely that there is any easy way to get a translator group as an
argument to a music function.

> 3) when you write this:
>> None here, as long as you automate it (perhaps use a markup
>> command to extract and prettify the list entries).
>    what qualifies as automating? Can I just copy the UNARY
>    TYPE-CHECKS to a list and work with that? Is that what you
>    meant? 

I can't speak for Neil, but I can speak for the documentation rules.

No hand-made lists can be added to the documentation, because they are
impossible to maintain.  All of the lists in the documentation need to be
completely automatically generated, such that when make doc is run, the
lists will be recreated.

>    Or did you want the UNARY TYPE-CHECKS list to somehow
>    be automated, to account for future additions to the list?
>    Offhand, I can't imagine a sensible way of doing that.

Well it might require some serious hacking.  But it ought to be possible to
create a python script to do your regex search (and maybe even eliminate the
duplicates).  This could be stored as a .scm file that defines a list of
ly:predicates.

Then, there could be a .ly file that would:

load the list of predicates (using Scheme)
for each of the predicates, see what the current definition is to obtain the
argument count.
Build an alist of (arg-count . predicate-symbol->string)
Sort the resulting alist.
Display the sorted alist in appropriate form for the manual.

This .ly file could then be run through a perl script to send the console
output to a text file, and strip the lilypond-output part of the text file,
leaving only a text file that could be included in the documentation.  This
file would be classified, not by functionality, but by number of arguments.

Alternatively, a new .scm file (similar to define-grobs.scm or
define-grob-interfaces.scm) could be created:  define-predicates.scm.  This
would define an alist of predicate types and predicates, and any predicates
that were found by your routine and were not included in the
define-predicates alist would be classified as "Other" or "Unknown".

BTW, the full list of predicate types shouldn't go in NR 6.1.1, but instead
in an appendix to the NR.

I think this is a great project, and hope that you'll be able to complete
it!


HTH,

Carl