MENTAL
 Main Menu
 Applications
 Computer Science
 Event-Driven Programming

Event-Driven Programming
 EVENT-DRIVEN
PROGRAMMING

"Gaining a deep understanding of the event process is still a challenge" (Ted Faison).

"A programming language is low-level when its programs require attention to the irrelevant" (Alan J. Perlis).


The Concept of Event

An event is something that occurs in a system and that is of interest to know or detect in order to carry out a certain process associated with that event.

The general way to specify an event is "If condition, then action".

Events can be internal and external:
Specification in MENTAL

An event is specified by a conditional generic expression:
Observations
Process of an event

When an event occurs, the following process takes place:
  1. The current process is paused.
  2. The event is processed, i.e. the action associated with the event is executed.
  3. The evaluation of the current expression is continued, unless in the previous step, a stop occurs, for example, due to the detection of an error.

Named and anonymous events

A named event is an event that is assigned a name so that it can be referred to throughout a program. The form is where e is the name of the event.

An anonymous event is one that is defined without a name, by directly specifying the corresponding generic expression:

Specific and generic events

The generic expression specifying an event can be parameterized or not: Examples of specific events:
  1. Detect if a is an element of the group (sequence or set) g:

    ⟨( a∈g → action )⟩

  2. Detect if the variable u has a value greater than 1 and less than 10:

    ⟨( (u>1 → u<10) → action )⟩

  3. Detect whether a group g contains a, b or c:

    ⟨( {(a∈g)? (b∈g)? (c∈g)? }↓ → action )⟩

    In a more compact form:

    ⟨( {[(([a b c]∈g)?]}↓ → action )⟩

  4. Detect whether any element of a sequence s belongs to g:

    ⟨( {[s↓∈g)?]}↓ → action )⟩
