Glossary

accu­mu­lator A value that is updated on every pass through a recur­sive loop, for instance in for/fold.

anony­mous func­tion A name­less func­tion created by using a lambda form rather than define. See also func­tions.

argu­ment A value used as input to a func­tion or program.

arity The number of input argu­ments accepted by a func­tion, or the number of values returned by a func­tion. Most commonly seen when you try to invoke a func­tion with the wrong number of argu­ments: you will get an “arity error”.

asso­ci­a­tion A pair holding a key and value.

asso­ci­a­tion list A list of asso­ci­a­tions. Used as a light­weight alter­na­tive to a hash table. See also data struc­tures.

atom A value that is not a list.

bound Describes an iden­ti­fier that has a binding.

boundary In the contract system, describes places where a contract can be applied. The most common contract bound­aries are the module boundary (using contract-out) and the func­tion boundary (using define/contract). See also contracts.

binding An asso­ci­a­tion of a value with an iden­ti­fier. A binding can be made explic­itly (e.g., with define) or implic­itly (e.g., a require expres­sion adds bind­ings to a program). A program cannot run unless every iden­ti­fier has a binding, other­wise you get the famous “unbound iden­ti­fier” error. See also iden­ti­fiers.

calling site The place where a macro is invoked. See also macros.

char­acter An integer-like data type—distinct from a string—that repre­sents a single Unicode value.

check An asser­tion about the behav­ior of the func­tion, usually pack­aged as a unit test.

collec­tion A name­space of related modules, which might come from more than one package.

coloring anno­ta­tion Used by DrRacket to deter­mine the syntax coloring for a chunk of code.

column A field in a source loca­tion that rep­re­sents the hori­zontal offset within the current line. Counts from 0.

combi­nator In the contract system, a special set of helper func­tions used to build contracts.

compile time The stage of program eval­u­a­tion when required modules are imported and macros are expanded, resulting in a fully expanded program. Compile time happens before run time.

compiler A program that takes source code as input and converts it to a different, usually lower-level, form that can then be passed along to the next stage of processing.

compi­la­tion The act of using a compiler on a program.

compos­able See compos­ability.

compos­ability The idea of making func­tions and data struc­tures that are small, self-contained, and generic, and combining them to produce more complex behav­iors. An impor­tant soft­ware-design prin­ciple in Racket, and func­tional program­ming gener­ally.

cons cell The atomic unit of memory allo­ca­tion, equal to one pair. Used to create lists.

contin­u­a­tion A func­tion that encap­su­lates the loca­tion of an expres­sion and its surrounding eval­u­a­tion context. See also contin­u­a­tions.

contract An optional run-time check on the input argu­ments or output values of a func­tion. See also contracts.

contract combi­nator A special func­tion that takes contracts as input and produces a new contract, including -> and listof. See also contracts.

control flow The path of eval­u­a­tion within a program. For instance, ordi­nary S-expres­sions are eval­u­ated from the inside out. Macros are eval­u­ated from the outside in. Contin­u­a­tions allow control flow to jump from one point to another.

core syntactic form In a fully expanded program, a form that cannot be expressed in terms of more prim­i­tive forms. For a full list, see fully expanded programs in the Racket Refer­ence.

datum The “liter­al­ized” version of an expres­sion, usually created with quote or its equiv­a­lent, the ' prefix. The datum form of a single value is a single datum. The datum form of a paren­the­sized S-expres­sion is a list of datums.

defi­n­i­tion site The place where a macro is defined. As a result of hygiene, a macro retains the lexical context of its defi­n­i­tion site, regard­less of where it’s invoked. See also hygiene.

delim­iter A token (or pair of tokens) used to set apart certain code from the surrounding code, so it can be parsed sepa­rately.

dictio­nary A class of Racket data types that repre­sent key–value mappings (e.g., an asso­ci­a­tion list or hash table) and can all be used with Racket’s generic dictio­nary func­tions (like dict-ref). See also data struc­tures.

