Re: Context.Grob considered as symbol list
On the other hand, things like \overrideProperty can only have one interface or the other, and put a single dotted symbol list here to specify the path with no alternative readings is dead simple and straightforward. And starting with version 2.19, or at the latest 2.21, I would want to remove the compatibility mode which is really complicating things both in the parser as well as conceptually. Using the dotted form only in the future is fine for me. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Context.Grob considered as symbol list
Werner LEMBERG wl at gnu.org writes: Instead of having an optional argument Remember that David's previous approach used no optional arguments, the optional components were attached with dots to the core arguments \override [Context.]Grob property[.subproperty] = #value \tweak [Grob.]property.[subproperty] value c2 I would prefer that both commands simply accept such a hierarchy, making e.g. \override color ... \override Accidental.color ... \override Voice.Accidental.color ... and \tweak color ... \tweak Accidental.color ... \tweak Voice.Accidental.color ... valid syntax Remember that by far the most common cases use no optional components, thus no dots in the old syntax. Also remember that \override color = #blue will not do anything useful even if it is valid syntax. (David's latest patch prints a reasonable message for the error above, before crashing.) I would prefer to keep David's previous syntax in documentation, even if we accept the fully-dotted form, because the space helps me find my way when copying new forms from the manuals. \override Ceol.Clochan dath.mion = #glas I forget a lot, but am reminded seeing the above that \override always takes a grob (sometimes with context to its left) and the property (rarely with sub-properties to its right). ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Context.Grob considered as symbol list
Keith OHara k-ohara5...@oco.net writes: Werner LEMBERG wl at gnu.org writes: Instead of having an optional argument Remember that David's previous approach used no optional arguments, the optional components were attached with dots to the core arguments \override [Context.]Grob property[.subproperty] = #value \tweak [Grob.]property.[subproperty] value c2 I would prefer that both commands simply accept such a hierarchy, making e.g. \override color ... \override Accidental.color ... \override Voice.Accidental.color ... and \tweak color ... \tweak Accidental.color ... \tweak Voice.Accidental.color ... valid syntax Remember that by far the most common cases use no optional components, thus no dots in the old syntax. Also remember that \override color = #blue will not do anything useful even if it is valid syntax. (David's latest patch prints a reasonable message for the error above, before crashing.) Aborting with an error message? I am actually not all too sure. At some point of time I ran out of steam accommodating the never satisfied. I would prefer to keep David's previous syntax in documentation, even if we accept the fully-dotted form, because the space helps me find my way when copying new forms from the manuals. \override Ceol.Clochan dath.mion = #glas I forget a lot, but am reminded seeing the above that \override always takes a grob (sometimes with context to its left) and the property (rarely with sub-properties to its right). I suggest that you then take responsibility for your side in the shouting match. It would certainly simplify both code and concept (as witnessed by me taking almost a week, admittedly while other work of mine was being shouted down in parallel, just for coming up with a still faulty implementation), but that has never been a strong reason here. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Context.Grob considered as symbol list
Keith OHara k-ohara5...@oco.net writes:
Werner LEMBERG wl at gnu.org writes:
Instead of having an optional argument
Remember that David's previous approach used no optional arguments,
the optional components were attached with dots to the core arguments
\override [Context.]Grob property[.subproperty] = #value
\tweak [Grob.]property.[subproperty] value c2
I would prefer that both commands simply accept such
a hierarchy, making e.g.
\override color ...
\override Accidental.color ...
\override Voice.Accidental.color ...
and
\tweak color ...
\tweak Accidental.color ...
\tweak Voice.Accidental.color ...
valid syntax
That's what is accepted in the current version of the patch. Of course,
except for \tweak Voice.Accidental.color which makes _absolutely_ no
sense whatsoever since tweaks are not associated with contexts. And
actually, it _will_ get accepted but will probably complain later that
the tweaked grob does not have a grob property called Voice.
Remember that by far the most common cases use no optional components,
thus no dots in the old syntax. Also remember that
\override color = #blue
will not do anything useful even if it is valid syntax. (David's latest
patch prints a reasonable message for the error above, before
crashing.)
It just does the following non-fatal error in the current version
(updated at origin/dev/syntax):
xxx.ly:1:12: error: bad grob property path
{ \override
color = #blue }
That's good enough.
I would prefer to keep David's previous syntax in documentation, even if
we accept the fully-dotted form, because the space helps me find my way
when copying new forms from the manuals.
\override Ceol.Clochan dath.mion = #glas
I forget a lot, but am reminded seeing the above that \override always
takes a grob (sometimes with context to its left) and the property
(rarely with sub-properties to its right).
On the other hand, things like \overrideProperty can only have one
interface or the other, and put a single dotted symbol list here to
specify the path with no alternative readings is dead simple and
straightforward. And starting with version 2.19, or at the latest 2.21,
I would want to remove the compatibility mode which is really
complicating things both in the parser as well as conceptually.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Context.Grob considered as symbol list
David Kastrup d...@gnu.org writes: Werner LEMBERG w...@gnu.org writes: On the other hand: Wouldn't it be possible to make LilyPond simply walk over all possible combinations to find out whether, say, foo.bar is a context followed by a property, or a property followed by a sub-property, etc.? Technically impossible. At the time an \override is parsed, the valid set of contexts has not been established. OK. And the interpretation of the just parsed data (this is, checking the validity of contexts, properties, etc.) can't be delayed, right? Context validity can't be checked at that point of time. The system of available properties, however, is more or less considered static, so the basic consistency checks for overriding existing/non-existing properties are being done while parsing. However, I consider it a bad idea to use insider knowledge for parsing an override (meaning skip ahead until finding a word declared as a grob property and split the input backwards from there) since it means that understanding the input requires knowing _all_ prospective properties, whether it is a human, a LilyPond importer, a syntax highlighter, a cross referencing tool or LilyPond itself that is trying to interpret the input. But then most of those don't need to _understand_ the input really. And it turns out that _all_ decisions, whether we are talking tweak or override, can be made on the criterion is the first element in the list a grob name?, the decision that currently _can_ be made statically. Of course, the call interface of \override/\revert currently expects _two_ symbol chains. Conflating these chains (making \tweak and \override compatible again) is not really a backward compatibility problem for \override since its $#!? syntax demands conflating symbol lists before the '=' signs anyway. \revert, however, is a different matter. It currently needs exactly two symbol chains as argument. To accept only one, it would need to first accept one symbol chain, check it, and then _only_ in case that this symbol chain _ends_ in a grob name, parse another one. Very unpretty. But yes, it would likely get a load of users off our necks. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Context.Grob considered as symbol list
On 2012-10-13 07:30, Keith OHara wrote: Can anyone reading here (other than David who implemented it) give an example where he has used the grob-augmented \tweak syntax ? I had to use it to change the parentheses of \parenthesize, e.g. to use square brackets or to use only a left or right parenthesis (to indicate longer parenthesized parts, like multiple staccatos). See: http://lists.gnu.org/archive/html/lilypond-user/2012-09/msg00707.html Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://www.kainhofer.com * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * Edition Kainhofer, Music Publisher, http://www.edition-kainhofer.com ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Context.Grob considered as symbol list
On the other hand: Wouldn't it be possible to make LilyPond simply walk over all possible combinations to find out whether, say, foo.bar is a context followed by a property, or a property followed by a sub-property, etc.? Technically impossible. At the time an \override is parsed, the valid set of contexts has not been established. OK. And the interpretation of the just parsed data (this is, checking the validity of contexts, properties, etc.) can't be delayed, right? LilyPond's parser is written with Bison, a standard parser generator normally used for writing that part of a compiler that would deal with syntax. LilyPond's free-form language stretches the capabilities of Bison beyond what it has been designed for. Interesting. My knowledge here is very limited. So let's just assume I have heard of compilers. Give me a bit of credit here. I don't doubt your capabilities. I only refer to error messages which I've seen while working with C++ code. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Context.Grob considered as symbol list
Werner LEMBERG w...@gnu.org writes: On the other hand: Wouldn't it be possible to make LilyPond simply walk over all possible combinations to find out whether, say, foo.bar is a context followed by a property, or a property followed by a sub-property, etc.? Technically impossible. At the time an \override is parsed, the valid set of contexts has not been established. OK. And the interpretation of the just parsed data (this is, checking the validity of contexts, properties, etc.) can't be delayed, right? Context validity can't be checked at that point of time. The system of available properties, however, is more or less considered static, so the basic consistency checks for overriding existing/non-existing properties are being done while parsing. However, I consider it a bad idea to use insider knowledge for parsing an override (meaning skip ahead until finding a word declared as a grob property and split the input backwards from there) since it means that understanding the input requires knowing _all_ prospective properties, whether it is a human, a LilyPond importer, a syntax highlighter, a cross referencing tool or LilyPond itself that is trying to interpret the input. LilyPond's parser is written with Bison, a standard parser generator normally used for writing that part of a compiler that would deal with syntax. LilyPond's free-form language stretches the capabilities of Bison beyond what it has been designed for. Interesting. My knowledge here is very limited. Mine isn't. Educating people about the details takes a lot of time, and it is time that only has a payoff if their ultimate goal is actually working in that area rather than just satisfying their sense of being taken seriously. The problem is that there is an unlimited supply of people with helpful suggestions, and if they come and go without having acquired enough working knowledge to actually make a difference, or even if they stay without working on connecting the dots to a degree where their contributions become more focused, the net balance makes them feel more important and me feeling more futile, with no new work being accomplished, and the value of the actually accomplished work being slighted or dismissed. So let's just assume I have heard of compilers. Give me a bit of credit here. I don't doubt your capabilities. I only refer to error messages which I've seen while working with C++ code. At a climbers' weekend, I answered a call from my ex, afterwards explaining apologizingly that I was sort of her support person for LaTeX problems while she was doing her dissertation. One of the climbers (who I met there for the first time) pitched in with Oh, I know someone who could do this better. This piqued my interest and I asked for his name, being reasonably sure that I'd have heard of him, likely met him in person already if this was the case. Turned out that his qualification was that he had written something akin to a dissertation using LaTeX himself. My ex could probably have run circles around him, and she was doing Romance studies. Now this incident was more amusing than anything else. What I am getting at that it is taking enough effort and energy to work and discuss on an item-per-item basis and bringing the discussion partners up to scratch on that. I don't actually have the means to address I feel sure others manage to do a better job under circumstances I consider the same in any meaningful manner: there are too many technical details involved to address that. The net result is the impression that I am seen as doing a subpar job, making LilyPond worse than necessary either through incompetence or obstinacy. Whether this impression is one I get myself, or other people interested in LilyPond: I doubt that it serves as a motivator. So I would prefer if we tried discussing LilyPond as a system in its own right rather than using sweeping comparisons with systems that are actually quite dissimilar. I just have a better chance of not tearing out my hairs completely in vain then, and they are a limited resource. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Context.Grob considered as symbol list
On 2012-10-12 00:25, David Kastrup wrote: \tweak gets one symbol list, \override gets two symbol lists. The symbol list for \tweak may optionally start with a grob name, the first symbol list for \override may optionally start with a context name. I can offer \tweak color.Accidental #red cis as the optional form for \tweak, but that seem bonkers. Is there really no way to determine whether a symbol describes a context, a grob or a grob property? We don't neccessarily need this at the parsing stage. We might change the internal functions to use a list to describe the full path for grob properties, and the functions that handle them could then check whether the first entry is a context, a grob or a property. Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://www.kainhofer.com * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * Edition Kainhofer, Music Publisher, http://www.edition-kainhofer.com ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Context.Grob considered as symbol list
David, On Fri, Oct 12, 2012 at 7:57 AM, David Kastrup d...@gnu.org wrote: AFAIK, compilers do something similar, warning about ambiguities. It is one of the sad facets of communication that the mood-deteriorating effects of unintentional satire are quite similar to that of the real deal. I don't know what you mean here, and i prefer not to guess since guessing often leads to misunderstanding. Can you say it in a more straightforward manner, please? Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Context.Grob considered as symbol list
Janek Warchoł janek.lilyp...@gmail.com writes: On Fri, Oct 12, 2012 at 7:57 AM, David Kastrup d...@gnu.org wrote: AFAIK, compilers do something similar, warning about ambiguities. It is one of the sad facets of communication that the mood-deteriorating effects of unintentional satire are quite similar to that of the real deal. I don't know what you mean here, and i prefer not to guess since guessing often leads to misunderstanding. Can you say it in a more straightforward manner, please? The above statement is like telling a flutist that he can't be much of a musician since one has seen other musicians sing while playing. Or tell a composer That was pretty swell. Have you ever heard of somebody called Bach, by the way? Probably worth a look. The limitations when working on the compiler-technology parts of LilyPond don't go away by name-dropping of compilers in general unless one assumes that the recipient of the message has such a confined area of expertise that even this sort of reference will serve to broaden his horizon. Regarding the sad facets: even though I perfectly well realize that Werner might not have the level of technical skills required to realize that he is in effect calling me clueless in an area I specialize in, my mood has the capacity of being negatively affected. The message gains an agenda of its own which it is able to deliver without further help from its sender. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Context.Grob considered as symbol list
2012/10/9 David Kastrup d...@gnu.org:
Since this patch series is a bit humongous for reviewing in a single
Rietveld review and it would take two months to get every patch in
sequence through an individual review, I am putting this series out as
an experiment to the list.
Let's see how we fare.
Hi David,
sorry to drop in that late.
I had seen your patch and call for feedback before, but no time to
have a look in it. But now I did.
I copied some extracts with (small) comments:
(1)
-\tweak #'color #red c4
-\tweak #'color #red c4
+\tweak color #red c4
+\tweak color #red c4
-\once \override Glissando #'style = #'dashed-line
+\once \override Glissando style = #'dashed-line
(these are some examples among a plethora of others)
This is great!!
Ofcourse the argument still needs hash and '-sign (if needed)
Excursion (skip if you want):
Recently I tried changing \label to give it a STRING-argument,
planning to parse this STRING in some additional manner.
Estimating the amount of work to change all other
functions/definitions/commands related to \label I gave up and used a
workaround.
(2)
-\once \override Glissando #'(bound-details left Y) = #3
-\once \override Glissando #'(bound-details right Y) = #-2
+\once \override Glissando bound-details.left.Y = #3
+\once \override Glissando bound-details.right.Y = #-2
Great again!!
(3)
-\footnote #'(1 . -1) #'Stem
- \markup { \teeny { Das ist ein Hals } } \default
+\footnote #'(1 . -1)
+ \markup { \teeny { Das ist ein Hals } } Stem
Here I'm not convinced.
As a LilyPond-starter (I postulate a user not having read the NR
carefully) I'd be puzzled by the single: Stem.
The older version contains \default.
This is puzzling, too. (Again, I think of a lazy user.)
Is it possible to do:
\footnote #'(1 . -1) Stem
\markup { \teeny { Das ist ein Hals } }
?
Summary:
I'm enthusiastic.
And your patch will solve some of the complaints I've listed here
(putting together the results of the german user-poll):
http://lists.gnu.org/archive/html/lilypond-devel/2012-10/msg00178.html
-Harm
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
explaining parser subtleties (was: Context.Grob considered as symbol list)
Hi, i'm short on time so i'll try to be brief - hopefully this won't cause any misunderstanding. David, i understand that some comments and questions may look like the sender is questioning your knowledge in some area. I want to assure you that when i ask such a stupid question, i'm not questioning your knowledge - i'm asking for explanation so that i could understand. In other words, my intent is never it looks like you're mistaken. prove that you're right. I always mean i don't understand this because i'm a newbie in this area. You are experienced - could you explain to me why we cannot do this? I think it would be easier for both you and us if you assume that the intent of our questions is like i described above (unless someone explicitely says i think you're wrong). On Fri, Oct 12, 2012 at 10:18 AM, David Kastrup d...@gnu.org wrote: Educating people about the details takes a lot of time, and it is time that only has a payoff if their ultimate goal is actually working in that area rather than just satisfying their sense of being taken seriously. I agree that this is a serious problem. However, i think that we cannot avoid it completely: we are a team, and we need to know what's happening inside LilyPond. Of course, you don't have to write super-detailed explanations about everything. By the way: if people won't understand what you do and why, they may not be able to actually *use* the solutions you provide, and they will be unable to appreciate them :/ best wishes, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Context.Grob considered as symbol list
However, one could change the current \tweak Accidental.color into \grob Accidental \tweak color ... and similarly for other tweaks: \grob name would just take the next music element, take a look at the last applied tweak and make it specific to one grob type. Better names welcome. It would be used for making a \tweak more specific. That would get rid of the \tweak anomaly and also provide the directed tweak interface for \footnote. Sounds interesting. Could you show an `bigger' example how it would look like? And \grob is an excellent name, I think. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Context.Grob considered as symbol list
Hello, On 10 Oct 2012, at 21:02, Werner LEMBERG w...@gnu.org wrote: X-offset anyone? ... should be renamed IMHO. Regardless of our discussion, it doesn't fit into the current naming scheme. The corresponding axis is called X, and using x for a constant in the expectation that the user would not attempt naming a variable after it would seem rather optimistic. I think a big fat bold sentence which says Variables *must* start with a lowercase letter, contexts with an uppercase letter. should make everything clear. What do others think? Well taking Werner's last reply at face value, I'd say 'big fat bold sentences' (in amongst oh so many other big fat bold sentences) is not helpful at all and makes nothing clear if in the end things are not consistent for the user. I already struggle with orders of things, dots or hashes or brackets and things like when I use staff vs Staff. What I think about 'x-offset' is that would using 'Left' and 'Right' be more in keeping with things like UP and DOWN that we use already for DIRECTION (slurs, cues etc.)? I don't really follow technically the conversation that lead to David's comment of 'X-offset anyone?' but would this be an alternative? James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Context.Grob considered as symbol list
James pkx1...@gmail.com writes: On 10 Oct 2012, at 21:02, Werner LEMBERG w...@gnu.org wrote: X-offset anyone? ... should be renamed IMHO. Regardless of our discussion, it doesn't fit into the current naming scheme. The corresponding axis is called X, and using x for a constant in the expectation that the user would not attempt naming a variable after it would seem rather optimistic. I think a big fat bold sentence which says Variables *must* start with a lowercase letter, contexts with an uppercase letter. should make everything clear. What do others think? Well taking Werner's last reply at face value, I'd say 'big fat bold sentences' (in amongst oh so many other big fat bold sentences) is not helpful at all and makes nothing clear if in the end things are not consistent for the user. I already struggle with orders of things, dots or hashes or brackets and things like when I use staff vs Staff. What I think about 'x-offset' is that would using 'Left' and 'Right' be more in keeping with things like UP and DOWN that we use already for DIRECTION (slurs, cues etc.)? I don't really follow technically the conversation that lead to David's comment of 'X-offset anyone?' but would this be an alternative? X-offset was an example for a grob property that starts with an uppercase letter, to put a damper on the suggestion to disambiguate grob names from grob property names in function calls by looking at lettercase. Now of course there is something to be said for naming consistency, but I still don't want to make the interpretation of identifiers depend on case other than, of course, that you need to stick with the exact spelling of an identifier once you picked its name. X-offset could likely be renamed into right-shift or shift-right, accompanied by shift-up or so. However, it would then seem unnatural that there is no accompanying shift-left or shift-down. The obvious solution of adding shift-left and shift-down as well and calculating the offset as (shift-right - shift-left) has the disadvantage that you'll always need to override _both_ in order to change the offset predictably. Werner picked up on something I mentioned as a dissatisfactory workaround idea, so there is little surprise that I am not in favor. I found a quite more satisfactory solution by, uh, changing the footnote user interface _again_, something which you likely are not all that fond of hearing. It turns out that independently from the _big_ consequences of this change this would bring the footnote interface better in line with other functions without losing functionality (thanks to \single now being available). So the X-offset naming question really belongs in a separate discussion. If one wanted to bring it in line with the properties should be lower case mantra, the cheapest solution would probably be renaming it to offset-X instead. While I am not particularly enthralled with the original naming choice, I have my doubts that such a step would be worth the hassle. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Context.Grob considered as symbol list
[...] I still don't want to make the interpretation of identifiers depend on case other than, of course, that you need to stick with the exact spelling of an identifier once you picked its name. Besides limiting the namespace of user variables, what are your arguments against such a change? For me, the simplicity of being able to always use `.' to mark the hierarchy instead of using a combination of `space' and `.' definitely outweighs the namespace limitation. Werner picked up on something I mentioned as a dissatisfactory workaround idea, so there is little surprise that I am not in favor. I found a quite more satisfactory solution [...] It seems that I'm missing something. Let's assume that your footnote syntax change is applied. How do you then solve the case \tweak Accidental.color #red cis vs. \override Voice.Accidental color #red ? Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Context.Grob considered as symbol list
Werner LEMBERG w...@gnu.org writes: [...] I still don't want to make the interpretation of identifiers depend on case other than, of course, that you need to stick with the exact spelling of an identifier once you picked its name. Besides limiting the namespace of user variables, what are your arguments against such a change? For me, the simplicity of being able to always use `.' to mark the hierarchy instead of using a combination of `space' and `.' definitely outweighs the namespace limitation. Werner picked up on something I mentioned as a dissatisfactory workaround idea, so there is little surprise that I am not in favor. I found a quite more satisfactory solution [...] It seems that I'm missing something. Let's assume that your footnote syntax change is applied. How do you then solve the case \tweak Accidental.color #red cis vs. \override Voice.Accidental color #red \tweak gets one symbol list, \override gets two symbol lists. The symbol list for \tweak may optionally start with a grob name, the first symbol list for \override may optionally start with a context name. I can offer \tweak color.Accidental #red cis as the optional form for \tweak, but that seem bonkers. Yes, the difference in visuals for quite similar commands is a bit of a nuisance, but it is not the only difference. You forgot the equals sign in the \override command... At any rate, the long form of the \tweak command is rather rare and special, anyway. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Context.Grob considered as symbol list
\tweak Accidental.color #red cis vs. \override Voice.Accidental color #red \tweak gets one symbol list, \override gets two symbol lists. The symbol list for \tweak may optionally start with a grob name, the first symbol list for \override may optionally start with a context name. [...] Yes, the difference in visuals for quite similar commands is a bit of a nuisance, but it is not the only difference. You forgot the equals sign in the \override command... I've omitted it intentionally, since it isn't relevant to the argument I want to hold. For both commands, I see a hierarchy, and for me *as a user* the syntax difference looks artificial. Instead of having an optional argument I would prefer that both commands simply accept such a hierarchy, making e.g. \override color ... \override Accidental.color ... \override Voice.Accidental.color ... and \tweak color ... \tweak Accidental.color ... \tweak Voice.Accidental.color ... valid syntax (where LilyPond complains if a hierarchy element is missing or inappropriate). I'm aware of the potential namespace clashes, so no need to reiterate this :-) On the other hand: Wouldn't it be possible to make LilyPond simply walk over all possible combinations to find out whether, say, foo.bar is a context followed by a property, or a property followed by a sub-property, etc.? Is this too expensive? Or is this technically impossible? AFAIK, compilers do something similar, warning about ambiguities. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Context.Grob considered as symbol list
Werner LEMBERG w...@gnu.org writes: On the other hand: Wouldn't it be possible to make LilyPond simply walk over all possible combinations to find out whether, say, foo.bar is a context followed by a property, or a property followed by a sub-property, etc.? Is this too expensive? Or is this technically impossible? Technically impossible. At the time an \override is parsed, the valid set of contexts has not been established. It may be different depending on the global context that is ultimately employed. For example, there is no GregorianTranscriptionVoice in Midi. The user may decide to define a few new context types in a \layout block coming later in file. And so on. AFAIK, compilers do something similar, warning about ambiguities. It is one of the sad facets of communication that the mood-deteriorating effects of unintentional satire are quite similar to that of the real deal. LilyPond's parser is written with Bison, a standard parser generator normally used for writing that part of a compiler that would deal with syntax. LilyPond's free-form language stretches the capabilities of Bison beyond what it has been designed for. So let's just assume I have heard of compilers. Give me a bit of credit here. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Context.Grob considered as symbol list
Colin Campbell c...@shaw.ca writes:
On 12-10-09 12:59 PM, David Kastrup wrote:
Since this patch series is a bit humongous for reviewing in a single
Rietveld review and it would take two months to get every patch in
sequence through an individual review, I am putting this series out as
an experiment to the list.
Let's see how we fare.
How do you want to handle countdowns for this patch, David? I suspect
the discussion might get rather technical, and I would have to rely on
your judgement as to when sufficient consensus has been reached for
the countdown step. There are several reviewers commenting on
Rietveld, which would ordinarily be enough for me to go to countdown,
but are you looking for explicit comment on each element in the
series? I wouldn't think it inappropriate if you put the patch on
countdown yourself, when you feel it has had proper discussion.
There is rarely such a thing as a proper discussion. Three quarter of
the patches in the series are straightforward simple rearrangements that
I'd have no qualms pushing without any indication of interest. Of the
remaining patches, half create more natural/nicer user interfaces for a
number of existing functions. The rest introduces conceptually a
uniform concept of LilyPond syntax of which the existing language has
regional dialects in different areas which, after this change, can be
exchanged.
Now the question is what the performance impact of this new part of
LilyPond constructs with some ambiguity is.
If you compare the execution time of the classic
#(do ((i 0 (1+ i)))
(( i 10))
#{ \override Accidental #'color = \red #})
with
#(do ((i 0 (1+ i)))
(( i 10))
#{ \override Accidental color = \red #})
of course the cost of calling the LilyPond parser a hundred thousand
times is going to dominate the execution time. However, there is still
a significant difference (5-10%) between the two. The latter is faster.
Now of course the comparison is not fair since I was using the same
LilyPond version, and so the machinery for sifting through various types
of strings and symbols was at work in either case. However, the point
is that switching to the Guile interpreter may be cheap, but it is not
zero price, so for the actually trivial stuff like symbols even with the
necessary resolution of ambiguities, a native LilyPond equivalent to
symbols buys us performance as well.
It is not likely to matter much in practice, but in this case there is
not even a tradeoff between convenience and performance involved, and
that makes for some incentive to move to LilyPond-native representations
even while they are optional.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Context.Grob considered as symbol list
Ok, here are a few followup thoughts. One: response to the on-list posting of the patches, intended to be more useful for per-patch review, has resulted in zero followups. I'll put out the next iteration to the lilypond-auto list for that reason, at least I'll attempt doing so (the list page sounds like postings not made by bots might get auto-grounded). Barring that, again on the developer list. I've made a much more radical patch converting all \override/\revert to use the now available syntax. Now I've hit another snag: \tweak. \tweak has an optional grob argument (now a string) situated before its target symbol. This obviously won't survive upon converting the second argument to string as well. What this means is that \tweak Accidental #'color #red cis will have to get converted to \tweak Accidental.color #red cis in order to preserve the optional character of Accidental. Contrasting this with \override Accidental color #red or \override Voice.Accidental color #red This is a bit unsatisfactory. Basically, the optional component is separated by a period. While that is reasonably understandable, the difference in syntax is a bit of a nuisance. Also, \override syntax is backwards compatible, the grob-augmented \tweak syntax (granted, just available since 2.16) is not. Sigh. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Context.Grob considered as symbol list
One: response to the on-list posting of the patches, intended to be more useful for per-patch review, has resulted in zero followups. Well I've already checked your changes on Rietveld, so I simply skipped the patches sent to lilypond-devel. \tweak has an optional grob argument (now a string) situated before its target symbol. This obviously won't survive upon converting the second argument to string as well. What this means is that \tweak Accidental #'color #red cis will have to get converted to \tweak Accidental.color #red cis in order to preserve the optional character of Accidental. Contrasting this with \override Accidental color #red or \override Voice.Accidental color #red Would it be possible to have \override Accidental.color #red \override Voice.Accidental.color ? For me, this feels most natural. In case a convert-ly rule is feasible, I don't mind changing the syntax. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Context.Grob considered as symbol list
Werner LEMBERG w...@gnu.org writes: One: response to the on-list posting of the patches, intended to be more useful for per-patch review, has resulted in zero followups. Well I've already checked your changes on Rietveld, so I simply skipped the patches sent to lilypond-devel. \tweak has an optional grob argument (now a string) situated before its target symbol. This obviously won't survive upon converting the second argument to string as well. What this means is that \tweak Accidental #'color #red cis will have to get converted to \tweak Accidental.color #red cis in order to preserve the optional character of Accidental. Contrasting this with \override Accidental color #red or \override Voice.Accidental color #red Would it be possible to have \override Accidental.color #red \override Voice.Accidental.color ? For me, this feels most natural. Won't work since you can't distinguish \override Voice.Accidental.color from \override Accidental.bound-details.left and I really don't want to try picking this apart based on uppercase/lowercase letter distinctions. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Context.Grob considered as symbol list
Would it be possible to have \override Accidental.color #red \override Voice.Accidental.color ? For me, this feels most natural. Won't work since you can't distinguish \override Voice.Accidental.color from \override Accidental.bound-details.left and I really don't want to try picking this apart based on uppercase/lowercase letter distinctions. In other words, `.' is used for two different purposes, namely to indicate hierarchy of Contexts and accessing properties of grobs. What about to disunify these two purposes, introducing a different symbol? Something like \override VoiceAccidental.color \override Accidental.bound-details.left Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Context.Grob considered as symbol list
Werner LEMBERG w...@gnu.org writes: Would it be possible to have \override Accidental.color #red \override Voice.Accidental.color ? For me, this feels most natural. Won't work since you can't distinguish \override Voice.Accidental.color from \override Accidental.bound-details.left and I really don't want to try picking this apart based on uppercase/lowercase letter distinctions. In other words, `.' is used for two different purposes, namely to indicate hierarchy of Contexts and accessing properties of grobs. No, it is used for tying several symbols into one list. \override takes one list for specifying the grob, and one list for specifying the property/subproperty of the grob. \tweak takes just a single list for specifying the property, but that list may include a grob at its start. It's just that the lists for \override and \tweak are structured differently when \tweak takes an optional grob specification. But the purpose of '.' is the same in each case. What about to disunify these two purposes, introducing a different symbol? Something like \override VoiceAccidental.color \override Accidental.bound-details.left That does not map to anything useful at the Scheme level. Nor does it map to any useful concept. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Context.Grob considered as symbol list
Would it be possible to have \override Accidental.color #red \override Voice.Accidental.color ? For me, this feels most natural. Won't work since you can't distinguish \override Voice.Accidental.color from \override Accidental.bound-details.left and I really don't want to try picking this apart based on uppercase/lowercase letter distinctions. After some thinking I wonder why not? For example, Haskell does something similar, this is, some elements (type names) of this programming language must start with an uppercase letter. IMHO, it would elegantly solve this problem. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Context.Grob considered as symbol list
Werner LEMBERG w...@gnu.org writes: Would it be possible to have \override Accidental.color #red \override Voice.Accidental.color ? For me, this feels most natural. Won't work since you can't distinguish \override Voice.Accidental.color from \override Accidental.bound-details.left and I really don't want to try picking this apart based on uppercase/lowercase letter distinctions. After some thinking I wonder why not? X-offset anyone? For example, Haskell does something similar, this is, some elements (type names) of this programming language must start with an uppercase letter. IMHO, it would elegantly solve this problem. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Context.Grob considered as symbol list
[...] I really don't want to try picking this apart based on uppercase/lowercase letter distinctions. After some thinking I wonder why not? X-offset anyone? ... should be renamed IMHO. Regardless of our discussion, it doesn't fit into the current naming scheme. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Context.Grob considered as symbol list
Werner LEMBERG w...@gnu.org writes: [...] I really don't want to try picking this apart based on uppercase/lowercase letter distinctions. After some thinking I wonder why not? X-offset anyone? ... should be renamed IMHO. Regardless of our discussion, it doesn't fit into the current naming scheme. The corresponding axis is called X, and using x for a constant in the expectation that the user would not attempt naming a variable after it would seem rather optimistic. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Context.Grob considered as symbol list
David Kastrup d...@gnu.org writes: Werner LEMBERG w...@gnu.org writes: [...] I really don't want to try picking this apart based on uppercase/lowercase letter distinctions. After some thinking I wonder why not? X-offset anyone? ... should be renamed IMHO. Regardless of our discussion, it doesn't fit into the current naming scheme. The corresponding axis is called X, and using x for a constant in the expectation that the user would not attempt naming a variable after it would seem rather optimistic. In other words: I don't think that we want types be decided by letter. This sort of implicit declaration is going to cause surprises. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Context.Grob considered as symbol list
X-offset anyone? ... should be renamed IMHO. Regardless of our discussion, it doesn't fit into the current naming scheme. The corresponding axis is called X, and using x for a constant in the expectation that the user would not attempt naming a variable after it would seem rather optimistic. I think a big fat bold sentence which says Variables *must* start with a lowercase letter, contexts with an uppercase letter. should make everything clear. What do others think? Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Context.Grob considered as symbol list
Since this patch series is a bit humongous for reviewing in a single Rietveld review and it would take two months to get every patch in sequence through an individual review, I am putting this series out as an experiment to the list. Let's see how we fare. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Context.Grob considered as symbol list
On 12-10-09 12:59 PM, David Kastrup wrote: Since this patch series is a bit humongous for reviewing in a single Rietveld review and it would take two months to get every patch in sequence through an individual review, I am putting this series out as an experiment to the list. Let's see how we fare. How do you want to handle countdowns for this patch, David? I suspect the discussion might get rather technical, and I would have to rely on your judgement as to when sufficient consensus has been reached for the countdown step. There are several reviewers commenting on Rietveld, which would ordinarily be enough for me to go to countdown, but are you looking for explicit comment on each element in the series? I wouldn't think it inappropriate if you put the patch on countdown yourself, when you feel it has had proper discussion. Cheers, Colin -- I've learned that you shouldn't go through life with a catcher's mitt on both hands. You need to be able to throw something back. -Maya Angelou, poet (1928- ) ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