Examples of generic events:
  1. Detect if an element a belongs to a group (sequence or set).

    ⟨( (x = {x↓}) → a∈x → action )⟩

  2. Detect a group (sequence or set) of length greater than 10:

    ⟨( (x# > 10) → action )⟩

  3. Detect whether a simple condition is evaluated:

    ⟨( (x → y) → action )⟩

  4. Detect whether a complete condition is evaluated:

    ⟨( (x ← y →' z) → action )⟩

Parameterized events

These are events defined by parameters. They can be, in turn, specific or generic, depending on whether they include, in turn, parameters in their definition.

Example of specific parameterized event:

⟨( e(u v) = ⟨( (a>u → a<v) → action )⟩ )⟩ // definition event

(e(3 9)) // event activation ⟨( (a>3 → a<9) → action )⟩

Example of generic parameterized event:

⟨( e(u v) = ⟨( (x>u → x<v) → action )⟩ )⟩ // event definition

e(3 9) // event activation ⟨( (x>3 → x<9) → action )⟩

In this case there are two types of parameters: those of its definition or internal (x) and external (u and v).


Relative events

The above events were of absolute (or global) type, since they affected all expressions that are evaluated. But there may be events that only apply to a certain expression. These are the relative (or local) events. They are specified by where x is the potential source expression (event producer) and ⟨e⟩ is the generic expression defining the relative event.

As in the case of absolute events, relative events can be specific or generic, depending on whether or not parameters are defined.

Examples:
  1. Prevent a variable (result of an operation) from exceeding a certain value.

    (y = x*x + 7)/⟨( y>1000 → (y = 1000) )⟩

  2. Prevent the result of a given function from exceeding a certain value, regardless of the argument.

    ⟨( f(x) = x*x )⟩/⟨( f(x)&&rgt;1000 → (f(x) = 1000) )⟩

Dynamic events

A dynamic event is an event that changes during the execution of a program. It can change in many ways: by making the condition, action or both variable, by parameterizing the event, etc. Examples:
  1. Variable condition.

    ( cond = (x>10)° ) // initial condition.
    ⟨( cond → x=10 )⟩ // event definition
    (x = 20)
    x // ev. 10
    ...
    ( cond = (2*x > 20)° ) // new condition
    (x = 5)
    x // ev. 5

  2. Variable action.

    ( action = (x=10)° ) // initial action.
    ⟨( x>10 → action )⟩ // definition of event
    (x = 20)
    x // ev. 10
    ...
    ( action = (x = (x = 2*x)° ) // new action
    (x = 20)
    x // ev. 40

  3. Variable full event.

    ( event = (x>10 → x=10)° ) // initial event
    ⟨( event )⟩ // event definition
    (x = 20)
    x // ev. 10
    ...
    ( event = (x>20 → x=30)° ) // new event
    (x = 25)
    x // ev. 30

Null event

A null event is one in which the condition or action of the generic expression is null. The event is said to be null because it produces no effect: Using a variable (as a condition or as an action), which can take a null value or a non-null concrete value, we can activate or deactivate the event, in its condition or action aspect. Examples:
  1. (cond = θ) // null condition
    ⟨( cond → action )⟩ // event disabled by null condition

  2. (action = θ) // null action
    ⟨( cond → action )⟩ // event disabled by null action

Change detection

In a dynamic environment, expressions can change over time. If you want to capture the event that a certain expression changes, it can be done, but you need to include additional variables that record the changes.

Example: We want to detect changes in the variable x.
Higher order events (event events)

An event event (order 2 event) is an event that happens during the process associated with a normal (order 1) event.

Order 2 events can be absolute or relative to the event process. The relative form would be: Example: Detect, only during the processing of an event, if a variable exceeds a certain value. Similarly, higher level events (3, 4, etc.) can also be specified.


Examples of restrictive events
  1. We want that a given variable v during a process, never exceeds the value 10. If it is greater, it must be automatically made equal to 10.

      ⟨( v>10 → v=10 )⟩
      (v = 12)
      v // ev. 10

  2. In a given sequence s of two components, initially with the value (3 7), we want the sum to always be 10, so that the second component always matches the value of the first.

      (s = (3 7))
      ⟨( (s\1 + s\2)10 → (s\2 = (10 - s\1)) )⟩
      (s\1 = 4)
      s // ev. (4 6)

  3. Prevent a sequence s from having more than two components.

      ⟨( (s# > 2) → (s = (s\1 s\2)) )⟩
      s=(a b c)
      s // ev. (a b)

Security and exceptions through constraints

The constraint mechanism is applicable to security issues and for exception control. The following are examples of generic constraints (use parameters).
  1. Division by zero.
    We want to intercept divisions by zero, before they occur, and obtain in the variable error the null expression θ if there is no error or a text with the message "Attempt division by zero in exp", being exp the expression to which the division by zero is attempted to be applied. Then stop the process.

    ⟨( (error = θ) ←' (x÷0) → ((error = "Attempt to divide by zero in " x) ■) )⟩

  2. In order to avoid memory problems, we want to prevent any sequence x from being of length greater than 1000, by preventing assignments of type (x\i = y) with i greater than 1000.

    ⟨( ((x\i) = θ) ← i>1000 )⟩

Advantages of MENTAL in Event-Driven Programming

Addenda

History of events in the software

Events were born in the software world in the early 1980s with the Smalltalk language to keep the parts of a system synchronized. But two were its big drivers: 1) externally, at the user level, the graphical user interfaces of operating systems, such as Microsoft Windows; 2) internally, the emergence of Visual Basic in the early 1990s.

With the advent of the Internet, "push" systems emerged, in which users subscribe to topics that interest them and automatically receive notifications of news.


Classic implementation of an event-driven system

When event-driven programming is used as the only programming paradigm with traditional languages, program execution is determined solely by the process associated with the events. It is implemented as follows:
  1. Code and data initializations are performed.

  2. The events that are contemplated in the system are specified.

  3. An "event loop" is developed, a loop that waits for an event to occur. When it occurs, it invokes the handler associated with that event, which processes it, and goes back to waiting for another event to occur.
For example, interactive word processing programs, spreadsheet programs, drawing programs, presentation programs, etc. are started and wait for the user's actions on the graphical user interface that presents the program.

In MENTAL everything is simpler and more straightforward. There is no need for an event loop because the semantics of the generic expression already performs it implicitly. And the event handler resides in the language code associated with the condition.

While the notion of event is natural, its support in programming languages is often unexpressive, non-generic, and difficult to use. Several languages support (each in its own way) event orientation, such as Visual Basic, Tcl/Tk, Java, Delphi, PowerBuilder, C#, FoxPro, Simula, etc. In Artificial Intelligence we do not speak of events, but of "demons", entities that are alert to the occurrence of specific events and that trigger associated actions or processes when they occur.


Bibliography