lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Carl D. Sorensen
Subject: Re: type-check list in NR 6.1.1 (was: Time to retire Dynamic_engraver?)
Date: Mon, 29 Jun 2009 20:35:42 -0600



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

> 
> 
> Carl D. Sorensen wrote:
>> 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!
> 
> I don't know python, nor do I expect to start learning it in the
> near future... All of the type-checks are already listed in IR 4,
> so perhaps a more reasonable solution would be to add a note and
> a link to IR 4 within the text in NR 6.1.1

I agree that this is a more reasonable solution.

Carl





reply via email to

[Prev in Thread] Current Thread [Next in Thread]