writing functional lisp code effectively

[alecbenzer]

I seem to be having some trouble "getting" how to do certain tasks in lisp. I've been using clojure for a bit and am just picking up scheme (racket), and often times, when given a particular function to write, I find it difficult to write the code all as one function, and often find that the problem is simplified a lot in my mind if I break it up into several functions. Is this a good way of lisping, or am I going about things the wrong way? An example: I needed to write a function that would search for a given pattern inside of a larger list and return the number of occurrences (allowing overlapping). I came up with this:

Code: Select all

(define (count-pattern pattern lst)
  (if (null? lst) 0
  (+ (if (check-pattern pattern lst) 1 0) (count-pattern pattern (cdr lst)))))

(define (check-pattern pattern lst)
  (cond
    ((null? pattern) #t)
    ((null? lst) #f)
    (else (and (equal? (car pattern) (car lst)) (check-pattern (cdr pattern) (cdr lst))))))

Is there a more elegant way to write this as one function that I'm not seeing, or is what I did acceptable in this case?

[Ramarren]

I find it difficult to write the code all as one function, and often find that the problem is simplified a lot in my mind if I break it up into several functions

You seem to have somehow posted from an alternate universe

Seriously though, I have no idea where you got the "all as one function" thing from. Every single text about programming since about 1968 which talks about this aspect at all stresses decomposing problems into smaller problems. There are entire books written about it! First class, anonymous and local functions, which allow such decomposition even further are a significant part of the point of Lisp.

I would suggest reading some materials from this universe and millennium. Or possibly Structure and Intepretation of Computer Programs.

[alecbenzer]

Seriously though, I have no idea where you got the "all as one function" thing from

Perhaps what I wrote was a bit misleading. Often times when someone tells me to "write a function that does <blank>" I find it difficult to complete the task with just one function, whereas I'm used to being able to solve problems of similar complexity within single functions in imperative/procedural languages like C. I also never really encountered "difficulty" in writing tasks as single functions in other languages, at least not the same type of difficulty I encounter in lisp. With other languages the difficulty is usually just tediousness or clutter getting in the way of writing code, and although I would implement code across several functions, it's mostly for simplicity's, clarity's, or conciseness's sake, while in lisp I simply do not know how to implement the problem in one function (without just substituting in a lambda). Is that often normal in lisp (like in the example I gave)?

[Ramarren]

First, Lisp is a family of rather diverse languages, many of which are not particularly functional. Common Lisp, which is a language I personally prefer, is a multi-paradigm language somewhat biased towards iterating by iteration, so I am not as well versed with pure functional programming idioms. But as far as I can tell, it is reasonably obvious that if your primary flow control mechanism is recursion and/or higher order functions, then every flow unit must be a separate function.

Is that often normal in lisp (like in the example I gave)?

So, understanding that in this case "lisp" is a functional lisp family language, like Clojure or Scheme, I would say yes.

[nuntius]

The biggest thing I've noticed is how the languages differ in variable scoping. Discounting old-school C which required all variable declarations at the top of a function, C/C++/Java allow one to "seamlessly" introduce variables in the middle of the function body. Lisp systems generally require adding a new scoping form (e.g. LET), and this changes indentation, etc.

The C family of languages also have terser syntax for mutating data than for calling functions. This is another force that discourages certain coding styles in lisp.