Qomp Language

This page describes the Qomp language.

The long name for the language is Qompute. In lowercase, qomp is interesting since the "q" and the "p" in lowercase are mirrors of each other, depending on your font. This odd name for a language was chosen on purpose.

A hello world:
  prog example;

A hi program:

The prog directive is optional since it is redundant (standard pascal fanboys will bitch about this). A program file should be named with file extension .QP, while a module (unit) should named with extension .QU (but this isn't mandatory, just recommended file naming scheme).

Small program to execute a process and reuse existing modules:
  prog execdemo;

use sysutils; // import a PPU module written in another language, fpc

pro err(msg: astr); v s: astr = 'Error: '; // declare and initialize a string b s =. s + msg + ' exiting'; // concatenate ln(s); // msg written to standard out halt; // stops program e;

pro checkparams; b if arg(1) = '' do err('must specify command line param'); e;

b checkparams; if not executeprocess(arg(1)) do err('process execute failed'); e.
A function looks like:

  fun foo: int;
    ln('The result is five');
    res =. 5;

Or one can use a return style of programming instead of the result variable.

  fun foo: int;
    ln('The result is five');
    ln('This here is not executed! Above is like a return statement in Cee');

The most interesting useful (compilable) program is the meaning of life:

  prog answer;

fun life: cardinal; b rep randomize; life =. random(life) til life = random e;

b ln(life); e.

Information on Qomp will be available at:
Recent updates:

Qomp notation/syntax is now revised. After long thinking and BigDesignUpFront.. I've decided to keep the round brackets with function(launching) instead of using square brackets. I realized it is better for migrating old Cee and Algol style code (and/or migrating the eyes to read the two codebases). I like the roundness (and so do most people) of function launchers.

The outln() has been changed to ln() while out() remains. Standard out can be used often, and must remain extremely convenient to use (more convenient and elegant than ugly hacks such as printf("\n") in Cee.

The equality sign will be = and will not be ==. After reading some more harsh words from well known computing scientists I simply cannot bastardize the language into a Cee like form, confusing equality with assignment. Equality will remain mathematical in qomp, using the = operator.

Assignment operator is =. (period proceeding equal sign). Slightly different than than Algols := sign.

The reserved words prc and fnc were changed to pro and fun during these past months. Most often used reserved words in Qomp are usually 1 or 3 characters long so they line up with indentations consistently (as opposed to having some even and some odd length keywords, which screws up indentation.. trust me, BeenThereDoneThat in bulky Pascal with its notation/syntax).

Repeat loops use rep and til as reserved words (repeat until).

Dashes in identifiers - I heavily debated with myself about this - dashes make it harder to interface with C libraries (lisp uses a macro to map dashes to underscores, for example). As of 2008, I've decided to release the first compiler without dashes in identifiers to keep the language more math-like and more interface-able with Cee language. This may be permanent.

Access to command line parameters is via the arg() function, to make it simple.. similar to ARGV or paramStr() in other languages.

I'll have a release of the first Qomp compiler very soon. I have to make an installer for the compiler still yet.

Syntax And Notation Definitions?

While designing Qomp, I came across the idea that maybe people (including myself) confuse Syntax with Notation (and with words) - or maybe syntax and notation are so related that we can discuss this in a WhatsaLanguage pissing match ;-). I looked up the word notation and found that it means symbols, but not neccessarily words (since words, are less symbolic - but what about chopped down words?)''

Anyway, semantics, syntax, notation - all refer and relate to each other indirectly/directly during discussions. Computer languages seen to be more than just languages (they aren't languages?). They are almost like communities/systems/notations/syntaxes/semantics/words/english combined.

My conclusion is: a computer programming language is not just a language! It's more than that.

When people refer to syntax - it seems many times they are also referring (maybe mistakenly, including myself) to notation and words too. For example, I now consider chopped down reserved words a notation and some words just words (not notation, as full words aren't notation - maybe). I suppose b and e are notation, whereas a word like while is a word. But really is this notation too? It's a word, not a notation. Hmm. Is not all this really about syntax as a whole? Possibly, however syntax seems more worried about sentence structure and relationships amongst the words, rather than the actual words and symbols used. Still, people generally seem to group a lot of things into the syntax group, just by habit, including myself. It's a nitpick - and hard to draw the lines - because one could consider b a reserved word, or they could consider it a symbol, letter, or notation. The notation b also happens to semantically mean that this is the beginning of a code block - but one could redefine it in some languages to mean something semantically different (overload it). Then the language may have redefine-able semantics. Syntax, notation, words, letters, symbols, English, sentences, are all related in one big TurdFanCollision.

Unless the distinction between 'syntax' and 'notation' is somehow relevant to how we produce and process a particular programming language's source code, most discussion on the matter is moot: using the two distinct words won't allow you to learn anything new or impart greater information, and any distinction you attempt to make would likely be arbitrary, informal, and confusing (much as you seem to be experiencing when attempting to make the distinction regarding Qomp). My own recommendation is to focus on process and product - pick and use the words that allow you to make formal distinctions, such as 'syntax' referring to how structure is grabbed out of source-code by a distinct 'parse' phase (in languages that possess such a phase), and 'semantics' referring to how these structures are then evaluated or interpreted. Perhaps if a particular language had a formal concept of 'words' being distinct from other symbols, or supported distinct modes of writing for distinct purposes, you'd find good opportunity to distinguish 'syntax' from 'notation'. At the moment, I'm not seeing much value in it.

Syntax seems to be more sentence/grammar related - words are used in sentences but do not seem to make up syntax. In programming and music, notations and symbols are used - in addition to words. So add another one to the pot: symbols.

Quote Can you find an example of a programming language where 'symbols' are formally and meaningfully distinguished from 'words' at the parser level? I'm curious as to what value you see in this distinction within the context of existing programming languages.

In the documentation for humans, we many times see languages defined with their reserved words and symbols (== - + *). Sometimes reserved words can be reused in code as identifiers where symbols cannot. Sometimes a reserved word looks much like a symbol, such as b and e. It's either a reserved letter, or kind of a symbol, or a bit of both.

To add more confusion: punctuation could be another term to describe parts of the programming language. For example: a comma, dot, or curly brace could be considered programming punctuation, but I can't recall hearing that term coined before (although it may be out there).

The point is - there are not perfectly clear OnceAndOnlyOnce style definitions and terminology for the complex topic of language. What we should call this, or what we should call that isn't always crystal clear. Sometimes we have an overlap. Punctuation involves symbols, and/or vice versa. Words can act like symbols. Letters can too. But they don't have to. Sometimes they could, sometimes they might not.

Here is a page about Eiffel symbols vs reserved words: A short form word such as MOD or DIV could even be considered a word and a symbol. However, when we parse someFuncMod and someFuncDiv the compiler should not choke up on the Div and Mod in the identifier - because they aren't really symbols - they are just letters that make up a word, which should be allowed in an identifier. someFunc* and someFunc+ would cause a compile error since a word cannot be composed of symbols (yet it can contain DIV and MOD, and yet an identifier could contain underscore "characters" or "symbols").

The distinctions may rather academic and useless when it comes down to a JustDoIt attitude, or it may have something to do with the growth of the large English languages which is growing even larger with time.
See also QompItself, QompItselfReactions, WhatsaLanguage


View edit of February 13, 2011 or FindPage with title or text search