Thank you for your comment

Beau­tiful Racket / tuto­rials

Learn some functional programming: funstacker

Our stacker language worked fine. But the way we imple­mented the stack wasn’t as sleek as it could’ve been. The rele­vant excerpt from the source code:

(define stack empty)

(define (pop-stack!)
  (define arg (first stack))
  (set! stack (rest stack))
  arg)

(define (push-stack! arg)
  (set! stack (cons arg stack)))

(define (handle [arg #f])
  (cond
    [(number? arg) (push-stack! arg)]
    [(or (equal? * arg) (equal? + arg))
     (define op-result (arg (pop-stack!) (pop-stack!)))
     (push-stack! op-result)]))
(provide handle)
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
(define stack empty)

(define (pop-stack!)
  (define arg (first stack))
  (set! stack (rest stack))
  arg)

(define (push-stack! arg)
  (set! stack (cons arg stack)))

(define (handle [arg #f])
  (cond
    [(number? arg) (push-stack! arg)]
    [(or (equal? * arg) (equal? + arg))
     (define op-result (arg (pop-stack!) (pop-stack!)))
     (push-stack! op-result)]))
(provide handle)
copy to clipboard

What’s the problem here? Our handle func­tion uses two tech­niques that are common in other program­ming languages, but discour­aged in Racket:

  1. Relying on a vari­able outside the func­tion, also known as state. Here, handle relies on stack, which is a vari­able that lives outside the func­tion.

  2. Changing a value from afar, also known as muta­tion. Here, handle uses push-stack! and pop-stack! to add & remove items by changing the value of stack.

Racket, instead, encour­ages a style called func­tional program­ming. This doesn’t mean merely “program­ming with func­tions”. (Everyone does that.) It means designing our func­tions so that they’re self-contained. Rather than relying on state, every­thing the func­tion needs to do its job is passed into the func­tion as input. Rather than relying on muta­tion, the func­tion provides its result as a return value, which entirely replaces the old value. So instead of updating a single element of an existing list, we would return a whole new list.

Func­tional program­ming is big in Racket for two reasons.

First, because it dove­tails with Racket’s expres­sion-based struc­ture. Expres­sions can be freely combined like Legos, allowing us to join elements that wouldn’t fit together in other languages. For instance, we can wrap if around an argu­ment in an arith­metic oper­a­tion:

(define (div num denom)
  (/ num
     (if (zero? denom)
         (error 'division-by-zero)
         denom)))
1
2
3
4
5
(define (div num denom)
  (/ num
     (if (zero? denom)
         (error 'division-by-zero)
         denom)))
copy to clipboard

Or we can wrap it around the oper­ator:

(define (div num denom)
  ((if (zero? denom)
       (error 'division-by-zero)
       /) num denom))
1
2
3
4
(define (div num denom)
  ((if (zero? denom)
       (error 'division-by-zero)
       /) num denom))
copy to clipboard

Or the result:

(define (div num denom)
  (if (zero? denom)
      (error 'division-by-zero)
      (/ num denom)))
1
2
3
4
(define (div num denom)
  (if (zero? denom)
      (error 'division-by-zero)
      (/ num denom)))
copy to clipboard

What makes these combi­na­tions possible is the fact that every expres­sion is self-contained. In Racket, this virtue goes by the slightly mathy name compos­ability. When we use func­tional program­ming, we sever the tentac­ular connec­tions implied by state and muta­tion, thereby improving the compos­ability of our func­tions.  + Compos­ability is also a design virtue of many Unix-derived text-based command-line tools, which are designed to be chained together.

The other reason func­tional program­ming is big in Racket is because of its roots as a research language. Researchers like to be able to prove things about func­tions. But when a func­tion oper­ates outside its bound­aries, or is affected by data far away, it becomes harder to reason about the func­tion’s behavior. All those external possi­bil­i­ties need to be consid­ered. It’s easier to prove that a self-contained func­tion is correct.

When we say a func­tion is more easily proved correct, this also implies that it can be more easily tested. We’re not going to dive into Racket’s testing facil­i­ties yet (though the curious can peek ahead). But the disci­pline of func­tional program­ming tends to reveal bugs earlier.

That said, do we always have to use func­tional program­ming in Racket? No. Some­times, it can be more effi­cient or read­able to use state or muta­tion. In those cases, we should feel free.

Nor are we standing on a moun­taintop, shouting “you’re doing it wrong” at the languages below. It’s simply an issue of idiomatic usage. Func­tional program­ming is perva­sive within Racket. If we take the time to under­stand func­tional program­ming at the begin­ning of our Racket journey, a lot of things will make sense. If we don’t, we’ll have the uncom­fort­able feeling of moving against the grain.

So let’s create a little variant of stacker called funstacker, designed to intro­duce some func­tional-program­ming concepts.

← prev next →