Demo of ICL Naming, Infix Parsing (Note Dual Level Syntax for Error Checking)

Among the idiosyncratic concepts in the language are some perspectives on variable naming and traditional computational syntax. Naming of process variables follows a number of industrial traditions which can require large tags and unusual forms. ICL allows the most flexible naming possible: large names, duplicate names (e.g. a large meaningful name with an abbreviation name for convenient use), initial digits (as long as letters are later included), single included spaces (represented in display by underscores). This is supported by automatic separation of unambiguous names and digits by single spacing, or by double spaces when necessary (in this case always displayed as a single space).

The language assumes two related user visual forms: an input script and the display form. The script is a necessary means for entering programs and their editing, without the graphic complication. The display form is the real language representation, self-documenting the working program. Related to these two forms is a concept of two levels of parsing so that the type of statement is recognized before and independent of its accuracy. In ICL it is possible to have a wrong statement as well as a correct one! This helps debugging.

Traditional computational statements and expressions are to be represented in ICL using a generalized (largely conventional) infix format which is converted to reverse polish form internally. Every aspect of the language is intended to be compiled to a p-coded form for more efficient execution, but one which is back compilable allowing user access to the actual original language text. Every aspect of the working program should be highly readable to the working user.

This page describes a down-loadable demo of these concepts including a rough user's guide.

Demo User's Guide

The rough User's Guide here expands on the list of commands displayed in the demo before each command entry. When the Demo file below is decompressed the result is a PC (DOS!!/Windows) executable named infix.exe. Its original purpose was to demonstrate routines used to process the conventional assignment statements and infix expressions in the language implementations. It also demonstrates the above naming conventions and initial simplified parsing and its effects on name processing. The demo commands and demo syntax do not reflect the ICL ease of use concepts! The input and command line commands are entered and then terminated with a Carriage Return/Enter key.

=: Enters input character string.

The following input is (display) echoed and then saved as an input string (also echoed).

clr: Clears variable/value tables.

The variable/value table is cleared , echoing the command and displaying: "Cleared".

lex: Lexical processing of input string to Token string.

The already entered input string is "lexed" into its component words in a Token string. The command is echoed followed by the input string, a Token type-code* string and the Token string itself, with each Token name enclosed in brackets. A final line shows the variable/value table with new variables entered following the ")*(" separator each with an arbitrary assigned value. For example:

Output from the command: lex.

* The symbol @ means a variable, ! means an operator, % means a function. Incidentally, the parser (and probably ICL) treats normal use of parentheses as having an associated dummy unity function, so that simple parentheses and functions with associated operand parentheses are coded and processed the same way.

rpolt: Compiles Token string to Polish string.

The already lexed Token string is parsed into the Polish string. Success is indicated followed by the Polish string set off by a "Rpol from lexed tokens" line header, and by the variable value table. On failure, this is indicated followed by the Polish string with an indication of the point in which the parse failed. The language design presumes an implementation in which all program elements are compiled to a more efficient, stored, but back compilable, p-coded form. Infix computation are thus to be compiled to p-coded reverse polish form.

The demo includes the operators: +, -, *, /, and ^, and also the functions: sin , cos, ln, and exp, all treated normally. Applied to the earlier token string:

Output from the command: lex.

rpoll: Compiles input string to Polish string, lexing on the fly.

This is the same as rpolt except that it compiles directly from the input string including the lexical processing before parsing.

bacom: Back Compiles the Polish string to Bacom string.

This Back Compiles a previously parsed Polish string indicating the success and displaying the result. ICL depends on all internal representations being back compiled to provide listings that can directly display the users original intent in a standardized pretty printed form. In the demo, the individual token symbols are still set off in square brackets. From the earlier reverse polish string:

Output from the command: lex.

polint: Interprets Polish string.

This computes and displays the result of computing the value of the Polish string.

infintt: Interprets Token string.

This computes the value of the Token string bypassing any Polish compilation. Although the language envisions compiled execution not interpretive computation, the routines were included for completeness; there may be some subordinate use for them.

infintl: Interprets input string, lexing on the fly.

This computes the value of the input string lexing on the fly and bypassing Polish compilation.

dsort: Incomplete distribution of Polish string to Dist string.


dtop: Move Dist string to Polish string.


stop: Exit program.

Exits program.

<variable> = <infix expression>: Carry out assignment.

Illustrates the usage in an assignment statement. For example:

Default (no command): Lexical processing of input string.

Accepts the line input and lexes it according to the ICL naming rules.

In addition to operators and function names, the demo has predefined two main key words ("ramp" and "wait") and nine secondary keywords ("from", "to", "in", "sec", "min", "hr", "sec", "min", "hr"). "ramp" and "wait" (All lower case although in ICL these are spelled in capitals. RAMP and WAIT set of two forms of ICL "Theme Statements" represented by these two examples: "Ramp from 10 to 100 in 20 min." and "Wait 2 hrs.". These keywords are included just to illustrate the lexical and simplified parsing interaction; none of the other commands make use of them.

As an illustration of the interplay of the simplified parsing and the naming conventions, the demo can be used to show that the statement "ramp from ramp start to ramp end in ramp time" will be lexed into "ramp from ramp_start to ramp_end in ramp_time" with the keywords "ramp", from", "to", "in", and "min" pre recognized in such a way that the three variables: "ramp_start", "ramp_end" and "ramp_time" can be recognized as well without confusion. The other parsing functions have no other action in this special example statement demonstration.

The routines making up this demo are based on standard methods with a few twists. I am happy to provide the code to anyone, but it represents my first C efforts, using an early quasi interpretive C package, many years ago, and was experimental in a number of ways that made it even worse. You probably won't want to see it!! But if so, here it is!!


The Demo consists of compiled C program displaying a set of options on a simple console display and calling underlying Language routines to make various parsing actions. The demo terminates with a 'stop' command.