xHarbour is a free, open source, multi-platform, dynamic, programming language, also available as a commercial distribution by xHarbour.com Inc. It is derived from the Clipper language which itself is a derivative of dBASE. As most dynamic languages, xHarbour is also available as a scripting language utilizing an Interpreter written in xHarbour language.

Built-in data types

xHarbour has 6 Scalar types ( Nil, String, Date Logical, Numeric , Pointer, and 4 complex types: Array, Object, Codeblock , and Hashes . A scalar holds a single value, such as a string, number, or reference to any other type. Arrays are ordered lists of scalars or complex types, indexed by number, starting at 1. Hashes, or associative arrays, are unordered collections of any type values indexed by their associated key, which may be of any Scalar or complex type too.

Literal (static) representation of scalar types:

• Nil: NIL

• String: "String", 'String', [String], or E"String\n"

• Date: Stod("2005-03-17" )

• Logical: .T., .F.

• Numeric : 1, 1.1, -1, 0xFF

Complex Types may also be represent as literal values:

• Array: { "String"", 1, { "Nested Array" }, .T., FunctionCall(), @FunctionPointer() }

• Codeblock : { |Arg1, ArgN| Arg1 := ArgN + OuterVar + FunctionCall() }

• Hash: { "Name" => "John", 1 => "Numeric key", { "Nested" => "Hash" } }

Hashes may use any type including other Hashes as the Key for any element. Hashes and Arrays may contain any type as the Value of any member, including nesting arrays, and Hashes.

Codeblocks may have references to Variables of the Procedure/Function>method in which it was defined. Such Codeblock may be returned as a RETURN Value, or by means of an argument passed BY REFERNCE , in such case the Codeblock will "outlive" the routine in which it was defined, and any variables it references, will be a DETCAHED variable. Detached variables will maintain their value for as long as a Codeblock referencing them still exists. Such value will be shared with any other Codeblock which may have access to those same variables. If the Codeblock did not outlive it's containing routine, and will be evaluated within the life time of the routine in which it is defined, changes to its Detached Variables(s) by means of its evaluation, will be reflected back at it's parent routine. Codeblocks can be evaluated any number of times, by means of the Eval( BlockExp ) function.

Variables

All types can be assigned to named variables. Named variables can be 1 to 63 characters long identifiers, starting with [A-Z|_] and further consisting from additional [A-Z|0-9|_] characters, up to 63 characters, which are not case sensitive.

Variables may have the following scope:

• LOCAL: Visible only within the routine which declared it. Value is lost upon exit of the routine.

• STATIC: Visible only within the routine which declared it. Value is preserved for subsequent invocations of the routine. If a STATIC variable is declared before any Procedure/Function/Method is defined, it has a MODULE scope, and is visible within any routine defined within that same source file, it will maintain it's life for the duration of the application life time.

• GLOBAL Visible within any routine defined in the same source module where the GLOBAL variable is declared, as well as any routine of any other source module, which explicitly declares it, by means of the GLOBAL EXTERNAL declaration. Both GLOBAL and GLOBAL EXTERNAL declarations must be declared before any Procedure/Function/Method is defined.

• PRIVATE: Visible within the routine which declared it, and all routines called by that routine.

• PUBLIC: Visible by all routines in the same application.

LOCAL, STATIC, and GLOBAL are resolved at compile time, and thus are much faster, than PRIVATE and PUBLIC variables which are dynamic entities accessed by means of a Run-time Symbol Table . For this same reason LOCAL, STATIC and GLOBAL variables are not exposed to the Macro compiler, and any macro code which attempts to reference it, will generate a Run-time error.

Due to the dynamic nature of PRIVATE and PUBLIC variables, they can be created and destroyed at Run-time, can be accessed and modified by means or Run-time macros, and can be accessed and modified by Codeblocks created on the fly.

Control structures

The basic control structures include all of the standard dBase, and Clipper control structures as well as additional ones inspired by the C or Java programming languages:

Loops

[DO] WHILE ConditionExp
   ...
   [LOOP]
   [EXIT]
END[DO]

FOR Var := InitExp TO EndExp [STEP StepExp]
   ...
   [LOOP]
   [EXIT]
NEXT

FOR EACH Var IN CollectionExp
   ...
   [HB_EnumIndex()]
   [LOOP]
   [EXIT]
NEXT

• The ... is a sequence of one of more xHarbour statements, and [] denote optional syntax.
• The HB_EnumIndex() may be optionally used to retrieve the current iteration index (1 based).
• The LOOP statement restarts the current iteration of the enclosing loop structure, and if the enclosing loop is a FOR or FOR EACH loop, it increases the iterator, moving to the next iteration of the loop.
• The EXIT statement immediately terminates execution of the enclosing loop structure.
• The NEXT statement closes the control structure and moves to the next iteration of loop structure.

In the FOR statement, the assignment expression is evaluated prior to the first loop iteration. The TO expression is evaluated and compared against the value of the control variable, prior to each iteration, and the loop is terminated if it evaluates to a numeric value greater than the numeric value of the control variable. The optional STEP expression is evaluated after each iteration, prior to deciding whether to perform the next iteration.

In FOR EACH, the Var variable will have the value (scalar, or complex) of the respective element in the collection value. The collection expression, may be an Array (of any type or combinations of types), an Hash Table, or an Object type.

IF statements

IF CondExp
   ...
[ELSEIF] CondExp
   ...
[ELSE]
   ...
END[IF]

... represents 0 or more statement(s).

The condition expression(s) has to evaluated to a LOGICAL value.

DO CASE statements

DO CASE
   CASE CondExp
      ...
   [CASE CondExp]
      ...
   [OTHERWISE]
      ...
END[CASE ]

Above construct is logically equivalent to:

IF CondExp
   ...
ELSEIF CondExp
   ...
[ELSEIF CondExp]
   ...
[ELSE]
   ...
END[IF]

SWITCH statements

xHarbour supports a SWITCH construct inspired by the C implementation of switch().

SWITCH SwitchExp
   CASE LiteralExp
      ...
      [EXIT]

   [CASE LiteralExp]
      ...
      [EXIT]
 
   [DEFAULT]
      ...
END

• The LiteralExp must be a compiled time resolvable numeric expression, and may involve operators, as long as such operators involve compile time static value.

• The EXIT optional statement is the equivalent of the C break; statement, if present execution of the SWITCH structure will end when the EXIT statement is reached, otherwise it will continue with the first statement below the next CASE statement (Fall Through).

BEGIN SEQUENCE statements

BEGIN SEQUENCE
   ...
   [BREAK]
   [Break([Exp])]
RECOVER [USING Var]
   ...
END[SEQUENCE]

or:

BEGIN SEQUENCE
   ...
   [BREAK]
   [Break()]
END[SEQUENCE]

The BEGIN SEQUENCE structure allows for a well behaved abortion of any sequence, even when crossing nested procedures/functions. This means that a called procedure/function, may issues a BREAK statement, or a Break() expression, to force unfolding of any nested procedure/functions, all the way back to the first outer BEGIN SEQUENCE structure, either after its respective END statement, or a RECOVER clause if present. The Break statement may optionally pass any type of expression, which may be accepted by the RECOVER statement to allow further recovery handing.

TRY [CATCH]statements

TRY
   ...
   [BREAK]
   [Break([Exp])]
   [Throw([Exp])]
CATCH [Var]
   ...
END

or:

TRY
   ...
   [BREAK]
   [Break()]
   [Throw([Exp])]
END

The TRY construct is very similar to the BEGIN SEQUENCE construct, expect it automatically integrate error handling, so that any error will be intercepted, and recovered by means of the CATCH statement or ignored otherwise.

Procedures/Functions

[STATIC] PROCEDURE SomeProcedureName
[STATIC] PROCEDURE SomeProcedureName()
[STATIC] PROCEDURE SomeProcedureName( Param1' [, ParamsN] )

INIT PROCEDURE SomeProcedureName
EXIT PROCEDURE SomeProcedureName

[STATIC] FUNCTION SomeProcedureName
[STATIC] FUNCTION SomeProcedureName()
[STATIC] FUNCTION SomeProcedureName( Param1' [, ParamsN] )

Procedure/Functionss in xHarbour can be specified with the keywords PROCEDURE, or FUNCTION. Naming rules are same as those for Variables (up to to 63 characters non case sensitive). Both Procedures and Functions may be qualified by the scope qualifier STATIC to restrict their usage to the scope of the module where defined. The INIT or EXIT optional qualifiers, will flag the procedure to be automatically invoked just before calling the application startup procedure, or just after quitting the application, respectively.Parameters passed to a procedure/function appear in the subroutine as local variables, and may accept any type, including references. Changes to argument variables are not reflected in respective variables passed by the calling procedure/function/method unless explicitly passed BY REFERENCE using the @ prefix.

PROCEDURE have no return value, and if used in an Expression context will produce a NIL value. FUNCTION may return any type by means of the RETURN statement, any where in the body of it's definition.

An example procedure definition and a function call follows:

 x := Cube( 2 )

 FUNCTION Cube( n )
 RETURN n ** 3

Database support

xHarbour extend the Clipper Replaceable Database Drivers (RDD) approach. It offers multiple RDDs such as DBF, DBFNTX, DBFCDX, DBFDBT, and DBFFPT. in xHarbour multiple RDDs can be used in a single application, and new logical RDDs can be defined from combination of other RDD. The RDD architecture allows for inheritance, so that a given RDD may extend the functionality of other existing RDD(s). 3rd part RDDs, like RDDSQL, RDDSIX, RMDBFCDX, and Mediator exemplify some of the RDD architecture features.

xHarbour also offers ODBC support be means of an OOP syntax, and ADO support by means of OLE.

xHarbour code samples

The typical "hello world" program would be:

 ? "Hello, world!"

Or:

 QOut( "Hello, world!" )

Or:

 Alert( "Hello, world!" )

Or, enclosed in an explicit procedure:

 PROCEDURE Main()
 
    ? "Hello, world!"

 RETURN

OOP samples

 #include "hbclass.ch"

 PROCEDURE Main()

    LOCAl oPerson := Person( "Dave" )

    oPerson:Eyes := "Invalid"

    oPerson:Eyes := "Blue"

    Alert( oPerson:Describe() )
 RETURN

 CLASS Person
    DATA Name INIT ""

    METHOD New() CONSTRUCTOR

    ACCESS Eyes INLINE ::pvtEyes
    ASSIGN Eyes( x ) INLINE IIF( ValType( x ) == 'C' .AND. x IN "Blue,Brown,Green", ::pvtEyes := x, Alert( "Invalid value" ) )

    // Sample of IN-LINE Method definition
    INLINE METHOD Describe()
       LOCAL cDescription

       IF Empty( ::Name )
          cDescription := "I have no name yet."
       ELSE
          cDescription := "My name is: " + ::Name + ";"
       ENDIF

       IF ! Empty( ::Eyes )
          cDescription += "my eyes' color is: " + ::Eyes
       ENDIF
    ENDMETHOD

    PRIVATE:
       DATA pvtEyes
 ENDCLASS

 // Sample of normal Method definition.
 METHOD New( cName ) CLASS Person

   ::Name := cName

 RETURN Self

Scripting

xHarbour is also available as an interpreted language in few flavors of scripting engines.

• Stand alone Interpreter: Portable, self contained, interpreter xBaseScrript .

• ActiveScript: Microsoft ActiveScript compliant OLE Dll, which supports xHarbour scripting in:

* Windows Script Host (WSH).
* Internet Explorer, HTML client side scripting.
* IIS, and any other ASP compliant server.