Too many arguments for function

Question

I'm starting to learn Lisp with a Java background. In SICP's exercise there are many tasks where students should create abstract functions with many parameters, like

 (define (filtered-accumulate combiner null-value term a next b filter)...)

in exercise 1.33. In Java (language with safe, static typing discipline) - a method with more than 4 arguments usually smells, but in Lisp/Scheme it doesn't, does it? I'm wondering how many arguments do you use in your functions? If you use it in production, do you make as many layers?

Answer 1

SICP uses a subset of Scheme

SICP is a book used in introductory computer science course. While it explains some advanced concepts, it uses a very tiny language, a subset of the Scheme language and a sub-subset of any real world Scheme or Lisp a typical implementation provides. Students using SICP are supposed to start with a simple and easy to learn language. From there they learn to implement more complex language additions.

Only positional parameters are being used in plain educational Scheme

There are for example no macros developed in SICP. Add that standard Scheme does have only positional parameters for functions.

Lisp and Scheme offer also more expressive argument lists

In 'real' Lisp or Scheme one can use one or more of the following:

• objects or records/structures (poor man's closures) which group things. An object passed can contain several data items, which otherwise would need to be passed 'spread'.

• defaults for optional variables. Thus we need only to pass those that we want to have a certain non-default value

• optional and named arguments. This allows flexible argument lists which are much more descriptive.

• computed arguments. The value or the default value of arguments can be computed based on other arguments

Above leads to more complicated to write function interfaces, but which are often easier to use.

In Lisp it is good style to have descriptive names for arguments and also provide online documentation for the interface. The development environment will display information about the interface of a function, so this information is typically only a keystroke away or is even display automatically.

It's also good style for any non-trivial interface which is supposed to be used interactively by the user/developer to check its arguments at runtime.

Example for a complex, but readable argument list

When there are more arguments, then Common Lisp provides named arguments, which can appear in any order after the normal argument. Named arguments provide also defaults and can be omitted:

(defun order-product (product
                      &key
                      buyer
                      seller
                      (vat   (local-vat seller))
                      (price (best-price product))
                      amount
                      free-delivery-p)
  "The function ORDER-PRODUCT ..."   ; documentation string
  (declare (type ratio vat price)    ; type declarations
           (type (integer 0) amount)
           (type boolean free-delivery-p))
  ...)

We would use it then:

(order-product 'sicp
               :seller 'mit-press
               :buyer  'stan-kurilin
               :amount  1)

Above uses the seller argument before the buyerargument. It also omits various arguments, some of which have their values computed.

Now we can ask whether such extensive arguments are good or bad. The arguments for them:

• the function call gets more descriptive
• functions have standard mechanisms to attach documentation
• functions can be asked for their parameter lists
• type declarations are possible -> thus types don't need to be written as comments
• many parameters can have sensible default values and don't need to be mentioned

Several Scheme implementations have adopted similar argument lists.