Re: checking grob type
David Nalesnikwrites: > On Fri, Mar 17, 2017 at 9:50 AM, Paul wrote: >> cc'ing lilypond-devel to move discussion there. >> >> On 03/17/2017 09:38 AM, David Nalesnik wrote: >> >>> You can get more info about public functions with the attached file. >>> I was planning on getting documentation into the manuals somehow, but >>> I got hung up with getting the parameters of curried functions. >> >> >> Hi David, Thanks for your work on this. Is there an easy way to just omit >> any curried functions in a first-pass at this? (I wonder what percentage >> are curried?) > > I never found it. > > The problem is that a parameter isn't shown: > > #(define ((curried arg) grob) '()) > #(display curried) > > ==> # What problem? `arg' _is_ the only parameter of the function `curried'. The function `curried', when called, returns a function taking a single parameter `grob'. But that's a detail of the description. Remember that the above currying is just short for (define (curried arg) (lambda (grob) '())) which is short for (define curried (lambda (arg) (lambda (grob) '( -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: checking grob type
On Fri, Mar 17, 2017 at 9:50 AM, Paulwrote: > cc'ing lilypond-devel to move discussion there. > > On 03/17/2017 09:38 AM, David Nalesnik wrote: > >> You can get more info about public functions with the attached file. >> I was planning on getting documentation into the manuals somehow, but >> I got hung up with getting the parameters of curried functions. > > > Hi David, Thanks for your work on this. Is there an easy way to just omit > any curried functions in a first-pass at this? (I wonder what percentage > are curried?) I never found it. The problem is that a parameter isn't shown: #(define ((curried arg) grob) '()) #(display curried) ==> # > >> Also, of course, publicizing a number of these probably won't do >> anybody a bit of good. > > > Maybe we could just have a list of functions to document publicly (or to not > document)? I suppose a metric could be usage in the code base, but I'd hate to get into a function-by-function discussion for the rest! > >> In lieu of actual documentation, I could add a Scheme function? > > > Seems like actual docs would be better in the long run, but I guess it > depends on how much they would take to implement. > Yes, real documentation would certainly be best. Shouldn't have implied "instead of": I meant in the meantime (and later, in addition) it would be nice to have a convenience function to return everything available. And it would need to be in C++ so it wouldn't need to be invoked to reveal itself :) David. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: checking grob type
cc'ing lilypond-devel to move discussion there. On 03/17/2017 09:38 AM, David Nalesnik wrote: You can get more info about public functions with the attached file. I was planning on getting documentation into the manuals somehow, but I got hung up with getting the parameters of curried functions. Hi David, Thanks for your work on this. Is there an easy way to just omit any curried functions in a first-pass at this? (I wonder what percentage are curried?) Also, of course, publicizing a number of these probably won't do anybody a bit of good. Maybe we could just have a list of functions to document publicly (or to not document)? In lieu of actual documentation, I could add a Scheme function? Seems like actual docs would be better in the long run, but I guess it depends on how much they would take to implement. Thanks again, -Paul ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel