bug-lilypond
[Top][All Lists]
Advanced

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

Re: New read/eval Scheme syntax inconsistent in handling existing code


From: Valentin Villenave
Subject: Re: New read/eval Scheme syntax inconsistent in handling existing code
Date: Sun, 4 Dec 2011 14:51:00 +0100

On Sun, Dec 4, 2011 at 1:20 PM, David Kastrup <address@hidden> wrote:
> I don't see why you would be using make-parameter at all, and why you
> would be creating a parameter of type _letter_ when you actually _need_
> a symbol.  Then write a macro around it that needs to do some partial
> evaluation using primitive-eval in order to evaluate one half of a
> construct in advance but not the other and you already have one added
> layer of diddling with evaluation order using macros...

Yes, I should get more acquainted with macro syntax, pseudo-quote, unquote etc.

> I protest in the name of geeks against this characterization.

Well, there **is** a documented trend of *not* doing things the
simpler way just "because we can" do it otherwise... Granted, that
doesn't say anything about elegance. Or maintainability :-)

> I don't get it.  It's like you want to put a nail into a wall, and miss
> with a hammer, so you take a shoe and complain to the producer of the
> hammer that the nails are really hard to drive using a shoe.

Sure.

>   You can use `$' with a Scheme expression anywhere you could use
> `\NAME' after having assigned the Scheme expression to a variable NAME.
> This replacement happens in the `Lexer', so Lilypond is not even aware
> of the difference.

That's promising. I've often wished I could do that.

>   One drawback, however, is that of timing.  If we had been using `$'
> instead of `#' for defining `newLa' in the above example, the Lexer
> would have evaluated the Scheme code right away in order to figure out
> the kind of the next token before Lilypond would have had a chance for
> executing the assignment.  Consequently, the Scheme definition would
> have failed because `traLaLa' would not yet have been defined.  As a
> rule, using `#' rather than `$' whenever it is allowed will cause fewer
> surprises.

That's what I'm gradually realising. Which makes the change less
"disruptive" that it seemed at first.

> Uhm, "avoid this kind of lock-in hack programming", not support it
> better.  The regtests are for features that should not stop working
> without good reason.  This includes ly:parser-include-string and
> eval-string.  But that does not imply that what you use them for is a
> good idea.

Never said that, never will.

> describeMusic =
> #(define-music-function (parser location description music) (string? 
> ly:music?)
>  (set! (ly:music-property music 'description) description)
>  music)
>
> hideNotes =
> \describeMusic "This hides notes"
> {
>  ...
> }

Interesting. I think this discussion took place when we started
documenting music-functions-init.ly, and were wondering how to
document property-init.ly in a similar way.

However, my point here was mostly about what I described in the linked
git commit:
(define (foo) bar) isn't evaluated quite exactly like (define foo
bar), only the former of which allows for docstrings. So I'm not sure
how to properly document (define foo bar), other than in comments.

Anyway. Attached is a patch that I'd suggest for the two oddities
you've been addressing earlier. (I'm not sure this deserves a rietveld
entry, and I'm a bit rusty wrt git-cl.)

Thoughts?

Cheers,
Valentin.

Attachment: 0001-Add-regtests-for-Scheme-strings-inclusion-evaluation.patch
Description: Text Data


reply via email to

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