=head1 NAME

language.pod -- state of the art mudela-vapourware.

=head1 DESCRIPTION

[this document is slowly merged into the mudela doco, as the
implementation progresses. If you want to see our previous musings,
take out an old version of lilypond]

=head1 REQUIREMENTS

=head1 CONCRETE PROPOSALS


=head1 Decisions (Sat 1997-3-15, dommelpijpje no21)

	\extract{ \from 2:3*4 \to 5 oboe }

=head1 THOUGHTS

=head2 Typing

It is difficult to make mistakes with typing now because you have to
tell LilyPond what it is dealing with

	staff { identifier }

versus

	staff { music { identifier } }

I'm not sure on dropping this, I'm afraid it will make the language
less legible. Technically, dropping it is not very difficult (it will
introduce slight parser-source bloat)

What if the staff is extended to have some more blocks, all of which
can be declared? Like the score now:

	score {
		a_staff_id
		a_midi_id
		a_paper_id
		a_command_id
	}

This will only be readable if the Mudela-user rigidly uses hungarian,
which he/she won't.

Of course \key should take a \notename. In fact, I think we should
program the note intervals (which are now hardcoded for midi purposes)
To allow adaptation to other scales.

As simple fix, we might do key declarations:

	\keybes= \key { bes es }

	\key{\keybes}



=head2 Requests

I want to give the user some access to the internals. Technically,
engravers/performers will happily typeset voices which mix lyrics and
notes, which combine stem requests and lyricreqs. I want to have a

	\request { melodic name = 5, acc = -10
		rhythmic ball=4 dots 2, lyric = "foobar" }

type of syntax. This is the most flexible input format possible, since
any valid LilyPond input can be made. This strongly implies tying
mudela to LilyPond. That I don't mind, but it hampers
portability. Suppose some commercial systems want to read mudela too.

=head2 Command placement:


=head2 Volta

uhh?

=head2 Filtering

This is a idea of mine: we could filter some request types from
voices,

eg:

	\mel1 = \music { c-. d-. e-. f-. \meter {2*4} g-. a-. b.- c-. }

	\m1 = \filter { "script_req" \mel1 }
	\m2 = \filter { "command_req" \mel1 }
	\m3 = \filter { "melodic_req" \mel1 }
	\m3 = \filter { ("rhythmic_req") && (!"lyric_req") &&
		("stem_req" || "beam_req") \mel1 }
		% syntax needs change. Clash with () slur?

	\mel2 = \music { c c g  g a a g2 }

	\combined = \merge { \m1, \mel2  }

This means m1 contains the scripts, of \mel, \m2 only the meter
command surrounded by (essentially) some skips, and \m3 the notes
without scripts or meters. This could be a solution to the "command in
music vs. command with skip".

Combined with merging of requests, this would be a powerful tool. In
this example \combined is a combination of melody mel2 and the accents
of \mel1.

This idea is for advanced users, but it would come in handy in urtext
editions:

	include "mozart-horn.ly"

	\m1 = \merge { \urmozart + \dennisbrain_interpretation }
	\m2 = \merge { \urmozart + \barrytuckwell_interpretation }


=head2 Proposed operators:

Just ideas:

	|| && !		filter syntax 

=head2 Quoting

Difficult. Hmm...

	\oboe = \music { ........................ }

	\oboefragment = \extract { \from 5*2 \to 6*2 \music { \oboe } }


