Re: significance of whitespace [WAS: LilyPond, Finale and Sibelius]

2009-04-07 Thread Simon Dahlbacka
 Can be typed pretty rapidly too: hold down right shift with your little
 finger and  fall under the index and middle fingers.
..not everyone uses us keyboard


___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user


significance of whitespace [WAS: LilyPond, Finale and Sibelius]

2009-04-06 Thread Jan Nieuwenhuizen
Op zondag 05-04-2009 om 18:13 uur [tijdzone -0300], schreef Han-Wen
Nienhuys:

 as long as I have anything to do with LilyPond, I will veto changes
 like this that introduce inconsistent whitespace handling in the
 syntax.

What was the problem with this again?  It is not so much inconsistent
whitepace, it's the absence or presence of whitespace.  That's
quite a difference.  We have that already

   c 4 4 == c4 4  != c44  % first ws significance BAD, second GOOD?
^ ^

I'm quite certain there is a good argument for not not making such
changes--in fact I remember proposing this change about a decade
ago and you talking me out of it :-) --but I don't remember
the reason.  

It would be good for the archives too: a good reason
may even hold it back should the veto ever fail ;-)

Jan.

-- 
Jan Nieuwenhuizen jann...@gnu.org | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien   | http://www.lilypond.org



___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user


Re: significance of whitespace [WAS: LilyPond, Finale and Sibelius]

2009-04-06 Thread Han-Wen Nienhuys
On Mon, Apr 6, 2009 at 9:23 AM, Jan Nieuwenhuizen
janneke-l...@xs4all.nl wrote:
 as long as I have anything to do with LilyPond, I will veto changes
 like this that introduce inconsistent whitespace handling in the
 syntax.

 What was the problem with this again?  It is not so much inconsistent
 whitepace, it's the absence or presence of whitespace.  That's
 quite a difference.  We have that already

   c 4 4 == c4 4  != c44  % first ws significance BAD, second GOOD?
    ^ ^

This is actually a lexicographic difference: the input of lilypond is
a stream of tokens (ints, keywords, strings, etc.), and we have  a
grammar specified in terms of these tokens.

There are also two technical reasons why this might is a bad idea.

When you introduce a change like this, it often means that the parser
has to signal back to the lexer, to interpret

  c4 =  PITCH=c , INT=4

and with space

  c 4 = PITCH=c, INT_AFTER_SPACE_PITCH=4

this is difficult to get right, since parser actions happen somewhat
unpredictably due to lookahead.

Secondly, if you do this, you now have an extra way
(INT_AFTER_SPACE_PITCH) to denote a number, on top of

 bare_unsigned:
UNSIGNED {
$$ = $1;
}
| DIGIT {
$$ = $1;
}
;

(remember: digits are already special due to constructions such as
c4-5), with all the extra difficulties of constructing a grammar
without ambiguities.

From a user perspective, I also don't see how this makes sense in
corner cases.  For example:

  c'=, ,4
  c4- 4

(note space between commas and after - ) - is this a
INT_AFTER_SPACE_PITCH? In this case, probably not, right?  (if it
would, it would be a parse error,  since comma on itself does not mean
anything.)

So, INT_AFTER_SPACE_PITCH is a number preceded by a space.

Great!  Now we have to keep track of all spaces in the lexer, to make
sure we catch all of the INT_AFTER_SPACE_PITCHes.

Great!  now \tempo 4 = 120 is actually taking a INT_AFTER_SPACE_PITCH
in its 3rd argument, just like c4 * 5 (the 5 is
INT_AFTER_SPACE_PITCH).  Good luck with not creating ambiguities.

Remember how much fun TeX is, where you have to cover up newlines in
definitions with %  (but only half of the time?) so you do not create
accidental spaces in macro expansions?  This is the same thing, and I
think it is a bad idea.

For crying out loud, why is this so difficult to understand?  Syntax
changes may be inspired by would it not be nice if .. , but this
mindset must then be discarded immediately to look whether you can
pull it off in the parser/lexer consistently.  Then, after introducing
it, run a 100 pieces of mutopia through the new lexer, and check if
they are not breaking in unobvious ways.

The lilypond syntax is already way more convoluted than is good for
it, and especially if there is an easy way to avoid the problem (using
 or similar), I see no reason to make it even more convoluted.

 I'm quite certain there is a good argument for not not making such
 changes--in fact I remember proposing this change about a decade
 ago and you talking me out of it :-) --but I don't remember
 the reason.

 It would be good for the archives too: a good reason
 may even hold it back should the veto ever fail ;-)




-- 
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen


___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user


Re: significance of whitespace [WAS: LilyPond, Finale and Sibelius]

2009-04-06 Thread Marc Hohl
Despite the fact that it would cause massive problems in parsing, a line 
like


c4 4 4 4

is not quite readable for me.

