File Format

Sling source code files are text files saved using the UTF-8 encoding. Files are composed of a multitude of characters that are organized as a linear collection of "lines" (sometimes also called rows) that are separated by newline characters (NL or character code 10 or 0x0A). CRLF line feeds are NOT valid in Sling source code, and the CR (character code 13 or 0x0D) must not be present. The SAM compiler does accept the presence or CR characters, but will print a warning for each instance, and subsequently ignores them.

Use of semicolons

As a matter of legacy, Sling supports the use of semicolons as statement separators, and allows them to be used to also place several statements on a single line. However, semicolons are not required, and it is also strongly discouraged to use them where it is not necessary. Rather, Sling uses the newline characters at the ends of statements as statement separators, making semicolons unnecessary. Wherever a semicolon is found at the end of a line, the compilation will still proceed, but the SAM compiler will issue a warning.

See below for a sample. This is completely valid Sling code, but produces warnings upon compilation:

func doSomething
{
	var n = 10;
	if n < 100 {
		PRINT String.forInteger(n);
	}
	n ++;
}

The following is a fully equivalent program, but compiles without warnings:

func doSomething
{
	var n = 10
	if n < 100 {
		PRINT String.forInteger(n)
	}
	n ++
}

Using curly braces

As a matter of syntax, logically related statements in the code (labelled "blocks") are grouped together by the use of curly braces "{" and "}" around the statements. This is used in practice as follows:

if n < 100 {
	PRINT String.forInteger(n)
}

However, since in the above example the code block contains only one statement, the curly braces can be optionally omitted and replaced with the colon (":") syntax, as follows:

if n < 100:
	PRINT String.forInteger(n)

Either one of the two MUST be observed. The following is NOT legal Sling code (although programmers coming from other languages may be used to it):

// This is not legal
if n < 100
	PRINT String.forInteger(n)

// This is also not legal
if n < 100 PRINT String.forInteger(n)

Note also that the colon-based "shortcut syntax" is only allowed for single-statement blocks. The following (Python style) code is NOT valid Sling code:

// This is not correct
if n < 100:
	PRINT "Look at this:"
	PRINT String.forInteger(n)

This should always rather be written as:

if n < 100 {
	PRINT "Look at this:"
	PRINT String.forInteger(n)
}

The colon-based "shortcut syntax" is accepted in all places where a code block is normally used, including function declarations. The following function declarations are equivalent:

func getNumber
{
	return 10
}

func getNumber:
	return 10

Empty lines

Syntactically, the Sling language does allow the programmer to insert empty lines anywhere in the code in order to group the code in a manner of their choosing. The empty lines are not considered as part of the program in any way, and do not affect functionality. However, for the sake of consistent and good code formatting, Sling strongly discourages excessive use of empty lines, and provides compiler warnings when it detects non-recommended use of empty lines. Notably, the compiler encourages the programmer to follow these guidelines:

• There should never be more than one consecutive empty line, anywhere in the code.

• Inside functions, there is no need to place empty lines in between statements. However, blank lines between function and class declarations are encouraged for clear readability.

• Comments (see below) may be surrounded by blank lines in order to give them emphasis, to increase readability and to provide the appropriate "rhythm" for the code.

Indentation

As is also common with other languages (with the notable exception of Python), indentation does not affect the functionality of Sling programs. Rather, proper indentation is done to write readable code that can be understood by human beings, and that can be easily enhanced and edited further.

However, the SAM compiler does care about indentation. While it does not affect functionality, and even programs with bad indentation do compile, the compiler issues warnings of all instances where indentation is not compliant to the standards. The following rules are observed by the compiler:

• Only tabs are used for indentation, never spaces.

• At the beginning of the file, the indentation level starts at 0 tabs.

• Each instance of the tokens "{", "[" or "(" increase the indentation level by 1. However, if several of these characters appear on a single line, the indentation level is increased by only 1.

• Consequently, instances of tokens "}", "]" and ")" decrease the indentation level accordingly.

• The presence of "extendable tokens" at the ends of lines will likewise increase the indentation level temporarily for the following line only. Extendable tokens are usually operators that are used in long expressions that extend to several lines. Currently, the extendable tokens are "..", "+", "-", "&&" and "||".