Special Characters

Sometimes esProc strings, like the field names in a table sequence, contain special characters that may cause ambiguity of the expression. This section explores how to resolve this kind of ambiguity.

5.4.1 Special characters in strings

A string may include various signs, some of which could be problematic. The following are the possible problems when using certain signs in constant strings. For example:

	A	B	C
1	=,>,<,+,-	===== dividing line =====	>100
2	/ is division sign	34.55	end

Strings in A1 and B1 beginning with "=" will be interpreted as wrong expressions instead of constants if they are entered directly in cells, and will cause errors in computation. The string in C1 beginning with ">" won’t be handled as what it is; instead the cell will be regarded as an executable cell. The string beginning with "/" in A2 will be treated as a comment statement when written directly in the cell. The constant in B2 will be parsed automatically into an integer instead of a string. Being a reserved word, the string in C2 also won’t be handled as a string constant. Among these cells, only B2 has a value; but the value is not of string type.

The above problems that string constants cannot be identified correctly are caused by two factors. In most cases the string itself is ambiguous, in other cases the string’s first character is a special one, such as "=", ">", "/" and etc. In esProc, you just need to add a single quotation mark (’) before the string constant to make it recognized normally.

	A	B	C
1	'=,>,<,+,-	'===== dividing line =====	'>100
2	'/ is division sign	'34.55	'end

Values of A1, B1 and C1 are shown below. The single quotation mark at the front serves only as the mark of a string constant cell, but it won’t appear in the value:

   

Below are values of A2, B2 and C2. Data in B2 is left-aligned, showing it is of string type:

   

Since a string used in an expression should be surrounded by double quotation marks (like "…"), the above problematic strings won’t cause ambiguity when used in expressions. But for a string containing the double quotation mark " in it, you need to put an escape character \ before " to interpret it literally; the same with the slash \ used in a string. For example:

	A	B	C
1	="===== dividing line ====="	="/ is division sign"	="34.55"
2	="\"How is Frank?\" he asked."	=$[$\{B1}"C:\\test"]	=$[${B1}"C:\\test"]

In the cellset, A1, B1 and C1 enclose the special strings mentioned in the above with double quotation marks to remove ambiguity and parse them as string-type data. Here’re their values:

   

The string in A2 includes double quotation marks, each of which should be preceded by an escape character. An escape character also needs to be escaped with a slash \. Here’s A2’s value:

B2 uses the format of $[…], instead of the double quotation marks, to represent a string. In this case, the double quotation marks won’t cause ambiguity and escape characters are not necessary; but an escape character is still needed for the slash \. Note that here is another problem about the string constants: As a macro in the format of ${…}is allowed in a string constant, an escape character should be added to distinguish the string from a macro when the latter is not wanted. You can see this more clearly by comparing values of B2 and C2:

 

In C2’s expression, ${B1} is a macro that introduces B1’s value to the string.

5.4.2 Special characters in field names

In a table sequence, a field name including non-letter and non-number special characters, like %, (, ), " or a blank space, could cause ambiguity when the expression is parsed. For example:

	A
1	$(demo) select * from STATES order by STATEID
2	=A1.new(NAME:STATE,POPULATION,AREA:'AREA(sq. mi.)')
3	=A2.(round(POPULATION/AREA(sq. mi.),3))

The following is A2’s table sequence, where AREA field is further specified with units added:

When A3 computes the population density using the data in A2, there’s something wrong with the parsing of the field name in the expression. To prevent the parsing problem, single quotation marks can be used to surround the field name of the table sequence (like '…') so as not to recognize the identifiers as the special characters. For example:

	A
1	$(demo) select * from STATES order by STATEID
2	=A1.new(NAME:STATE,POPULATION,AREA:'AREA(sq. mi.)')
3	=A2.(round(POPULATION/'AREA(sq. mi.)',3))

By doing so, esProc will handle the characters surrounded by the single quotation marks (as with 'AREA(sq. mi.)') as a whole and A3 can get the desired result:

Besides representing field names in a table sequence, the format of '…' can also be used in calling a parameter containing special characters. Of course the fields in a table sequence can be referenced by their positions to avoid the trouble brought by directly using the field names. For example:

	A
1	$(demo) select * from STATES order by STATEID
2	=A1.new(NAME:STATE,POPULATION,AREA:'AREA(sq. mi.)')
3	=A2.derive(round(POPULATION/#3,3):Density)

A3 adds a Density field to the table sequence in A2. The code uses #3 to reference A2’s third field so that the problem caused by special characters is solved. Here’s A3’s result:

When a field name in a table sequence represented with '…' is called, the field name is not allowed to contain a single quotation mark; otherwise it can only be called according to the position as with the example above.