domain-specific language A language tailored to the needs of a partic­ular set of prob­lems. The oppo­site of a general-purpose language. See domain-specific languages for exam­ples.

DSL See domain-specific language.

dyadic A func­tion that takes only two argu­ments (aka has arity 2).

ellipsis Does two things in a macro. First, when used after a pattern vari­able in a syntax pattern, it greedily matches as many subse­quent syntax objects as it can, and asso­ciates them with that pattern vari­able. Then, in a syntax template, it indi­cates that these matched elements should be handled the same way as the pattern vari­able. See also syntax patterns.

error An excep­tion that’s raised when a problem occurs at run time. See also errors & excep­tions.

eval­u­a­tion The process of recur­sively reducing expres­sions to yield a result. See also eval­u­a­tion.

excep­tion A message that imme­di­ately prop­a­gates upward through the chain of calling func­tions. Any of these func­tions can catch the excep­tion and handle it, or let it continue upward. If it reaches the top, the program stops. Excep­tions are typi­cally used to handle errors, but can also be used to create alter­na­tive forms of control flow. See also errors & excep­tions.

excep­tion handler A func­tion that processes an excep­tion, usually within a with-handlers expres­sion. An excep­tion handler might modify an excep­tion, suppress it, or let it pass.

expander Used in a specific sense to mean the part of a Racket-imple­mented language respon­sible for providing the initial bind­ings for the code. It is, along with a reader, one of the two main parts of a Racket-imple­mented language. The term is also used in a general sense to mean the overall Racket subsystem that eval­u­ates macros and produces a fully expanded program.

expan­sion The code returned by the oper­a­tion of a macro. So named because the code returned is often more complex than the code that went in.

expres­sion A program entity that can be eval­u­ated to produce a value. Within Lisp languages, known as an S-expres­sion. See also eval­u­a­tion.

expres­sion-based language A language, like Racket, that is built entirely from expres­sions, and contains no state­ments.

fixnum A small exact integer, where “small” depends on the plat­form. On a 64-bit machine, fixnums can range from -4611686018427387904 to 4611686018427387904.

form Alter­na­tive name, frequently seen in the Racket docu­men­ta­tion, for certain macros.

format string An argu­ment provided to format and similar string-conver­sion func­tions that indi­cates how the other argu­ments should be converted to strings.

fully expanded program The state of a Racket program at the end of compile time, after the expander has finished its work, where the program has been rewritten in terms of a vocab­u­lary of core syntactic forms.

func­tion A set of instruc­tions that are not run until requested. Racket func­tions can take any number of posi­tional argu­ments and keyword argu­ments, and option­ally a rest argu­ment. Func­tions can also return any number of values. Func­tions can be named (if created with define) or anony­mous (if created with lambda). See also func­tions.

func­tional program­ming A style of program­ming where func­tions are designed to be self-contained, oper­ating only on their input argu­ments (rather than relying on state) and returning a value (rather than relying on muta­tion).

garbage collec­tion See garbage collector.

garbage collector The subsystem respon­sible for freeing blocks of memory no longer in use. The garbage collector runs auto­mat­i­cally during a program. Frequently abbre­vi­ated as GC.

general-purpose language A language designed to make any kind of program, like Racket or Python or C. The oppo­site of a domain-specific language.

getter A func­tion for retrieving a partic­ular value from inside a larger data struc­ture, like a struc­ture type.

grammar A set of produc­tion rules defining the mean­ingful elements of a language, and how they fit together. Often used as the basis of a parser.

guard An express­sion that limits the iter­a­tion values of a loop, usually by testing the current iter­a­tion value with a pred­i­cate. See also loops.

hash table A data struc­ture that maps keys to values. Both the keys and values can be any kind of data. See also data struc­tures.

