Plain English Programming
(Stub details: Search for FIXME and TBD.)
This page relates to Plain English Programming as developed by the Osmosian Order of Plain English Programmers. Notes primarily pertain to the CAL-4700 standalone IDE and compiler. There is at least one other version, Folds/english on Github, which forked off from an earlier version. Differences should be noted where applicable. The overarching difference is that Folds/english looks and acts more like a native Windows program. CAL opens fullscreen on the main monitor and looks like an OS with its own unique design and standards, although it relies on MS Windows underneath.
Far from "Hello, world," the first thing a user learns to do with CAL is recompile CAL itself. Then, the user is walked through making an app which takes a string, downloads an image from Google Image Search, and renders it in the style of famous painter Monet. It's a rather broad introduction to the language's features.
Español Llano is a closely-related programming language. (FIXME: Perhaps a Spanish-speaker might be able to find a link?)
Note that a sense of humor will be an advantage when reading CAL's instructions.
Language
The language and its documentation are almost entirely free of jargon and symbols other than a subset of English punctuation. Only the period, comma, colon, and semicolon are commonly used. The minus sign functions as a unary minus for negating variables.
The Order's blog makes a case for the language being no more verbose than C or C++. This assumes you're a good typist, finding whole words no more trouble to type than symbols. (eekee agrees because he finds using the shift key rather uncomfortable.)
"Not" and the suffix "n't" are recognized and understood as you'd expect.
Some words are ignored. Development of the language started with the realization that human infants ignore a lot of words when they're starting to learn to understand language.
Specifying parameters is more verbose than in human English. Example: a number and another number and a third number and a fourth number. It could be shortened, but typically, you set up a structure and pass that to a routine. For instance, you set up a box and then "Draw the box with the black color." Routines with more than 2 parameters are rare in CAL.
Wording tends to differ from English in some other ways too. For example, "Draw the box with the black color", rather than "Draw the box in black." FIXME: check if "in/into/to" is interpreted differently from "with". If not, the latter example is possible.
It has a strong type system and checks types strictly -- perhaps a little too strictly. "A buffer is a string", the compiler is told, and you can "Read the file into a buffer", but you can't "Read the file into a string." (The instructions are wrong on this point.) eekee intends to raise the issue with the Order.
Definition order doesn't matter. (The Order likes to sort definitions by name and rely on incremental search to find them.)
Types
FIXME
Routines vs. Functions
Like C functions, routines may take parameters and return values, but unlike C functions, they may not be part of an expression. You call one routine per line.
Functions may be part of expressions. Function calls may even look like references to structure elements. In that regard, they seem similar to the methods of a pure OO language but the instructions recommends using them sparingly. FIXME: include instructions example of "the box's bottom line".
Compiling with CAL
The compiler, text editor, "finder", and a document editor are all integrated into a single binary. Compilation is triggered by the Run menu entry or Ctrl-R in the text editor. All the files without an extension in the current directory are combined and compiled. The resultant Windows executable is then run. As it stands, this doesn't seem suitable for OS development at all, but CAL's subsystems are, on the whole, simple and easy to modify.
Cross-compiling (other x86-32)
CAL is a very stand-alone sort of program, so producing a cross-compiler is as simple as it can be. Modify the compiler to output the required format, compile this with an unmodified CAL, and you have a cross-compiler. The standard library (called the noodle) is compiled with every program, so there are no complexities in modifying or even recreating it for your target. (Maintaining a consistent version of it is trickier.)
Cross-compiling (CPU)
Re-targeting the compiler and standard library requires producing some machine code in hexadecimal form. This is more likely to be long than complex as few x86-32 instructions are used, only 52 if I (eekee) remember right. The machine code in the standard library exists primarily for optimization. (The longest hexadecimal string in the source is not code, but a TrueType font.)
A 64-bit architecture would be desirable to use more than 2GB memory. Yes, that's 2GB not 4; CAL doesn't do unsigned numbers.
Porting CAL
CAL looks like an OS with its own design and interface standards. Internally, it wraps Windows calls to present neat, simple interfaces for files, images, vector graphics, GUI, and HTTP. This all suggests porting it to "bare metal" to make it an OS. How much work would be required? Is it a desirable goal? This section attempts to answer these questions.
Low-level
Numbers FIXME: signed integers only, no floats, ratios, smaller integers available, characters are bytes.
Memory allocation evidently incorporates some clever ideas such as storing strings in their own region. How much complexity is required from the underlying OS and libraries is TBD.
Files TBD
Network TBD
Execution Model is perhaps the toughest point. CAL is a single-tasking executable which runs as a single task with a single memory space. Not very OS-like! On the other hand, when you switch tabs or open something from the finder, it appears to switch programs instantaneously. This design seems suitable for a limited-purpose system, but many OS developers will want to add program loading and other features.
Display
CAL is capable of rendering images but draws everything of its own with vector graphics. It relies on Windows library calls to render these vectors. It also has drawing routines which are essentially turtle graphics, but only straight lines are implemented well.
The coordinate system works entirely with integers. The basic unit is the "twip" which is 1/20th of a printer's point. Inches and other units are converted to twips, which in turn are multiplied by a number derived from the PPI (pixels per inch) setting to produce pixel coordinates. Rotation may be specified in degrees or fractions of a circle.
Font rendering deserves special mention. As supplied, CAL depends on Windows libraries for rendering fonts, even the one bundled in to the binary. However, it has routines for drawing all 96 ASCII characters with its own turtle graphics routines. It's a simple old-school plotter font. Do note that it is possible (but not very likely at all) they will need fixing because the compiler doesn't fully syntax-check routines if it can't find a code path to them.
License
Links
- osmosian.comVery little content, just a semi-humorous slideshow and a link to the manifesto. (This server also hosts downloads.)
- The Osmosian Order's blog -- eekee recommends this as an introduction, but note some of the example code is a little too out of date to compile, or perhaps omits some routines. You'll need to write some code.
- Download - search the blog to get the latest link.
- Folds/english on Github
- Instructions (PDF) - a little out of date. There's a newer one included in the download, but it's in CAL's native document format. (It can be exported as PDF.)
People and OSs using PEP
- eekee says, "I'm very happy to find a language which circumvents my problems with jargon and symbols. I can just read CAL's code without getting confused. I'm also happy with its simplicity and extensibility."