On Sun, Dec 4, 2011 at 9:38 AM, David Kastrup <d...@gnu.org> wrote: > Apart from the rest of this ugly contraption,
You mean, uglier than using eval-string? I'm not sure what a less ugly way of doing that would look like. (Perhaps using hooks, but I have yet to master that.) > there is no reason > whatsoever why you are calling the _internals_ of making music functions > here instead of define-music-function itself. Absolutely none whatsoever. That was pure uncalled-for geekness from me (at the time, it also allowed me to learn more about the music-function internals). > Yes, I changed the internals because the internals needed more > information. But the user API remained identical, and I don't > understand why you don't use it. It's not like things get simpler when > you sidestep the documented API. They sure don't. (And I'm not complaining about that.) > This is ridiculous. Now you use the API. What makes you think > eval-string is necessary for using define-music-function? It isn't. defmacro certainly is a cleaner way to do it. That was just to show you an example of a case where eval-string was useful to me, re. our previous conversation. > $ takes a look at the type of the enclosed > expression and creates a token of the appropriate type in the input > stream. The type of the enclosed expression is *unspecified* so nothing > gets inserted into the input stream by the lexer and the parser is > completely unimpressed. OK. > Or put differently: the principal difference of # and $ is that $ > interprets the resulting expression and generates a token corresponding > to its type (or in this particular case, none at all). The premature > evaluation is a _side-effect_ of this difference. Thanks. I think I get it now. I was confused between the _LilyPond_ parser and the guile interpreter; when you said $(...) expressions were evaluated instantly I misunderstood and thought you were referring to the former. > If would appear that you consider the side-effect more important than > the main effect, and have for that reason decided to be smarter than > convert-ly and replace # everywhere with $. Well, you have to take into account where we come from: I'm not used to convert-ly being smarter than me :-) > Yes, if you write code relying on temporary insanities of Lilypond's > implementation and on meddling with internals, my work on Lilypond will > be disruptive to your document base. Which is exactly what's happening here. And again: not once have I been advocating that your work should be reverted back and thrown away. > Looks like we have lots of fun ahead. Do me a favor and from time to > time add material to Lilypond's documentation that would have helped you > avoid this kind of lock-in hack programming. Once you know how to avoid > it. That's the whole point of our conversation so far: I've already identified two eligible regtests (the ly:parser-include-string thing and the eval-string thing). And of course I have no other intention but to document everything I can. On a totally unrelated note (since we're talking about Scheme evaluation), if I may quote a question that I discussed privately with Neil last year: On Mon, Dec 6, 2010 at 6:31 PM, Neil Puttock <n.putt...@gmail.com> wrote: > This caught my eye: > http://git.savannah.gnu.org/cgit/opus-libre.git/commit/?id=f149327afc41d869e34c29cf32b415254542ca9e > > I don't think there's any way around this unless you make all the > defines procedures, though in some cases this might be a good thing > since some of them are going to be evaluated immediately the file is > loaded. For example, in the following code, `foo' isn't a procedure: > it's called immediately Guile sees it. > > (define bar '(hello)) > (define foo (if (pair? bar) (display "Hello World!"))) > > This reminds me of the problem we have with identifiers: how can we > document them automatically? A really ineffecient method would be to > keep an alist handy with (key . docstring) pairs, but I think the only > way around this would be to extend the use of \description (though > this would require all identifiers to be sequential blocks, e.g., > > hideNotes = > { > \description "..." > ... > } > Cheers, Valentin. _______________________________________________ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
