=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]

here are some thoughts on the language. Most of the examples are in
pseudo current mudela.  Some stuff gratuitously taken from your mails.


=head1 NOTE

I dislike vapourware. That's why I oppose to concrete plans on how to
do input for features we don't know how to produce on paper 

=head1 REQUIREMENTS

=head1 CONCRETE PROPOSALS


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

=over 4

=item *

abbrev: [c2 c2]\noplet{1/2} (wat bout [c2 c2]1/2\noplet?),

=item *

abbrev: c4=16 (heu, =?),

=item *

plet === midi-note: c4*2/3; c4*385/384,

=item *

drop \music,

=item *

\meter compulsory in Simple mudela,

=item *

C<+> is  merge


=item *

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

=back



=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}



[LOOSE THOUGHT]

We might drop this {} argument altogether, by merely enforcing
that each "statement" (music,score,staff,chord) takes a LIST as
argument, and use the {} to group lists. This is admittedly perl. This
is very sketchy.


=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:

Mats is an arduous fan of having the commands inside music. I am
not. I see the Mudela music as something which can be plugged into
different staffs, transposed, translated in time, copied, quoted,
etc. Encouraging "inline" commands would be bad since they hinder this
reuse of typed music.

The way I figure it, the bad part is essentially counting
bars/wholes. Maybe we can get rid of it, by reinstalling the "mark"
commands.

I definitely want  to avoid complicated logic  ("Hey there is  another
bar request, should we merge this bar with another staff's", this kind
of "smartness" makes a  lot M$ software inconsistent) inside LilyPond,
by making the input unambiguous in this respect.

There is another complication: some symbols (bars) sometimes are
linked across staffs. I should first think of a way to do this in
LilyPond, before even considering a syntax.


=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 
	+		merging of voices

=head2 Quoting

Difficult. Hmm...

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

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