here string Alter­na­tive string-input syntax that makes it easier to handle multi­line strings and strings with special char­ac­ters like ". See here strings in the Racket Refer­ence.

higher-order func­tion A func­tion that takes other func­tions as argu­ments, like apply, map, filter, compose1, or curry.

hygiene The prin­ciple that macros adopt the lexical context of their defi­n­i­tion site (which is known in advance to the macro writer) rather than their calling site (which is not). This elim­i­nates the risk of name colli­sions between iden­ti­fiers intro­duced by the macro and iden­ti­fiers at the calling site. (A problem also known as iden­ti­fier capture.) One can over­ride hygiene by using an unhy­gienic iden­ti­fier. See also the hygiene explainer.

hygienic macro See hygiene.

iden­ti­fier A name that can be bound to a value to produce a vari­able (for instance (define foo 42) makes a vari­able from the iden­ti­fier foo). See also iden­ti­fiers.

iden­ti­fier capture See hygiene.

immutable Describes a data struc­ture that can never be changed, like a pair. The oppo­site of mutable. In func­tional program­ming, the use of immutable data struc­tures helps enforce the broader policy of avoiding muta­tion.

imper­a­tive program­ming A style of program­ming where func­tions don’t return values, but rather operate on external vari­ables using muta­tion to change the state of the program. The styl­istic oppo­site of func­tional program­ming.

indenter A func­tion used within DrRacket to indent lines of source code.

infix nota­tion A nonstan­dard way of writing func­tion expres­sions in Racket, with the func­tion name between two dots, anywhere amidst the argu­ment list (x1 . func . x2 x3). When a func­tion name is written like this, it’s treated as if it appeared in the first posi­tion (func x1 x2 x3) i.e., as prefix nota­tion.

instan­ti­a­tion The moment when a module is loaded.

inter­po­si­tion points A set of special macros that wrap certain oper­a­tions. See inter­po­si­tion points.

inter­preter A program that takes source code as input and eval­u­ates it, producing a result. In Racket, the idea is mostly inter­change­able with compiler.

interned Refers to a data type like symbols whose allo­ca­tion and storage is specially managed by Racket so that each unique instance of that data type only appears once in memory. This means that interned values can be compared with the fastest compar­ison func­tion (eq?) which relies on pointer compar­isons rather than value compar­isons.

keyword argu­ment A func­tion argu­ment parsed by name rather than posi­tion. A keyword is prefixed with #:. See also func­tions.

lambda In a general sense, an alter­nate name for a func­tion, derived from Racket’s asso­ci­a­tion with lambda calculus. In a specific sense, the lambda func­tion creates an anony­mous func­tion. See also func­tions.

lambda calculus Invented by Alonzo Church in the 1930s, the lambda calculus is a way of studying computable func­tions. In the 1950s, John McCarthy adapted the nota­tion of lambda calculus to create the Lisp program­ming language. Racket is a descen­dant of Lisp, so the influ­ence of this nota­tion continues.

language See program­ming language.

lexer A helper func­tion for a tokenizer that matches char­ac­ters from a source file to a series of rules that are similar to regular expres­sions.

lexical context The set of vari­ables defined at a certain point in a program. Every syntax object is asso­ci­ated with a lexical context that deter­mines the mean­ings of vari­ables in the code. This lexical context travels with the syntax object, ensuring that its vari­ables have consis­tent meaning. See also hygiene.

lift A tool avail­able during macro expan­sion that moves the result of a macro from its orig­inal loca­tion to some­where higher in the program, often the top level of the enclosing module. See, e.g., syntax-local-lift-expression.

line A field in a source loca­tion that rep­re­sents the vertical line number from the top. Counts from 1.

list The funda­mental data struc­ture of Racket. An ordered sequence of values. See also lists.

macro A func­tion that runs at compile time, taking certain code as input and rewriting it to produce new code. Also known as a syntax trans­former. See also macros.

