# General Proposal for Course Prerequisites Language

Evan Silverman and Albert Liu
This post proposes syntax and conventions for specifying the prerequisites of a course. In some cases the proposals are general, i.e. “the syntax should have this property”, and in other cases it is specific, i.e. “we should use this keyword”. Note that the tone used here is mostly declarative; this is just for convenience. All of these are suggestions, and the language is not yet defined.

### 1. Variables [back to top]

Variables represent objects and are the bread and butter of this language.

#### 1.1 Variable Identifiers can Contain Whitespace [back to top]

For convenience, variable identifiers should include whitespace. For example, MATH-UA 123 Calculus III would be handled as follows*:

• Whitespace has no inherent meaning:
e.g. MATH-UA  123 Calculus   III means the same thing
• …except as a separator of non-whitespace:
e.g. MATH -UA 123 Calculus III means something different
• Also, identifiers are stripped of additional whitespace:
e.g.   MATH-UA 123 Calculus III   means the same thing

* see section 2.3 for an exception to this rule.

#### 1.2 “Name” is the Term for Variables [back to top]

Instead of variables, since we’re operating on objects that have very concrete real-world analogues, I think we should call variables names. MATH-UA 123 Calculus III isn’t a variable that holds a course boolean as much as it is the name of a course, which we evaluate to be a course we have or haven’t taken. The remainder of this document will use the term “name” to refer to variables.

#### 1.3 Assignment with =[back to top]

Name assignment should be done using =:

calc 3 =
MATH-UA 123
Calculus III

Note that this example is valid because whitespace is meaningless*.

* see section 2.3 for an exception to this rule.

#### 1.4 “Naming” is the Term for Assignment [back to top]

Although we’re assigning a value to a namespace, that doesn’t really make sense in natural language. Instead, I think we should call assignment “naming”, so in the above example we don’t assign calc 3 the value MATH-UA 123 Calculus III, we instead give MATH-UA 123 Calculus III the name calc 3.

### 2. The Punctuation is Almost English [back to top]

Because this language’s target audience isn’t necessarily familiar with the idioms of computer science, and because, more generally, plain-text is easier to read, the syntax of this language should be as close as possible to english.

#### 2.1 Programs are Made of Sentences [back to top]

A program is comprised of sentences, which are each executed in order. These sentences can be separated by a period ., a semicolon ;, or the end of the file.

#### 2.2 Programs are Organized into Paragraphs [back to top]

Code is organized into paragraphs; which are groups of sentences separated by two or more newline characters. This isn’t necessary for 95% of use cases, but both simplifies parsing and improves readability.

#### 2.3 Double Newline Always Means New Paragraph [back to top]

A double newline indicates the end of the expression, regardless of context. For example, this would be a syntax error:

calc 3 = MATH-UA 123

Calculus III

The reason is simple: in English, paragraphs always end with a complete idea. When a paragraph ends on a quote, if that quote continues to the next paragraph it is first ended, then restarted. Paragraphs denote a completion of a group of ideas in English, and thus should do the same here. The above should instead be written as

calc 3 = MATH-UA 123.

Calculus III

to mean two separate paragraphs, or as

calc 3 = MATH-UA 123 Calculus III

to mean a single sentence.

#### 2.4 The Last Sentence of the Program is its Final Value [back to top]

The last sentence of the program is the ultimate decider of whether or not the course prerequisites are met or not. If the last sentence is a tautology, then regardless of what happens before that, the course has no prerequisites, as students will always qualify for it.

#### 2.5 Leading and Trailing Whitespace is Ignored [back to top]

The last sentence is the last sentence, and the first sentence is the first sentence, regardless of whitespace before or after. The above subsection applies even if the file looks like this:

calc 3 = MATH-UA 123 Calculus III



#### 2.6 Comments are Enclosed in Square Brackets [back to top]

Text that shouldn’t be considered part of the program code, but is still useful to include in the program, should be enclosed in [Square Brackets]. Doing so will add a comment to the program at that location, and act the same as if you had just typed a space there. For example,

calc 3 = MATH-UA 123[Level 100 course]Calculus III

is interpreted the same as

calc 3 = MATH-UA 123 Calculus III

Note: Comments cannot contain double newlines. That shouldn’t be necessary.

### 3. Keywords are Plain Text [back to top]

As stated above, we want the syntax of this language to be similar to English. Part of that means ensuring that syntax uses words, not symbols, to denote relationships between names.

#### 3.1 Boolean Operators AND, OR, NOT

Booleans allow us to manipulate courses and start describing course prerequisites. For example, if a student needs to take JOUR-UA 50 and one of either CORE-UA 711 or CORE-UA 724, we could express that as

JOUR-UA 50 AND (CORE-UA 711 OR CORE-UA 724)

