Web Hosting by Netfirms | Free Domain Names by Netfirms

Introduction

QDL is a language I developed because... well, I just felt like it. I like C++, but I figured it was worth trying to improve on. I developed it using mainly C++ as a base, with the following ideas in mind:

• Ease of Learning
  • QDL should have a less cryptic syntax than C++, and a more consistent syntax than BASIC
  • Programmers should need less knowledge to get started writing something useful
• Rapid Application Development
  • Less code should be required to set up an application
  • High-level class libraries
• Readability - by both people and computers
  • Source code scanners should be able to easily determine code structure
• Versatile, Elegant, Extensible Syntax
  • Highly customizable function-call syntax
• Powerful OO
  • QDL should have all the OO features of C++
• Potentially High Execution Speed
  • It should be possible to match the speed of C++, given similar optimization techniques.
• Portability
  • Language is portable
  • Standard libraries should be platform-independent to the greatest possible degree, without sacrificing advanced functionality such as windowing (modern GUIs), multimedia and networking.
• Platform-dependent features
  • Many modern OO languages suggest that if you want to do low-level stuff you should write it in C and use some awkward method to link to the C code.  This disagrees with me: why should you have to learn two languages, and worse, have to try to figure out how to get them to interface?  For the (hopefully rare) cases where platform-dependent code is required, the programmer should not have to resort to using another language.
  • Interfacing between QDL, C, C++, and/or dynamic-link libraries should be possible (though it's not important in the first language release.)
• Raising the Bar for the standard library

  In any computer language, the interface to a library of classes/functions (a "package" of code) is typically built upon the lowest common denominator in the language for which it is designed.  For example, a C library will pass strings around using primitive char arrays, and manage dynamic-sized arrays with malloc(), realloc() and free().  This is because doing things in a non-standard way can alienate potential users of the library.

  • The standard library should be powerful, easy to learn, easy to use, well organized, extendable, and based on modern programming principles such as object-orientation.
  • The standard library should contain enough capability that programmers need not:
    • Reinvent the wheel for commonly-used high-level data-management schemes: e.g. dynamic arrays, linked lists, and multithreaded access control mechanisms.
    • Call underlying OS functions for actions available on more than one platform: e.g. GUI window management, sending files to the recycle bin/trash can/rubbish shute
• Orthogonality and generality.
  • Different parts of the language should follow similar patterns of syntax or philosophy
  • Any given feature of the language should have as many logical counterparts as possible (orthogonality)
  • With any feature I considered putting into the language, I tried to think of a more general feature with more potential.
• Scalability
  • QDL should be suitable for development of just about anything--tiny scipts, device drivers, or vast things like, say, MS Windows 2010

C has been called a "high low-level language." With QDL, I've aimed to make the language as low-level as C, but also make it more feature-filled than C++, as high-level (and "pretty") as Visual Basic (but less verbose), and less bloated than C#.

How well did I succeed? Read on an decide for yourself!

I haven't written this documentation how a professional languagographer, or whatever they are called, would. Rather than formally describing the language with a grammar, this documentation is written with the aim of helping you understand it. I've glossed over the formal C++ grammar. As well as being huge beyond reason (for those who have seen the movie, The Princess Bride: "The cliffs of insanity!"), it's hopelessly difficult to understand. I have written the documentation to be understood, more than to be complete or overly compact.

I often make comparisons to and contrasts with the other languages I know: structured BASIC, Pascal, and especially C++. By doing this, I can more fully describe the language without needing as many words; these other languages have already been completely defined, and by making references to them I can fully define QDL... This is called inheritance in programming-speak.

Conventions

In this documentation,

• New terms are introduced by italicizing them.
• Short literal segments of code are shown in boldface.
• Longer segments of code, and complete lines, are shown in separate paragraphs using a fixed-pitch font.
• Notes are shown in indented paragraphs.
• Occasionally, italics and boldface may be used for emphasis.

Some lines, such as this one:

if-statement: If expression Then (statement | block) [Else (statement | block)]

Define the syntax of some part of the lnguage. The conventions used in these lines are:

• Optionally, an italicized word before a colon at the beginning of the line gives a name to the language element following the colon.
• Characters to be typed literally are shown in boldface.
• Words to indicate the placement of other syntax elements are shown in italics.
• (x | y | z) is used to indicate the placement of one and only one of x, y, or z.
• [x] is used to indicate that x is optional.
• [x | y | z] is used to indicate the placement of one of x, y, or z, or nothing at all.
• <x> is used to indicate one or more of syntax element x, separated by commas. For example, <identifier> would mean a list of identifiers.
• + is used to indicate one or more repetitions of the preceding syntax element
• * is used to indicate zero or more repetitions of the preceding syntax element

QDL is generally case-insensitive; nevertheless, I recommend using the VB-like "MixedCase" style in which every word in an identifier is capitalized. That style will be used throughout this documentation.