lilypond-devel
[Top][All Lists]
Advanced

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

Re: [PATCH 1/5] Remove parser/location global variable setup


From: David Kastrup
Subject: Re: [PATCH 1/5] Remove parser/location global variable setup
Date: Sat, 30 May 2015 21:37:07 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

Carl Sorensen <address@hidden> writes:

> On 5/30/15 12:51 PM, "David Kastrup" <address@hidden> wrote:
>
>>David Kastrup <address@hidden> writes:
>>
>>At any rate: huh.  I propose getting rid of a 10-year old syntactic
>>artifact and the only response are naming convention enquiries.  I mean:
>>good to know that there are still developers alive.
>>
>>I still think it may have the potential of issue 2883 where its general
>>availability lagged behind people becoming used to it.
>
> This is far enough over my head that I don't feel qualified to comment on
> it.

Well, the diff of the convert-ly effects is pretty thorough.  The manual
reads like

2.3.1 Music function definitions
--------------------------------

The general form for defining music functions is:

     function =
     #(define-music-function
          (ARG1 ARG2 …)
          (TYPE1? TYPE2? …)
        BODY)

quite in analogy to *note Scheme function definitions::.  More often
than not, BODY will be a *note LilyPond code block: LilyPond code
blocks.

...


2.2.1 Scheme function definitions
---------------------------------

The general form for defining scheme functions is:

     function =
     #(define-scheme-function
          (ARG1 ARG2 …)
          (TYPE1? TYPE2? …)
        BODY)

where

‘ARGN’                   Nth argument
                         
‘TYPEN?’                 a Scheme _type predicate_ for which ‘ARGN’
                         must return ‘#t’.  There is also a special
                         form ‘(_predicate?_ _default_)’ for specifying
                         optional arguments.  If the actual argument is
                         missing when the function is being called, the
                         default value is substituted instead.  Default
                         values are evaluated at definition time
                         (including LilyPond code blocks!), so if you
                         need a default calculated at runtime, instead
                         write a special value you can easily
                         recognize.  If you write the predicate in
                         parentheses but don’t follow it with a default
                         value, ‘#f’ is used as the default.  Default
                         values are not verified with _predicate?_  at
                         either definition or run time: it is your
                         responsibility to deal with the values you
                         specify.  Default values that happen to be
                         music expressions are copied while setting
                         ‘origin’ to the current input location.
                         
‘BODY’                   A sequence of Scheme forms evaluated in order,
                         the last one being used as the return value of
                         the scheme function.  It may contain LilyPond
                         code blocks enclosed in hashed braces
                         ( ‘#{…#}’ ), like described in *note LilyPond
                         code blocks::.  Within LilyPond code blocks,
                         use ‘#’ to reference function arguments (eg.,
                         ‘#arg1’) or to start an inline Scheme
                         expression containing function arguments (eg.,
                         ‘#(cons arg1 arg2)’).  Where normal Scheme
                         expressions using ‘#’ don’t do the trick, you
                         might need to revert to immediate Scheme
                         expressions using ‘$’, for example as
                         ‘$music’.
                         
                         If your function returns a music expression,
                         it is given a useful value of ‘origin’.

[...]

> Based on what I saw, it looks very useful.

No, it isn't really any more useful.  Just less black magic to
remember.  More convenient than useful.

> I love the idea of getting rid of arbitrary variables that the user
> cannot change (parser and location).
>
> I trust you to do the right thing.  You've demonstrated that you can
> and will.
>
> So I guess this means LGTM, but I suppose that is not worth much
> coming from me.

Probably not since this change is intended to benefit inexperienced
and/or clueless users most.  So there are probably not many of the
target clientele reading the developer list anyway.

Maybe if I want to go fishing for compliments, I'd probably better do it
on the user list.

-- 
David Kastrup



reply via email to

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