#reader(lib "docreader.ss" "scribble") @require[(lib "manual.ss" "scribble")] @require[(lib "eval.ss" "scribble")] @require[(lib "bnf.ss" "scribble")] @require["guide-utils.ss"] @title[#:tag "syntax-overview"]{Simple Definitions and Expressions} A program module is written as @schemeblock[ #, @BNF-seq[@litchar{#module} @nonterm{langname} @kleenestar{@nonterm{topform}}] ] where a @nonterm{topform} is either a @nonterm{definition} or an @nonterm{expr}. The REPL also evaluates @nonterm{topform}s. In syntax specifications, text with a gray background, such as @litchar{#module}, represents literal text. Whitespace must appear between separate such literals and nonterminals like @nonterm{id}, except that whitespace is not required before or after @litchar{(}, @litchar{)}, @litchar{[}, or @litchar{]}. A comment, which starts with @litchar{;} and runs until the end of the line, is treated the same as whitespace. Following the usual conventions, @kleenestar{} in a grammar means zero or more repetitions of the preceding element, @kleeneplus{} means one or more repetitions of the preceding element, and @BNF-group{} groups a sequence as an element for repetition. @define[val-defn-stx @BNF-seq[@litchar{(}@litchar{define} @nonterm{id} @nonterm{expr} @litchar{)}]] @define[fun-defn-stx @BNF-seq[@litchar{(}@litchar{define} @litchar{(} @nonterm{id} @kleenestar{@nonterm{id}} @litchar{)} @kleeneplus{@nonterm{expr}} @litchar{)}]] @define[fun-defn2-stx @BNF-seq[@litchar{(}@litchar{define} @litchar{(} @nonterm{id} @kleenestar{@nonterm{id}} @litchar{)} @kleenestar{@nonterm{definition}} @kleeneplus{@nonterm{expr}} @litchar{)}]] @define[app-expr-stx @BNF-seq[@litchar{(} @nonterm{id} @kleenestar{@nonterm{expr}} @litchar{)}]] @define[app2-expr-stx @BNF-seq[@litchar{(} @nonterm{expr} @kleenestar{@nonterm{expr}} @litchar{)}]] @define[if-expr-stx @BNF-seq[@litchar{(} @litchar{if} @nonterm{expr} @nonterm{expr} @nonterm{expr} @litchar{)}]] @define[lambda-expr-stx @BNF-seq[@litchar{(} @litchar{lambda} @litchar{(} @kleenestar{@nonterm{id}} @litchar{)} @kleeneplus{@nonterm{expr}} @litchar{)}]] @define[lambda2-expr-stx @BNF-seq[@litchar{(} @litchar{lambda} @litchar{(} @kleenestar{@nonterm{id}} @litchar{)} @kleenestar{@nonterm{definition}} @kleeneplus{@nonterm{expr}} @litchar{)}]] @define[and-expr-stx @BNF-seq[@litchar{(} @litchar{and} @kleenestar{@nonterm{expr}} @litchar{)}]] @define[or-expr-stx @BNF-seq[@litchar{(} @litchar{or} @kleenestar{@nonterm{expr}} @litchar{)}]] @define[cond-expr-stx @BNF-seq[@litchar{(} @litchar{cond} @kleenestar{@BNF-group[@litchar{[} @nonterm{expr} @nonterm{expr} @litchar{]}]} @litchar{)}]] @define[(make-let-expr-stx kw) @BNF-seq[@litchar{(} kw @litchar{(} @kleenestar{@BNF-group[@litchar{[} @nonterm{id} @nonterm{expr} @litchar{]}]} @litchar{)} @kleeneplus{@nonterm{expr}} @litchar{)}]] @define[let-expr-stx (make-let-expr-stx @litchar{let})] @define[let*-expr-stx (make-let-expr-stx @litchar{let*})] @;- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - @section{Definitions} A definition of the form @schemeblock[#, @val-defn-stx] binds @nonterm{id} to the result of @nonterm{expr}, while @schemeblock[#, @fun-defn-stx] binds the first @nonterm{id} to a procedure that takes arguments as named by the remaining @nonterm{id}s. In the procedure case, the @nonterm{expr}s are the body of the procedure. When the procedure is called, it returns the result of the last @nonterm{expr}. @defexamples[ (code:line (define five 5) (code:comment #, @t{defines @scheme[five] to be @scheme[5]})) (code:line (define (piece str) (code:comment #, @t{defines @scheme[piece] as a procedure}) (substring str 0 five)) (code:comment #, @t{of one argument})) five (piece "hello world") ] Under the hood, a procedure definition is really the same as a non-procedure definition, and a procedure name does not have to be used in a procedure call. A procedure is just another kind of value, though the printed form is necessarily less complete than the printed form of a number or string. @examples[ piece substring ] A procedure definition can include multiple expressions for the procedure's body. In that case, only the value of the last expression is returned when the procedure is called. The other expressions are evaluated only for some side-effect, such as printing. @defexamples[ (define (greet name) (printf "returning a greeting for ~a...\n" name) (string-append "hello " name)) (greet "universe") ] Scheme programmers prefer to avoid assignment statements; it's important, though, to understand that multiple expressions are allowed in a definition body, because it explains why the following @scheme[nogreet] procedure simply returns its argument: @def+int[ (define (nogreet name) string-append "hello " name) (nogreet "world") ] Withing @scheme[nogreet], there are no parentheses around @scheme[string-append "hello " name], so they are three separate expressions instead of one procedure-call expression. The expressions @scheme[string-append] and @scheme["hello "] are evaluated, but the results are never used. Instead, the result of the procedure is just the result of the expression @scheme[name]. @; ---------------------------------------------------------------------- @section[#:tag "indentation"]{An Aside on Indenting Code} Line breaks and indentation are not significant for parsing Scheme programs, but most Scheme programmer use a standard set of conventions to make code more readable. For example, the body of a definition is typically indented under the first line of the definition. Identifiers are written immediately after an open parenthesis with no extra space, and closing parentheses never go on their own line. DrScheme automatically indents according to the standard style when you type Enter in a program or REPL expression. For example, if you hit Enter after typing @litchar{(define (greet name)}, then DrScheme automatically inserts two spaces for the next line. If you change a region of code, you can select it in DrScheme and hit Tab, and DrScheme will re-indent the code (without inserting any line breaks). Editors like Emacs offer a Scheme mode with similar indentation support. Re-indenting not only makes the code easier to read, it gives you extra feedback that your parentheses are matched in the way that you intended. For example, if you leave out a closing parenthesis after the last argument to a procedure, automatic indentation starts the next line under the first argument, instead of under the @scheme[define] keyword: @schemeblock[ (define (nogreet name (string-append "hello " name))) ] Furthermore, when an open parenthesis has no matching close parenthesis in a program, both @exec{mzscheme} and DrScheme use the source's indentation information to suggest where it might be missing. @;- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - @section{Identifiers} Scheme's syntax for identifiers is especially liberal. Excluding the special characters @t{ @hspace[2] @litchar{(} @litchar{)} @litchar{[} @litchar{]} @litchar["{"] @litchar["}"] @litchar{"} @litchar{,} @litchar{'} @litchar{`} @litchar{;} @litchar{#} } and except for the sequences of characters that make number constants, almost any sequence of non-whitespace characters forms an @nonterm{id}. For example @schemeid[substring] is an identifier. Also, @schemeid[string-append] and @schemeid[a+b] are identifiers, as opposed to arithmetic expressions. Here are several more examples: @schemeblock[ #, @schemeid[+] #, @schemeid[Apple] #, @schemeid[integer?] #, @schemeid[call/cc] #, @schemeid[call-with-composable-continuation] #, @schemeid[x-1+3i] ] @;- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - @section{Procedure Applications} We have already seen many procedure calls---or @defterm{procedure applications} in Scheme termonology. The syntax of a procedure application is @schemeblock[ #, app-expr-stx ] where the number of @nonterm{expr}s determines the number of arguments supplied to the procedure named by @nonterm{id}. The @schememodname[big] language pre-defines many procedure identifiers, such as @scheme[substring] and @scheme[string-append]. More examples are below. In example Scheme code throughout the documentation, uses of pre-defined names are hyperlinked to the reference manual. So, you can click on an identifier to get full details about its use. @interaction[ (code:line (string-append "hello" " " "scheme") (code:comment #, @t{append strings})) (code:line (substring "hello scheme" 6 12) (code:comment #, @t{extract a substring})) (code:line (string-length "scheme") (code:comment #, @t{get a string's length})) (code:line (string? "hello scheme") (code:comment #, @t{recognize strings})) (string? 1) (code:line (sqrt 16) (code:comment #, @t{find a square root})) (sqrt -16) (code:line (+ 1 2) (code:comment #, @t{add numbers})) (code:line (- 2 1) (code:comment #, @t{subtract numbers})) (code:line (< 2 1) (code:comment #, @t{compare numbers})) (>= 2 1) (code:line (number? "hello scheme") (code:comment #, @t{recognize numbers})) (number? 1) (code:line (equal? 1 "hello") (code:comment #, @t{compare anything})) (equal? 1 1) ] @;- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - @section{Conditionals with @scheme[if], @scheme[and], @scheme[or], and @scheme[cond]} The next simplest kind of expression is an @scheme[if] conditional: @schemeblock[ #, if-expr-stx ] The first @nonterm{expr} is always evaluted. If it produces a non-@scheme[#f] value, then the second @nonterm{expr} is evaluted for the result of the whole @scheme[if] expression, otherwise the third @nonterm{expr} is evaluated for the result. @examples[ (if (> 2 3) "bigger" "smaller") ] @def+int[ (define (reply s) (if (equal? "hello" (substring s 0 5)) "hi!" "huh?")) (reply "hello scheme") (reply "\u03BBx:(\u03BC\u03B1.\u03B1\u2192\u03B1).xx") ] Complex conditionals can be formed by nesting @scheme[if] expressions. For example, you could make the @scheme[reply] procedure work when given non-strings: @schemeblock[ (define (reply s) (if (string? s) (if (equal? "hello" (substring s 0 5) "hi!" "huh?")) "huh?")) ] Instead of duplicating the @scheme["huh?"] case, this procedure is better written as @schemeblock[ (define (reply s) (if (if (string? s) (equal? "hello" (substring s 0 5) #f)) "hi!" "huh?")) ] but these kinds of nested @scheme[if]s are difficult to read. Scheme provides more readable shortcuts through the @scheme[and] and @scheme[or] forms, which work with any number of expressions: @schemeblock[ #, and-expr-stx #, or-expr-stx ] The @scheme[and] form short-circuits: it stops and returns @scheme[#f] when and expression produces @scheme[#f], otherwise it keeps going. The @scheme[or] form similarly short-circuits when it encounters a true result. @defexamples[ (define (reply s) (if (and (string? s) (>= (string-length s) 5) (equal? "hello" (substring s 0 5))) "hi!" "huh?")) (reply "hello scheme") (reply 17) ] Another common pattern of nested @scheme[if]s involves a sequence of tests, each with its own result: @schemeblock[ (define (reply-more s) (if (equal? "hello" (substring s 0 5)) "hi!" (if (equal? "goodbye" (substring s 0 7)) "bye!" (if (equal? "?" (substring s (- (string-length s) 1))) "I don't know" "huh?")))) ] The shorthand for a sequence of tests is the @scheme[cond] form: @schemeblock[ #, cond-expr-stx ] A @scheme[cond] form contains a sequence of clauses between square brackets. In each clause, the first @nonterm{expr} is a test expression. If it produces true, then the clause's second @nonterm{expr} provides the answer for the entire @scheme[cond] expression, and the rest of the clauses are ignored. If the test @nonterm{expr} produces @scheme[#f], then the clause's second @nonterm{expr} is ignored, and evaluation continues with the next clause. The last clause can use @scheme[else] as a synonym for a @scheme[#t] test expression. Using @scheme[cond], the @scheme[reply-more] procedure can be more clearly written as follows: @def+int[ (define (reply-more s) (cond [(equal? "hello" (substring s 0 5)) "hi!"] [(equal? "goodbye" (substring s 0 7)) "bye!"] [(equal? "?" (substring s (- (string-length s) 1))) "I don't know"] [else "huh?"])) (reply-more "hello scheme") (reply-more "goodbye cruel world") (reply-more "what is your favorite color?") (reply-more "mine is lime green") ] The use of square brackets for @scheme[cond] clauses is a convention. In Scheme, parentheses and square brackets are actually interchangable, as long as @litchar{(} is matched with @litchar{)} and @litchar{[} is matched with @litchar{]}. Using square brackets in a few key places makes Scheme code even more readable. @;- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - @section{Procedure Applications, Again} In our earlier grammar procedure applications, we oversimplified. The actual syntax of a procedure application allows an arbitrary expression for the procedure, instead of just an @nonterm{id}: @schemeblock[ #, app2-expr-stx ] The first @nonterm{expr} is often an @nonterm{id}, such as @scheme[string-append] or @scheme[+], but it can be anything that evaluates to an procedure. For example, it can be a conditional expression: @def+int[ (define (double v) ((if (string? v) string-append +) v v)) (double "hello") (double 5) ] Syntactically, the first expression in a procedure application could even be a number---but that leads to an error, since a number is not a procedure. @interaction[(1 2 3 4)] When you accidentally omit a procedure name or when you use parentheses around an expression, you'll most often get an ``expected a procedure'' error like this one. @;- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - @section{Anonymous Procedures with @scheme[lambda]} Programming in Scheme would be tedious if you had to name all of your numbers. Instead of writing @scheme[(+ 1 2)], you'd have to write @interaction[ (define a 1) (define b 2) (+ a b) ] It turns out that having to name all your procedures can be tedious, too. For example, you might have a procedure @scheme[twice] that takes a procedure and an argument. Using @scheme[twice] is convenient if you already have a name for the procedure, such as @scheme[sqrt]: @def+int[ (define (twice f v) (f (f v))) (twice sqrt 16) ] If you want to apply a procedure that is not yet defined, you could define it, and then pass it to @scheme[twice]: @def+int[ (define (louder s) (string-append s "!")) (twice louder "hello") ] But if the call to @scheme[twice] is the only place where @scheme[louder] is used, it's a shame to have to write a whole definition. In Scheme, you can use a @scheme[lambda] expression to produce a procedure directly. The @scheme[lambda] form is followed by identifiers for the procedure's arguments, and then the procedure's body expressions: @schemeblock[ #, lambda-expr-stx ] Evaluating a @scheme[lambda] form by itself produces a procedure: @interaction[(lambda (s) (string-append s "!"))] Using @scheme[lambda], the above call to @scheme[twice] can be re-written as @interaction[ (twice (lambda (s) (string-append s "!")) "hello") (twice (lambda (s) (string-append s "?!")) "hello") ] Another use of @scheme[lambda] is as a result for a procedure that generates procedures: @def+int[ (define (make-add-suffix s2) (lambda (s) (string-append s s2))) (twice (make-add-suffix "!") "hello") (twice (make-add-suffix "?!") "hello") (twice (make-add-suffix "...") "hello") ] Scheme is a @defterm{lexically scoped} language, which means that @scheme[s2] in the procedure returned by @scheme[make-add-suffix] always refers to the argument for the call that created the procedure. In other words, the @scheme[lambda]-generated procedure ``remembers'' the right @scheme[s2]: @interaction[ (define louder (make-add-suffix "!")) (define less-sure (make-add-suffix "?")) (twice less-sure "yeah") (twice louder "yeah") ] We have so far referred to definitions of the form @scheme[(define #, @nonterm{id} #, @nonterm{expr})] as ``non-procedure definitions.'' This characterization is misleading, because the @nonterm{expr} could be a @scheme[lambda] form, in which case the definition is equivalent to using the ``procedure'' definition form. For example, the following two definitions of @scheme[louder] are equivalent: @defs+int[ [(define (louder s) (string-append s "!")) code:blank (define louder (lambda (s) (string-append s "!")))] louder ] Note that the expression for @scheme[louder] in the second case is an ``anonymous'' procedure written with @scheme[lambda], but, if possible, the compiler infers a name, anyway, to make printing and error reporting as informative as possible. @;- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - @section[#:tag "local-binding-intro"]{Local Binding with @scheme[define], @scheme[let], and @scheme[let*]} It's time to retract another simplification in our grammar of Scheme. In the body of a procedure, definitions can appear before the body expressions: @schemeblock[ #, fun-defn2-stx #, lambda2-expr-stx ] Definitions at the start of a procedure body are local to the procedure body. @defexamples[ (define (converse s) (define (starts? s2) (code:comment #, @t{local to @scheme[converse]}) (define len2 (string-length s2)) (code:comment #, @t{local to @scheme[starts?]}) (and (>= (string-length s) len2) (equal? s2 (substring s 0 len2)))) (cond [(starts? "hello") "hi!"] [(starts? "goodbye") "bye!"] [else "huh?"])) (converse "hello!") (converse "urp") (code:line starts? (code:comment #, @t{outside of @scheme[converse], so...})) ] Another way to create local bindings is the @scheme[let] form. An advantage of @scheme[let] is that it can be used in any expression position. Also, @scheme[let] binds many identifiers at once, instead of requiring a separate @scheme[define] for each identifier. @schemeblock[ #, let-expr-stx ] Each binding clause is an @nonterm{id} and a @nonterm{expr} surrounded by square brackets, and the expressions after the clauses are the body of the @scheme[let]. In each clause, the @nonterm{id} is bound to the result of the @nonterm{expr} for use in the body. @interaction[ (let ([x 1] [y 2]) (format "adding ~s and ~s produces ~s" x y (+ x y))) ] The bindings of a @scheme[let] form are available only in the body of the @scheme[let], so the binding clauses cannot refer to each other. The @scheme[let*] form, in contrast, allows later clauses to use earlier bindings: @interaction[ (let* ([x 1] [y 2] [z (+ x y)]) (format "adding ~s and ~s produces ~s" x y z)) ]