Re: checking grob type

[David Kastrup]

David Nalesnik  writes:

> 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

[David Nalesnik]

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)

==> #

>
>> 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

[Paul]

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