Justification of Implementation

Made by Owen Dechow

The following is a justification of certain (perhaps controversial) implementation choices I made in this CSP Pseudocode (hereinafter “CSP”) Interpreter (CSP Pseudocode Runner By: Owen Dechow). Examples of CSP will appear to the below the text, as seen here.

// Owen Dechow
DISPLAY("Is Awesome")

Parts of the editor are also discussed because the interpreter and editor are closely integrated. The editor is NOT, though, the main purpose of this page and therefore will not be exhaustively justified.

1. Special Characters

CSP uses four special characters that are not found on a standard American keyboard. The interpreter uses ASCII equivalents to each of those special characters. No alternatives are given for these characters. The interpreter will not accept any similar ASCII symbols as equivalent. The symbols are featured in the following example.

name ← value // Left Facing Arrow
num ≥ num2 // Greater Than or Equal to
num ≤ num2 // Less Than or Equal to
num ≠ num2 // Not Equal

Because these characters are not easily typed they may be inserted into the editor by one of two simple ways. First, by button: on the top of the editor there are buttons for each of these characters that will, when clicked, insert the character. Second, by autocompletion; a basic autocomplete system is implemented in the editor. Each special character is given a simple escape sequence. Simply type the sequence and the character will be inserted.

← // Abbreviation: <-
≥ // Abbreviation: >=
≤ // Abbreviation: <=
≠ // Abbreviation: !=

2. Window Prompt as INPUT

The CSP INPUT function accepts a value from the user and returns the input value. While one would typically assume this means input is read form the terminal line, I have opted to use the builtin browsers prompt dialog. This choice was made for two reasons. First, to make it clear input is expected. The browser prompt makes it abundantly clear it wants you to enter some text. A hanging program that is just sitting waiting for you to press enter in the terminal does not. Second, because the DISPLAY function does not print a newline, the text of the input will unfavorably be on the same line as the output of the program if using terminal input.

userInput ← INPUT()
DISPLAY("The user typed: ")
DISPLAY(userInput)

3. INPUT as Number

If an input can be parsed as a number it is assumed to be a number. If not it is a string.

ipt ← INPUT() // User enters "34"
34 = ipt // `ipt` is of type NumberValue

ipt ← INPUT() // User enters "hello"
34 = ipt // `ipt` is of type StringValue

CSP is dynamically typed without a way to parse or cast types. Because of this I took inspiration from JavaScript (I dislike this feature of JS funnily enough). In the event that a string is compared to a number in JS, the type of the values are not considered, only the values themselves. Unlike JavaScript though, this implementation does not have arithmetic operators for strings (there is no mention of them in the CSP spec therefore they were left out intentionally).

"12" = 12 // True
353 = 353 // True
"43" = 4 // False
34 ≠ "3" // True

This means that if a value is a number, it has every feature of a string in CSP. The opposite is not true, though. If a value is a string, it does not have all the features of a number. Therefore if a input is assumed to be a number, it will work in every situation where that assumption was wrong without an error or unexpected behavior.

This does have the negative effect of making some errors less intuitive.

4. Number LENGTH Equals Number of Digits

Because INPUT is assumed to be a number if possible, it is common that a user enters a number into INPUT then the program attempts to pass that input into LENGTH. The solution to this is simple. Give numbers the same length they would have as strings. This avoids complex type resolution. It should be noted that for inputs such as “022” the will be 2 not 3 as the original input was. This is because “057” is converted and saved as 57 and their are 2 digits in 22.

DISPLAY(LENGTH(23)) // This will return 2
DISPLAY(LENGTH("23")) // This will return 2
DISPLAY(LENGTH("023")) // This will return 3
DISPLAY(LENGTH(023)) // This will return 2

5. Significant Ordering of the RANDOM Function

The RANDOM function Generates and returns a random integer from a to b, including a and b. Each result is equally likely to occur. Although it does not state a < b in the spec, the implementation does not allow a to be greater than b.

DISPLAY(RANDOM(1, 10)) // Will generate a random number
// on the closed interval [1, 10]

DISPLAY(RANDOM(7, 7)) // Will always return 7
DISPLAY(RANDOM(10, 1)) // Will throw an error

6. Dynamic List Types

In the implementation, lists can have differently typed elements. This is the case for several reasons. One, there is no way to determine the inner type of an empty list. Two, INPUT may result in a string or number. Three, the spec does not say lists must be comprised of one singular type. Four, I do not like JavaScript, and making them dynamic meant I had to write less of it.

// The following is a valid list
[1, "Hello", [1, 2]]

7. Comments

The CSP spec does not have any mention of comments. Despite this I decided to add single line comments anyway. As CSP has no practical use outside of a classroom. I decided the clarity added from a comment is more beneficial than the value of a perfect implementation.

// Hi there. This is a single line comment.

8. Literals

There is no clear specification on how literals should appear in CSP (the spec does not have any such section). I have chosen the following for the implementation based on questions from college board and CSP code examples.

Numbers may only contain digits and one single decimal point (the decimal point may be omitted in the case of integers). A leading negative is valid but will be evaluated at runtime.

10 // Valid number
3.14 // Valid number
67.41.0 // Invalid number
-20 // Evaluated as ("-", "20")

Strings must be encapsulated by double quotes. There “\n” and “\” are evaluated as escape sequences. \ has precedence over \n.

"I am a string" // Valid string
"\n" // This is the new line sequence
"\\" // This is backslash sequence
'Hello' // Invalid string

Booleans are implemented with the “true” and “false” keywords. They are both case sensitive.

true // True
false // False
False // This is not the same as false

9. Null/Void Values

The only way to create a null value in this implementation is to assign the result of a function that does not return a value (such as DISPLAY) to a variable.

If you attempt to display a null value to use an operator on it, the program will crash and a Null Value Error will be raised.

val ← DISPLAY("") // val has a null value
DISPLAY(val) // Null Value Error raised

10. No First Class Procedures

While you may create a procedure inside of a different procedure, the inner procedure only has access to the global scope. As CSP is meant to be language agnostic, I followed the simplest design pattern possible, and the one with least JavaScript.

PROCEDURE myProc(arg1)
{
  PROCEDURE myInnerProc()
  {
    DISPLAY(arg1) // Although this is
    //  inside myProc it
    //  does not have access
    //  to arg1
  }
  myInnerProc()
}

myProc(10) // This results in an error

11. Complete Guide

A complete guide on CSP can be found in the specification at the AP CSP exam reference sheet.