As lilypond is THE tool for typesetting beautiful scores, the source 
file should

reflect the beauty. So I should be able to grasp the score at first sight,
and in my opinion, a distinct repeat the last expression-sign would
be the best solution.

To join the discussion about the best character, here are my 2 cents:

1) personally, I would use the %, but this is the comment sign and 
can't be used.

   (perhaps this would be even possible, but ... NO!)

2) the  has a similar role in regular expressions as it would have in 
lilypond

   but I think not everyone using lilypond is familiar with grep and sed.
   The argument that it needs 2 keystrokes on most keyboards is not 
that important,
   because is will be used mostly as a shortcut for longer terms, so I 
will not write

   c4, but c4 c c c
   whereas c e g4ist faster to type than  c e g4  c e g   
c e g  c e g 
   (and more readable, because otherwise I could just use the 
copypaste function of

   my editor and forget about the rest)

3) why not use a x for eXpression, because the sign is meant not only 
to repeat

  Qords, but everything reasonable?

Marc


___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user


Re: significance of whitespace [WAS: LilyPond, Finale and Sibelius]

2009-04-06 Thread Han-Wen Nienhuys
I would avoid getting in this discussion before the feature is
complete.  Just call it \r (using an identifier or keyword),  and see
how it works in practice.  When it is debugged, think of a character.
The advantage of not using a letter a-z is that there are no backward
compat problems with source files that use said character as
identifier or unquoted string.


On Mon, Apr 6, 2009 at 11:30 AM, Marc Hohl m...@hohlart.de wrote:
 To join the discussion about the best character, here are my 2 cents:

 1) personally, I would use the %, but this is the comment sign and can't
 be used.
   (perhaps this would be even possible, but ... NO!)

 2) the  has a similar role in regular expressions as it would have in
 lilypond
   but I think not everyone using lilypond is familiar with grep and sed.
   The argument that it needs 2 keystrokes on most keyboards is not that
 important,
   because is will be used mostly as a shortcut for longer terms, so I will
 not write
   c4, but c4 c c c
   whereas c e g4ist faster to type than  c e g4  c e g   c e g
 c e g 
   (and more readable, because otherwise I could just use the copypaste
 function of
   my editor and forget about the rest)

 3) why not use a x for eXpression, because the sign is meant not only to
 repeat
  Qords, but everything reasonable?

 Marc


 ___
 lilypond-user mailing list
 lilypond-user@gnu.org
 http://lists.gnu.org/mailman/listinfo/lilypond-user




-- 
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen


___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user


Re: significance of whitespace [WAS: LilyPond, Finale and Sibelius]

2009-04-06 Thread Anthony W. Youngman
In message 49da120a.7090...@hohlart.de, Marc Hohl m...@hohlart.de 
writes
1) personally, I would use the %, but this is the comment sign and 
can't be used.

  (perhaps this would be even possible, but ... NO!)


Oh my gosh, please, NOOO

As Han-Wen has said, parsing is important. In another life I work with a 
language called DataBasic. What do you thing of the following line of 
code:


REM: REM = REM(6, 4) ; REM This is an example of a horrendous line.

Here we have REM used consecutively as (1) a label, (2) a variable, (3) 
a function, and (4) a language command. Now imagine how easy that is to 
lex/parse... because it IS legal syntax ! :-(


Cheers,
Wol
--
Anthony W. Youngman - anth...@thewolery.demon.co.uk



___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user


Re: significance of whitespace [WAS: LilyPond, Finale and Sibelius]

2009-04-06 Thread Marc Hohl

Anthony W. Youngman schrieb:
In message 49da120a.7090...@hohlart.de, Marc Hohl m...@hohlart.de 
writes
1) personally, I would use the %, but this is the comment sign and 
can't be used.

  (perhaps this would be even possible, but ... NO!)


Oh my gosh, please, NOOO

As Han-Wen has said, parsing is important. In another life I work with 
a language called DataBasic. What do you thing of the following line 
of code:


REM: REM = REM(6, 4) ; REM This is an example of a horrendous line.

Here we have REM used consecutively as (1) a label, (2) a variable, 
(3) a function, and (4) a language command. Now imagine how easy that 
is to lex/parse... because it IS legal syntax ! :-(


Cheers,
Wol

That's why I said NO! ;-)



___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user


RE: significance of whitespace [WAS: LilyPond, Finale and Sibelius]

2009-04-06 Thread Nick Payne
Why not use an empty pair of braces, which at the moment are just ignored by
the parser, to dignify chord repetition:

c e g  gives c e g c e g

c e g 3 gives c e g c e g c e g c e g

c e g c  gives c e g c - ie  ignored as now if preceding element is
not a chord

Can be typed pretty rapidly too: hold down right shift with your little
finger and  fall under the index and middle fingers.

Nick



___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user