2.7 Procedure Applications and #%app
|(proc-expr arg )|
Applies a procedure, when proc-expr is not an identifier that has a transformer binding (see Expansion).
More precisely, the expander converts this form to (#%app proc-expr arg ), giving #%app the lexical context that is associated with the original form (i.e., the pair that combines proc-expr and its arguments). Typically, the lexical context of the pair indicates the procedure-application #%app that is described next. See also Expansion Steps.
|> (+ 1 2)|
|> ((lambda (x #:arg y) (list y x)) #:arg 2 1)|
|(#%app proc-expr arg )|
Applies a procedure. Each arg is one of the following:
The resulting value is a non-keyword argument.
The resulting value is a keyword argument using keyword. Each keyword in the application must be distinct.
The proc-expr and arg-exprs are evaluated in order, left to right. If the result of proc-expr is a procedure that accepts as many arguments as non-keyword arg-exprs, if it accepts arguments for all of the keywords in the application, and if all required keyword-based arguments are represented among the keywords in the application, then the procedure is called with the values of the arg-exprs. Otherwise, the exn:fail:contract exception is raised.
The continuation of the procedure call is the same as the continuation of the application expression, so the results of the procedure are the results of the application expression.
The relative order of keyword-based arguments matters only for the order of arg-expr evaluations; the arguments are associated with argument variables in the applied procedure based on the keywords, and not their positions. The other arg-expr values, in contrast, are associated with variables according to their order in the application form.
See also Expansion Steps for information on how the expander introduces #%app identifiers.
|> (#%app + 1 2)|
|> (#%app (lambda (x #:arg y) (list y x)) #:arg 2 1)|
|> (#%app cons)|
cons: expects 2 arguments, given 0
|(#%plain-app proc-expr arg-expr )|