function calls etc.), but they could be mapped to other programming languages and runtime environments as well.

This would release the users from having to know the concrete syntax and processing details of different programming languages, which can already be tedious for different shell scripting languages like csh and bash. E.g. in bash there are two for-loops, with syntax

for name [ in word ] ; do list ; done

and

for (( expr1 ; expr2 ; expr3 )) ; do list ; done

while in csh only the form

foreach name (wordlist); ... ; end

is used. However, the correct construction of more complex shell scripts by hand is allways challenging in any shell language, because of the diverse substitutions for shell variables, regular expressions and escape sequences that are processed by different entities (see the manual pages for details).

A language mapping would also allow to provide the user with higher level language constructs, which are mapped by the system to possibly lower level language constructs available in concrete scripting languages. E.g., the LISP-typical mapcar function for applying a function to each of the elements of a list could be mapped to a while-loop in a shell script, that reads lines (the elements of the list) from a file and feeds them successively to a command, which realizes the function to be mapped. The command itself can be elementary in the target software package, or could be derived from an OpenMusic user patch.

5.4 Configuring an Interpreter Mapping in OpenMusic

More precisely, this is realized on an easy to use and flexible to configure language expression mapping system that we have embedded into OpenMusic. The user--as usual--connects elements within a patch, specifying the »what« of a process. Besides this, he or she specifies within the patch one or more »interpreters« by name, which realize the meaning of the associated visual elements, either--when evaluating an element within the patch--as an actual call or--when an abstraction of the patch (a function) is made--as code that becomes a part of a script. An »interpreter« must be configured by specifying

• a service provider, e.g. a remote application like the FScript component within Rubato, that provides the required functionality,
• the target programming language, usually the scripting language, the service provider understands,
• initialization routines and wrapper code needed to evaluate the scripts in the right environment, e.g. within a namespace reserved for use from OpenMusic or from a specific OpenMusic patch,