If a course can only be taken if an equivalent has not already been taken, we can use NOT to express that. For example,

NOT JOUR-UA 50 AND NOT JOUR-UA 101 AND NOT JOUR-UA 102 

describes a course whose prerequisites only accepts students that have not started down the journalism track at NYU.

#### 3.2 Plain Text Keywords can Clash with Names [back to top]

Since names can contain whitespace, the language parser needs to do a lot more work to prevent names from being misinterpreted. The following subsections propose potential solutions to this problem, and the remaining sections will follow all of them.

#### 3.3 Keywords are Uppercase [back to top]

while words like and and or are used in course names, their uppercase variants really aren’t. Thus, requiring keywords to be uppercase prevents namespace clashing.

#### 3.4 Quotation Escapes Keywords [back to top]

Single and Double quotation can be used to indicate that a keyword is being used as part of a name, and not as a keyword. For example, all of the following are valid names, and mean the same thing:

JOUR-"UA" 50 Investigating "Journalism: Ethics AND "Practice.
JOUR-'UA' 50 Investigating 'Journalism: Ethics AND 'Practice.
JOUR-UA 50 Investigating 'J'"o"urnalism:'' E'thics 'AND' 'Practice

Additionally though, quotation escapes quotation, so the following would be different from the previous examples:

"'JOUR-UA 50 Investigating Journalism: Ethics" AND "Practice'".
"'JOUR-UA 50 Investigating Journalism: "Ethics" AND Practice'"

#### 3.5 Syntax is Context-Dependent [back to top]

Words mean different things in different contexts. By restricting the meaning of a keyword to a specific context or set of contexts, we can allow for some flexibility in the use of keywords in names. For example, the following might be permissible, if we don’t include the left-hand side of naming in the keyword context of AND:

CULTURES AND CONTEXTS = (CORE-UA 500, CORE-UA 509, CORE-UA 514, CORE-UA 515)

This kind of approach should be used conservatively; the use cases of keywords should be restricted to their intended use and nothing more.

### 4. Sets and Booleans are the Main Types [back to top]

The foundation of this section is the idea that the ultimate function of any prerequisite specification is to, given an arbitrary set of a student’s previous courses, return a boolean value, either prerequisites have been met, or prerequisites have not been met. For example, the prerequisite

Prerequisite: one introductory course


checks whether the courses that a student has taken contains at least one of the introductory courses, and returns true if it does. Because booleans and sets are the two types visible to the student, and to the writer, to minimize complexity they should be the only types in the language.

Additionally, we should assume that collection order is irrelevant. The order of taking courses is an emergent feature of the prerequisite graph itself; it shouldn’t be hard-coded in.

#### 4.1 “List” is the Term for Unordered Sets [back to top]

While the internal representation may be a set, the language’s target audience is not programmers, and thus the idea of an unordered set isn’t necessarily a useful name. The remainder of this document will use the term “list” to refer to an unordered set.

#### 4.2 List Builder Notation [back to top]

The following notation should be used to construct lists:

intro courses = (PHIL-UA 001, PHIL-UA 003, PHIL-UA 006, PHIL-UA 007).
intro courses again = (
PHIL-UA 001,
PHIL-UA 003,
PHIL-UA 006,
PHIL-UA 007
,).[One extra comma can be at the end but not the beginning]
empty list = (,).
another empty list = ().
small course list = (PHIL-UA 001,)[without the comma this is just a name]

#### 4.3 Names are Duck-Typed [back to top]

In the above example, we named the list intro courses. A name can refer to an arbitrary object, in the same sense that a name can be given to anything. If it is used incorrectly later, an error will be raised at that point.

### 5. Quantifiers Make Lists into Booleans [back to top]

Quantifiers are a way to specify how many courses we’d like. They provide a simple way to convert lists into booleans. For example, to give the above list a truth value, we might want to use a quantifier such as has taken at least 2 of the above courses. For the sake of this language, we will use the following quantifiers:

• At least how many
• At most how many
• Exactly how many

#### 5.1 Quantifier Notation [back to top]

The above can be expressed with the following notation:

AT LEAST 1 OF (PHIL-UA 001, PHIL-UA 003, PHIL-UA 006, PHIL-UA 007)

Similarly, we can also write both of the following:

intro courses = (PHIL-UA 001, PHIL-UA 003, PHIL-UA 006, PHIL-UA 007).
AT MOST 1 OF intro courses.
EXACTLY 1 OF intro courses

#### 5.2 AT LEAST is Implicit [back to top]

When reading the prerequisite one introductory course, we assume that having taken 2 introductory courses is also perfectly fine; the equivalent is true in this language. The following sentences are equivalent:

AT LEAST 1 OF intro courses.
1 OF intro courses

