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;
  b
    ln('hello');
  e.

While I really love Qomp, I have trouble with this "Hello World" program. When I run it in my QompInterpreter?, it just returns "hello". Is my interpreter at fault? -- QompUser?
- Thank you for the bug report, QompUser?. We shall call it a "hello" program in the QompManual?. "Hi" would be even more concise... so we may even change it to a "Hi" program.

A hi program:

  b
    ln('hi');
  e.

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;
  b
    ln('The result is five');
    res =. 5;
  e;

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

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

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:

http://z505.com/qomp/index.htm

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.

Why have you chosen not to use the (reasonably) familiar := digraph for assignment? DeleteWhenCooked
{I expect he wishes to avoid requirement to tap the 'SHIFT' key as would be required to strike the : character. Can't say I like his choice for replacement ('a =. 0.0' just looks too strange to me), but this is his language and I'll never need to use it.}
Doesn't look strange to me as we use spaces. In these situations such as s =.'string' it doesn't require a space. On dvorak, qwerty, and some international keyboards the dot is more accessible. The dot is less obtrusive than :=, however I will consider this feedback.
{Being a little 'obtrusive' is probably a GoodThing when comes time to visually distinguish assignment from boolean comparison. If you wanted, you could always take the context-sensitive approach ('=' assignment or test based on whether in procedural statement vs. value-expression) or the ColorForth approach ('=' red or green based on... ;)}
The context sensitive approach (i.e. without colors or without two signs) makes it confusing I think - as it merges the operator as if it is addressing the same problem. As for ColorForth, it reminds me of a pink floyd album (and maybe some LSD and Acid).
As a point of clarification, the use of color in ColorForth is precisely to reduce the dependency on context in the language. Context sensitivity is constrained to the problem's specific wordset only; the language's imposition of context (e.g., are we compiling or interpreting? What numeric base are we currently in? Etc.) is removed. --SamuelFalvo?
Can I change the color of words in the editor? Or does the compiler pick this up automatically? I.e. the compiler doesn't actually have knowledge of any colors, it is just binary to it.. and can the human control the colors or is it all just passive visual cues (rather than active ones I can adjust)? Can I try ColorForth to blow my mind, on BSD, Linux, or Windows?
You control the color of the words in the editor. The compiler actually takes its cues from your color selection. More precisely, the compiler is aware of a 4-bit tag on each word, which tells the compiler how to interpret its role in the program. The editor merely chooses to map tag values to colors. There are versions of ColorForth for Linux (not sure about BSD though) and Windows. I am most familiar with the Linux version, found here: http://colorforthray.info/XcolorForth.tar.gz . However, I must warn you -- this will be quite foreign. The default level of abstraction ColorForth presents to the user will be comparable to programming an Apple II with its built-in ROM monitor, and you don't know its machine language. If you'd like, I'd be happy to whip up a "type this program in and run it" type tutorial, kind of like the computer magazines from the 80s, with some dialog explaining what I'm doing, and why. --SamuelFalvo?

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

Syntax: "studies of the rules for forming admissible sentences" -- wordnet.princeton.edu/perl/webwn
Syntax: "the grammatical arrangement of words in sentences" -- Google Define

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:

http://www.gobosoft.com/eiffel/syntax/notation.html

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.

CategoryProgrammingLanguage