Libero gives you the freedom you get to choose the language that suits your purpose. The way I add support for a particular language is to write a new schema file. This is a kind of script that tells Libero how to generate code for that particular language. Inevitably, the solution I choose for a language tends to vary. For example, the C schema generates a couple of include files to hold the generated code. The UNIX shell schemas in contrast take a source 'module' file and generate the final script (which you don't work on directly).

This section documents the special aspects of each language (ie. schema). Some aspects that apply to all languages:

All the schemas separate the generated code from the hand-written code. This means either a strict division into hand-written files and generated files, or some sleight-of-hand to get a similar result. The mechanism varies from language to language since I use the mechanisms that each language offers (if any). You should understand which files you get when you work in a particular language.
Most languages provide some form of function or subroutine. I define one such for each module in the dialog, and you are free to define your own 'private' functions in the code. Libero provides the facility to detect unused ('idle') modules, but for this the syntax for the module functions must be different to that for your private functions. (Otherwise Libero can't tell the difference, and issues loads of incorrect warning messages.) In a few languages I did not find an acceptable way of making the distinction, so the -idle options is disabled. In the remaining languages you must take care to follow the recommended syntax for your private functions.
The generated code provides a number of public data items and functions. These have the same name in each language, as far as possible. Reserved names start with '_LR_' or something similar. Never use or refer to these names.

Standard Public Names

All schemas should support these names, which change syntax according to the -style option:

xxxx_event - defined for each event in the dialog, where 'xxxx' is the name used in the dialog. Use these event names whenever you need to set the value of the_next_event.
the_next_event - the event for the next state. Set this event in one of the action modules, before entering a new state.
terminate_event - when you assign this to the_next_event, the state machine halts. Normally you will do this in the terminate_the_program module.
exception_raised - if you set this to TRUE, the dialog engine stops executing the current action list, and goes into exception handling. Exceptions are described later.
the_exception_event - before you raise an exception, set this to the event you want to use as exception event. This event must be defined in the current state you are in, or in the Defaults state.
initialise_the_program - this standard module is called when the dialog engine starts; here you can access and check parameters, and set a suitable next event like ok_event.
get_external_event - this standard module is called when the dialog needs an event, i.e. when none of the action modules put anything in the_next_event.
raise_exception - this standard function sets exception_raised and places the specified event into the_exception_event.