#### 5.3 Special Cases of Quantifier Notation [back to top]

Boolean logic can be considered a special case of quantifier notation; i.e.

"PHIL-UA 001" AND "PHIL-UA 003" AND "PHIL-UA 006" AND "PHIL-UA 007"


is the same thing as

AT LEAST 4 OF (PHIL-UA 001, PHIL-UA 003, PHIL-UA 006, PHIL-UA 007)

and

"PHIL-UA 001" OR "PHIL-UA 003" OR "PHIL-UA 006" OR "PHIL-UA 007"


is the same thing as

AT LEAST 1 OF (PHIL-UA 001, PHIL-UA 003, PHIL-UA 006, PHIL-UA 007)

#### 5.4 Lists Have an Implicit Truth Value [back to top]

Lists implicitly have a truth value equivalent to chaining AND for all of their elements; when at least one course hasn’t been taken, the list is false, and only when all courses have been taken is the list true.

#### 5.5 NOT and EXACTLY Make Implicit Conversion Explicit [back to top]

EXACTLY explicitly casts a list to its implicit truth value, and NOT explicitly casts a list to the negation of its implicit truth value.

### 6. Other Operations on Lists [back to top]

To reduce the work necessary to specify categorical requirements for a course, we should allow for more complex operations on lists, beyond simply quantifying the number of courses taken in them.

#### 6.1 AND Combines Lists [back to top]

AND acts as a union when used between lists, combining all the unique elements of both lists into a new list.

For example, the following two lists are identical:

(PHIL-UA 001, PHIL-UA 003, PHIL-UA 006, PHIL-UA 007).
(PHIL-UA 001, PHIL-UA 003) AND (PHIL-UA 001, PHIL-UA 006, PHIL-UA 007)

#### 6.2 WITHOUT Finds List Differences [back to top]

WITHOUT finds all the names in the list to its left which are not contained in the list to its right. For example, to filter out PHIL-UA 001 from the list of introductory philosophy courses, you would do

intro courses WITHOUT PHIL-UA 001

Notice that even though PHIL-UA 001 is just a name for a course, and not a name itself, WITHOUT automatically puts it in its own list. However, the same can’t be said the other way around:

PHIL-UA 001 WITHOUT intro courses[This isn't correct grammar.]

#### 6.3 AND Behavior Favors List Evaluation [back to top]

When doing performing AND between a list and a boolean, the result is the union of the list and a one-element list containing the boolean. For example, the result of

(PHIL-UA 001, PHIL-UA 006, PHIL-UA 003) AND PHIL-UA 007

is the list

(PHIL-UA 001, PHIL-UA 003, PHIL-UA 006, PHIL-UA 007)

#### 6.4 OR Behavior Favors Boolean Evaluation [back to top]

When performing OR with a list and another list, or a list and a boolean, the list(s) are first implicitly turned into booleans, and then the result is evaluated as a regular OR.

### 7. Miscellaneous [back to top]

The above information should cover the vast majority of use cases. The following subsections introduce concepts that will aid in the use and adoption of this language, as well as allow for arbitrarily complex prerequisite systems without the need for all professors to learn a database query language. Of the remaining subsections, only 7.1 and 7.4 might be important for most users to know.

#### 7.1 READ Gets Names From Other Programs [back to top]

READ makes names from other programs available. If one or more READ statements are used in a program, they must be in the first paragraph of the program, and that paragraph may not contain anything but read statements and comments.

#### 7.2 Boolean Literals [back to top]

The boolean literals are represented as TRUE and FALSE. Determining the semantic meaning of each symbol is left as an exercise to the reader.

#### 7.3 System Administrators Use a Different Syntax to Create Meta-Files [back to top]

A separate syntax can be used to create name-only programs that only exist to provide other users with pre-made lists of courses. The syntax for this will be more technical, as its purpose is to create larger pre-made lists from database queries.

#### 7.4 Name Resolution Can be Customized [back to top]

The evaluation of a name to a truth value is an implementation detail. Resolving names to actual courses in the database should be done through the implementation of the language, and specified on a per-school basis.

#### 7.5 The Final Line of a Prerequisites Program is Visible to Students [back to top]

The syntax of this language may be cleaner than that of existing prerequisite descriptions. Thus, it may be beneficial to use the last line of the program for a specific course as the message displayed to students when registering. This message would also include comments (with brackets omitted).

#### 7.6 Title Comments Give Names to Paragraphs [back to top]

Single-line names that begin after a paragraph break and end with a colon and line break are title comments. They only differ from normal comments in syntax, and the fact that they can only be one line.

#### 7.7 Generalization of Language to Degree Requirements [back to top]

By the organizing sections of degree requirements into paragraphs, we can use this language to specify degree requirements as well as course requirements.