meta­lan­guage A Racket language that can be chained to another to add features. It’s “meta” in the sense that it doesn’t do every­thing an ordi­nary language would. Rather, it does a few things, then passes the code along to the main language for the heavy lifting.

module The smallest orga­ni­za­tional unit of code. All Racket code lives in a module. See also modules.

module language Racket lingo for a language that uses the default S-expres­sion reader, such as the br or racket languages. See also Module Languages in the Racket Guide.

mutable Describes a data struc­ture that can be changed, like a vector. The oppo­site of immutable.

muta­tion A program­ming tech­nique whereby a func­tion changes the value of a vari­able that’s been defined outside the boundary of the func­tion. Discour­aged in func­tional program­ming. See also side effects.

nonter­minal An element of a grammar that can be decom­posed into smaller pieces with a produc­tion rule. See also terminal.

nota­tion Collo­quial term for the surface syntax of a program­ming language.

optional argu­ment An argu­ment of a func­tion that adopts a default value if not explic­itly provided.

package The basic unit of soft­ware distri­bu­tion.

pair A data struc­ture that stores two values. More complex struc­tures, like lists, are built from pairs. See also pairs.

para­meter A special kind of func­tion that approx­i­mates a global vari­able. See para­me­ters.

parse tree The output from a parser, which consumes source code, destruc­tures it according to a grammar, and produces this hier­ar­chical repre­sen­ta­tion of code elements.

parser A func­tion that takes a stream of tokens and matches them to a grammar to produce a parse tree.

parser gener­ator A program that builds a parser from a grammar. Programs written in the brag language are parser gener­a­tors.

parsing The process of turning a series of tokens from a source file into a struc­tured, hier­ar­chical parse tree, usually by using a grammar as a guide.

path The loca­tion of a file on disk. See also paths.

pattern vari­able A named matcher within a syntax pattern or other pattern. See also syntax patterns.

phase A discrete stage in compi­la­tion. See also phase 0 and phase 1. See also eval­u­a­tion.

phase 0 Another name for run time in Racket.

phase 1 Another name for compile time in Racket.

pointer compar­ison To compare two values by their loca­tion in memory, rather than their literal values. Typi­cally only possible with interned values.

port A generic inter­face for reading from, or writing to, a data source (like a string, device, or disk). Ports can be used incre­men­tally—that is, you can read or write data a little at a time, rather than all at once. See ports in the Racket Refer­ence.

posi­tion A field in a source loca­tion that rep­re­sents the num­ber of char­ac­ters away from the start. Counts from 1.

posi­tional argu­ment An argu­ment of a func­tion that is parsed according to its loca­tion in the list of input argu­ments. Compare keyword argu­ments, which are not.

prefix nota­tion The stan­dard way of writing func­tion expres­sions in Racket, with the func­tion name at the front, and the argu­ments following. Compare infix nota­tion.

preprocessor A domain-specific language used to layer extra func­tion­ality atop existing languages, such as the C preprocessor, which doesn’t look anything like C.

proce­dure Alter­nate name for a func­tion.

produc­tion rule Within a grammar, defines a pattern showing how a nonter­minal can be decom­posed into smaller pieces (consisting of termi­nals and other nonter­mi­nals).

pred­i­cate A func­tion that takes any value and returns a Boolean. Gener­ally used to test if a vari­able belongs to a certain class of items, like string? or list?. Commonly used with filter and contracts. By conven­tion, names of pred­i­cates usually end with ?.

program­ming language A nota­tional system mutu­ally intel­li­gible to humans and computers. A program­ming language has two key ingre­di­ents: syntax and seman­tics. Within Racket, a program­ming language is imple­mented as a source-to-source compiler with two parts: a reader and an expander.

quasi­quote Nota­tion for making a list that allows inner expres­sions to be selec­tively eval­u­ated, and then either inserted or spliced into the surrounding list. See lists.

