The Pawn language - language and toolkit features

Skip to main content (skip navigation menu)
Letterhead logo

The pawn language

This product is made in the EU

Pawn's icon

An embedded scripting language

Language features


Toolkit features

section separator
Pawn's icon

Creating a robust language

The pawn language is designed with an audience of "non-expert" programmers in mind. Beginning programmers make particular kinds of errors frequently. Expert programmers do not just make fewer errors, their most frequent errors are also different than those made by beginning programmers.

The C language provided the basis for pawn; basically the ambition of pawn was to design a simplified and modified C in such way that pawn would avoid or circumvent the mistakes that novice C programmers make most frequently. The beauty of C is that the language comes of age and that it has been extremely popular. There is, hence, a wealth of experiences, both favourable and unfavourable, on the language. Many of the "holes" and culprits in the language are known. Make no mistake, designing a new language is no mean feat. The number of "deprecated" features in modern languages like C++ or Java shows that even seasoned language designers sometimes come to the conclusion that a feature once reckoned useful turned out to have severe shortcomings.

What are frequent (beginner) errors, and what does pawn do about it?

A note on single line comments
When you end a single line comment with a backslash in C, what happens? The backslash at the end of a line is the "line continuation" character of the pre-processor of C/C++. Two possibilities would be:

Two recent compilers for Microsoft Windows that I tried this on used the latter approach. In "The New C: About // Comments" (C/C++ Users Journal, July 2003), Randy Meyers writes that this issue is indeed ambiguous in C, but that the C++ standardizes the second approach. pawn uses the first approach and also issues a warning message.

If you read my note above on programming languages being difficult to design because features sometimes "bite" each other, I think this is an example of two such features (one old, one new). Both are useful in their own right, but combining them can lead to much confusion. This is not just a hypothetical, theoretical issue: a colleague once spent a few hours in tracking a bug where a single line comment happened to be extended over the next line. He claimed that the compiler did not issue any warning (when set at the highest warning level), the syntax highlighting in the editor did not recognize this special case. I have heard a similar story of another programmer.

What about pointers?
I read in more than one book on Java and in more than one description of other scripting languages that the language was "robust" or that it avoided bug-prone practices by virtue of not having pointers. Since I have experience in both teaching the C language (with pointers) at a novice level and in programming C at an advanced level, I think I can comment on this. Indeed, in my experience, novice programmers make a lot of pointer errors. To test myself in this aspect, I noted serious errors that I made during a two-day implementation of a new code that would be embedded into an existing application. I wrote over 500 lines of C code in those days. With "serious errors" I mean that I only counted those errors that caused invalid memory accesses. Logical errors and syntax errors were waved (the compiler catches syntax errors anyway).

In those two days, I made several array indexing errors, where the index was out of range, negative, or just garbage (uninitialized). I did not make any pointer mistake (as far as I know). There were approximately equally many pointer as array operations in the code. An interview of a colleague gave me the impression that pointers were not a major source of errors in his code either. So based on an amateurish empirical study with a population of a mere two persons, I dare to challenge the statement that, in general, pointers should be considered more harmful than arrays.

The pawn language has no pointers, but you won't catch me saying that, therefore, pawn is a robust language. The current implementation for the abstract machine for pawn performs bounds checking on array indices -if it knows the bounds of the array- and that makes it a little robust. The abstract machine also verifies that every indirect memory access stays within the address range defined for each program, which also gives pawn some robustness. But making a logical error in a mortgage calculation that'll cause you great misery is as easy in pawn as in any other language... with or without pointers.