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 20:51:53 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

David Kastrup <address@hidden> writes:

> Dan Eble <address@hidden> writes:
>
>> On May 27, 2015, at 05:45 , David Kastrup <address@hidden> wrote:
>>> 
>>> +(define %parser (make-fluid))
>>> +(define %location (make-fluid))
>>
>>> +(define-public (*parser*) (fluid-ref %parser))
>>> +(define-public (*location*) (fluid-ref %location))
>>
>> Are the decorations on these names ad-hoc or are you following a
>> convention?  (I’m asking for my own edification.)
>
> We are using them for parameters/accessors elsewhere:
>
> address@hidden:/usr/local/tmp/lilypond$ git grep '(\*[a-z]\+\*)' origin
> origin:Documentation/misc/ChangeLog-2.10: (*parser*) lookup if
> (*parser*) != #f.
> origin:scm/define-music-display-methods.scm: (if force-line-break (+ 2
> (*indent*)) 1)
> origin:scm/define-music-display-methods.scm: (parameterize ((*indent*
> (+ 2 (*indent*))))
> origin:scm/define-music-display-methods.scm: (if force-line-break
> (*indent*) 1))))
> origin:scm/define-music-display-methods.scm: (parameterize ((*indent*
> (+ 3 (*indent*))))
> origin:scm/define-music-display-methods.scm: (parameterize ((*indent*
> (+ (*indent*) 2)))
> origin:scm/define-music-display-methods.scm: (*indent*)
> origin:scm/define-music-display-methods.scm:                        
> (*indent*)))
> origin:scm/display-lily.scm:  (format #f "~%~v_" (max 0 (1- (*indent*)))))
> origin:scm/song.scm: #:unfinished (and (not (*syllabify*))
> (find-child-named music 'HyphenEvent))
>
> Doing a bit of web searching, I haven't been able to find use of this
> convention outside of LilyPond.

Oh, and regarding the %parser and %location names: GUILE itself uses
names like that for several fluids.

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.

-- 
David Kastrup



reply via email to

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