I often write things the way you do. I find that it's easier to test if I
can get at as many procedures as possible from the REPL (but maybe I'm not
very Schemey either). I also find it harder to read procedures declared in
let blocks sometimes because they make the flow of control jump around on
the page - first you have to read the body of the let block, which is lower
on the screen, and then jump back up to the functions that were defined at
the top of the block.

However, I think that inner functions make a lot of sense if you think of
each top-level procedure like its own little module. If you think like
that, then writing inner procedures means grouping related code together
and making the overall structure more clear.

Noah


On Wed, Apr 3, 2013 at 10:04 AM, Mike Gran <spk...@yahoo.com> wrote:

> I've been looking over one of the solutions to a Guile 100 problem
> (a basic version of the `ls' command) at the link below.  It is
> interesting stylistically because it works very hard at minimizing the
> scope of procedures.  It uses a lot of procedures within procedures,
> like, for example, within a `let*' block.
>
>
> https://gist.github.com/spk121/5301264
>
>
> For example
> (define (outer-function x)
> (let*
> ((inner-function
> (lambda (b . M)
> (let ((m (fold logior 0 M)))
> (eq? m (logand b m)))))
> ...
>
> Personally, I only define a procedure within a procedure if the
> inner procedure is not a pure function, e.g. if its result
> depends on information other than its parameters, and that
> information only exists within the scope of the outer procedure.
> I tend to keep most pure functions at the module level. But,
> I'm not a very Schemey guy.
>
> One could look at using lots of procedures within procedures as good
> defensive programming style: hiding unnecessary functions.
>
> Or one could look at it as being less clear because you end up with
> longer "paragraphs" to read.
>
> Do you have a personal philosophy on how much you try to minimize
> the scope of procedures?  If you were writing a tutorial,
> what would you say?
>
> -Mike Gran
>
>
>

Reply via email to