[2] Note again how the use of functional aguments allows for building of very general code libraries at high levels of abstraction. In our view this is part of the solution to the managability of the ever increasing complexity of software.

[3] To make a collection print so pretty we need to do a bit more, but pretty printing is not the topic of this chapter.

[4] Which was of course one of the reasons to define the onsets method in this way.

[5] The program to translate any musical object into a collection, which may contain only collections and notes, is left as an exercise to the reader.

[6] Of course this solution is not yet a final one because boundary boxes can easily overlap when musical objects are close in time or pitch. A better solution will be given later. [to do: are we creating better nesting anywhere ??]

[7] Which would quickly lead to difficult style-dependent issues.

[8] This definition of define- coctail- class is to be considered 'not done'. The use of eval on a constructed program has a high price (the need for the availability of the compiler at runtime) and a the dangerous possibility of confusing evaluation times and references.

[9] Cocktail classes that are mixed of the same ingredients are essentially equivalent and really have to be defined only once.

[10] It is a good execise to try to implement delete- selection, which is given a musical object and a selected part of it, maybe deep down in its structure without theuse of explicit backpointers first. It should first search for the compound object of which the to be deleted part is an element.

[11] N.B. These functiona are not Common lisp.

[12] The Undo facility will be treated later, in section 3.4: object oriented IV

[13] Using a functional style of programming, all of this would not have happened.

[14] Later we will open multiple views on the same object and maintain consistency