quasi­syntax Similar to quasi­quote, but the result of each oper­a­tion is a syntax object. See also quasisyntax.

reader One of the two main parts of a Racket-imple­mented language. The reader is respon­sible for converting source code into S-expres­sions. It runs before the other main part of a language, the expander.

recur­sion When speaking of func­tions, recur­sion is the idea of designing a func­tion so that it completes its task by calling itself. When speaking of data struc­tures, recur­sion denotes a struc­ture which can be nested indef­i­nitely, for instance an S-expres­sion. But these are two sides of the same coin, because a classic pattern of func­tional program­ming is using a recur­sive func­tion to process a recur­sive data struc­ture. See also recur­sion.

recur­sive See recur­sion.

REPL Abbre­vi­a­tion for read–eval­uate–print loop. A command line for eval­u­ating Racket expres­sions. See also REPL.

rest argu­ment An argu­ment that captures the “rest” of the argu­ments passed to a func­tion, after the posi­tional argu­ments and keyword argu­ments have been parsed. Used to make func­tions that can take any number of argu­ments, aka vari­adic func­tions.

run time The stage of program eval­u­a­tion when the fully expanded program is reduced to a program result. Ordi­nary func­tions are called during run time. Run time happens after compile time.

S-expres­sion The essen­tial building block of Racket programs. An S-expres­sion can be either a) an atomic value (like a string, number, or symbol) or b) a paren­the­sized list of values.

scope For every binding, the part of a program where that binding is visible.

seman­tics The fancy word used by computer scien­tists to describe the meaning assigned to certain nota­tional syntax within a program­ming language. Roughly, within a Racket language, the expander imple­ments the seman­tics.

sequence A data type that supports ordered retrieval of its elements. In prac­tice, a sequence is not a distinct data type so much as an inter­face supported by other data types. For instance, lists, strings, and hash tables can all be used as sequences.

setter A func­tion for changing a partic­ular value from inside a larger data struc­ture, like a struc­ture type.

shadow When a binding implic­itly over­rides another binding that would other­wise be avail­able. For example, all bind­ings outside a let expres­sion are avail­able within its body, but any iden­ti­fiers bound at the top of the let will over­ride them. For another example, if a binding is imported into a module with require, and the module defines a binding with the same name, then the local binding takes prece­dence.

shape The internal nesting struc­ture of an S-expres­sion or set of S-expres­sions.

side effect Some­thing that happens as a result of calling a func­tion, other than a value being returned. In func­tional program­ming, side effects are used spar­ingly. Muta­tion of vari­ables is a kind of side effect. Output func­tions like printf and displayln are side effects.

source code A sequence of char­ac­ters describing a program, usually within a source file.

source file A file that contains source code.

source loca­tion The posi­tion of an expres­sion within a source file. Typi­cally stored within a syntax object. Contains four fields: posi­tion, line, column, and span.

source-to-source compiler A compiler that converts the source code of one language into the source code of another. All Racket-imple­mented languages are essen­tially source-to-source compilers from the source language to Racket. Also called a transcom­piler.

span A field in a source loca­tion that rep­re­sents the num­ber of char­ac­ters that the code occu­pies, starting from its posi­tion. Counts from 0.

stack A data struc­ture holding an ordered set of items that are added and removed from the same end (tradi­tion­ally, these oper­a­tions are known as push! and pop!). So named because it can be visu­al­ized as a vertical “stack” with the edits happening at the top. A Racket list can be used as a stack.

state A program value that’s used to hold infor­ma­tion persis­tently, inde­pen­dent of a partic­ular func­tion. For instance, global vari­ables. A discour­aged tech­nique in func­tional program­ming.

state­ment A program entity that doesn’t return a value, like goto in BASIC. There are no state­ments in Racket, only expres­sions.

stdin Abbre­va­tion for “stan­dard input”, the default input port used by a program. For a program in DrRacket, stdin defaults to the REPL.

