Informix 4GL implemented as a first-class GraalVM language on Truffle

The single most expensive assumption in an Informix modernisation programme is that the 4GL has to go first. Decades of pricing rules, credit policy, despatch logic and period-close procedure are encoded in programs that are correct, tested and understood — and every conventional route off the platform begins by translating them into something else. Translation is where the risk lives: the rewritten rule is a new artifact requiring re-verification, the generated intermediate code becomes a maintenance liability of its own, and the programme's first milestone delivers no business capability at all.

This release removes the assumption. The platform now ships its own implementation of Informix 4GL as a GraalVM language built on the Truffle framework — registered, resolved and executed as a peer of the JavaScript, Python and Groovy already running server-side. The 4GL that runs in production is the 4GL under version control. There is no transpilation step, no generated Java or JavaScript to maintain alongside the original, and no second source of truth.

A language implementation, not an emulation layer

• Built on Truffle. The 4GL front end and runtime are implemented as a Truffle language, so the language is executed by the same infrastructure GraalVM uses for every other language it hosts, rather than by an interpreter bolted onto the side of the application server.
• One runtime, one process, one heap. The language implementation shares the host process's Truffle runtime and GraalVM version rather than embedding its own. A 4GL program and the JavaScript that invokes it occupy the same process and the same heap, with no serialisation boundary, no subprocess and no inter-process call between them.
• Compiled, not merely interpreted. Because execution goes through Truffle, 4GL benefits from the same partial-evaluation and just-in-time compilation that GraalVM applies to the languages beside it: hot business logic is compiled to native instructions at run time.
• Resolved by name. A program is declared as <script type='4gl'> and is also resolvable as i4gl, fgl or informix-4gl, so existing naming conventions carry across. Resolution of the other script languages is unchanged.

Executing inside the caller's transaction

• On the lent connection. A 4GL program executes on the physical database connection lent to it by its caller. It opens nothing of its own and closes nothing it was lent, so its statements sit inside the caller's transaction and draw on the caller's pool.
• Demonstrated, not asserted. The regression suite proves the property the way it has to be proved: a 4GL cursor reads a row the caller inserted and has not yet committed. Only a program on the caller's own connection can see it.
• No DATABASE statement required. A lent connection is already attached to a database and is the only one the program can reach, so the declared database name is redundant and the catalogue is read from the connection itself.
• Governed like everything else. Because the work happens on the platform's connection and inside the platform's transaction, 4GL inherits the pool management, the security perimeter and the audit trail that govern the rest of the runtime.

The constructs the language is actually made of

• Cursors. Cursor declaration and iteration, host variables bound at open and re-bound on re-open, and manual open, fetch and close — with an exhausted fetch leaving its targets untouched, as the language specifies.
• Records from the live catalogue. A record declared LIKE a table takes its members, their order, and each member's width and scale from the catalogue on the lent connection. Order is load-bearing: a record built in the wrong order binds positionally and puts the right value in the wrong column, silently.
• Reports. Report blocks execute, so the reporting logic that accompanies the business logic moves with it rather than being rewritten separately.
• A server has no terminal. Screen interaction has no meaning in a server process, so terminal output is directed to the server's console monitor and captured with the rest of the runtime's output.

Reachable from the platform's tooling

• The standard execution path. The script parser and the connection listener both recognise the 4GL type, so a 4GL program participates in the platform's ordinary script execution path with no special-case wiring around it.
• Edited in the workbench. The browser-based query editor provides 4GL language support and type definitions, so the code is read and written alongside the rest of the server-side code.
• Errors that cross the boundary. The script exception type gains methods for classifying and re-raising failures, so a fault inside a 4GL program reaches the surrounding logic with usable detail rather than as an opaque failure.

The strategic consequence is a change in sequencing. Modernisation no longer has to begin with the riskiest, least visible work: the data tier, the metadata model, the user interface and the integration surface are modernised while the business rules keep running as the 4GL they have always been, on a supervised runtime, in-transaction, under one security and audit model. Rewriting a given program becomes a decision taken on its own merits, at a time the organisation chooses, rather than the entry fee for modernising anything at all.

See the feature →

← All posts