lilypond-devel
[Top][All Lists]
Advanced

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

Re: GOP2-5 - GLISS discussions


From: David Kastrup
Subject: Re: GOP2-5 - GLISS discussions
Date: Fri, 14 Sep 2012 11:39:53 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (gnu/linux)

Werner LEMBERG <address@hidden> writes:

>> The current format needs to have a one-to-one correspondance (or
>> “bijection”) between ly and scheme. Graphically, the process is
>> something like this:
>> 
>>           ly <--> scheme -> pdf/midi
>
> I don't think that it is bijective.

It isn't.  Some music functions are used for producing dedicated Scheme
music expressions: those, in general, will get reasonably reconstructed
by \displayLilyMusic.  Quite a few music functions are there for
convenience, input manipulations.  Their application, of course, will
not be reversed when printing music expressions.

That gives us some convenient way of "canonicalizing" LilyPond:
\displayLilyMusic outputs a restricted form of LilyPond.

However, hardwired music constructs, namely stuff recognized by parser
rules outside of generic function calls and argument lists, usually
result in constructs reasonably structured along the structures of the
input.  This relation is not absolute, but it is rather fundamental to
making people deal comfortably with the language and its internals:
being able to analyze and print such constructs in predictable manners
enables people to work predictably and comfortably, and analyze how
their Scheme code works, and debug it where it goes wrong.

The less predictable and linear the transformation from LilyPond input
to Scheme becomes, the harder it becomes to solve problems in the
context of manipulating music.

> It's rather that anything in ly should be able to be representable in
> Scheme and vice versa.  This is not the same.  There might be multiple
> representations in Scheme, and multiple representations in lilypond
> for exactly the same thing.

More or less.

> PS: I'm still not happy with a separate mailing list.

A separate fluffy mailing list not to be taken seriously where people
may decide that no further changes to syntax will be allowed.

This has the ring of neighborhood meetings where people forget to invite
the new neighbors since this all is not to be taken seriously and where
one informally discusses how one can avoid the wrong people moving into
town.  But of course, not all that serious.  But then one does need
something to talk about, when almost everybody is present, since
otherwise it would be boring.  And when almost everybody is present
anyway, one might take the opportunity of talking enough to get to
making decisions after all.

Now this sounds like full-blown paranoia, but in terms of illustration,
exactly this was the way in which a vocal minority managed to get me
ousted from a prior choir of mine when I had to miss a rehearsal for job
reasons, so it is not like I don't know the way these things happen to
work, of course without any ill will involved.

Anyway: If the project lead tells me that I am wrong taking these
discussions seriously and they may move to another list where I am not
supposed to listen in, and at the same point of time states that
decisions need to be made, mentioning the decision to put a halt to any
further syntax changes as one example of a possible course...

It's pretty hard not to see where this is at least supposed to be able
to lead.

I don't see that my work so far warrants getting out the balls and
chains.  This really sounds like it is supposed to end in a rehash of
the story of Yunan and Duban.

-- 
David Kastrup




reply via email to

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