stdout Abbre­va­tion for “stan­dard output”, the default output port used by a program. For a program in DrRacket, stdout defaults to the REPL.

struc­ture type A custom data struc­ture that has named fields and its own pred­i­cate. See struc­ture types in data struc­tures.

submodule A module that’s nested inside another module. Submod­ules can be nested to any depth. More impor­tantly, loading a module does not auto­mat­i­cally load its submod­ules, nor does loading a submodule auto­mat­i­cally load its parent module. See submod­ules.

surface syntax See syntax.

symbol A string­like data struc­ture that is interned. When converted to a datum, iden­ti­fiers become symbols. See also string­like types.

syntactic form See form.

syntax This word is used in two ways. From a computer-science perspec­tive, it refers to the surface nota­tion of a program­ming language. Within Racket (and within this book) it is refers to S-expres­sions that repre­sent chunks of program code. To distin­guish the two, the first meaning is some­times called surface syntax. Within a Racket language, the reader imple­ments the surface syntax.

syntax colorer Func­tion used by DrRacket to apply colors to source code.

syntax context The program context of a syntax object, which includes lexical context and posi­tion within the source code. See also syntax objects.

syntax object A datum that repre­sents program code, pack­aged with other meta­data, such as lexical context and source loca­tion. Syntax objects are used primarily as the input and output format for macros. See also syntax objects.

syntax pattern A way of notating the shape of a syntatic form, used in macros for decom­posing syntax objects into their compo­nents and matching them to pattern vari­ables. See also syntax patterns.

syntax prop­erty A key–value pair attached to a syntax object. The key must be a symbol; the value can be anything. See also syntax objects.

syntax template A syntax object that appears within a macro defi­n­i­tion or with-pattern form. Unlike an ordi­nary syntax object, a syntax template can refer to any defined pattern vari­ables. These refer­ences are auto­mat­i­cally replaced with the under­lying matched value. See also syntax patterns.

syntax trans­former See macro.

terminal An element of a grammar that cannot be decom­posed further. See also nonter­minal.

thunk A lambda without argu­ments that wraps an expres­sion to delay its eval­u­a­tion. For instance, hash-ref option­ally takes a thunk as input that will be eval­u­ated only if the requested hash element isn’t found.

tokenizer A func­tion that consumes a source-code char­acter stream and reduces it to the smallest mean­ingful units, called tokens. In turn, these are used as input for a parser.

token The smallest unit of code handled by a parser. A token can refer to a literal string (gosub), a value (42), or a class of things (INTEGER).

transcom­piler See source-to-source compiler.

Turing complete Describes a language that can be used to write every possible computer program. The lambda calculus is Turing complete, as is Racket. Many domain-specific languages are not. But whether a language is Turing complete has no bearing on whether it is, in prac­tical terms, useful. As Alan Perlis said: “Beware of the Turing tar-pit in which every­thing is possible but nothing of interest is easy.”

unbound An iden­ti­fier that has no binding. A common problem in Racket programs is the “unbound iden­ti­fier” error, which arises when not every iden­ti­fier used in the program has a binding. See also iden­ti­fiers.

unhy­gienic Describes a macro-created iden­ti­fier that’s delib­er­ately intro­duced within a lexical context other than that of the macro itself (most commonly, the lexical context at the calling site). See also hygiene.

unhy­gienic iden­ti­fier See unhy­gienic.

unit test A small, specific soft­ware test, often set up to run frequently & auto­mat­i­cally during devel­op­ment. See also unit testing.

vari­able An iden­ti­fier that has been assigned a binding. See also iden­ti­fiers.

vari­adic A func­tion of unlim­ited arity. See also rest argu­ment.

vector A Racket data type that holds a sequence of values. Similar to a list, but has better perfor­mance when random access to elements is needed. See also data struc­tures.

void The result of eval­u­ating an expres­sion that returns no value. See also void? and void.