As Greg explained, the named let form simplifies the interface to other code. It is much more common in practice.
> On Sep 6, 2014, at 23:50, Greg Hendershott <[email protected]> wrote: > > Well, I think you answer your own question with good reasons in the > last paragraph. :) > > If `acc` is an implementation detail, let's not expose it as a parameter.[1] > > At least, let's not do this for a function provided by a module. > Especially not a function with a contract and/or documentation. > > But if it's a helper function that's not provided? Especially in a > small module? Then I'd say it doesn't matter so much. > > > [1]: Not even a parameter with a default value of '(), which is a 3rd > possibility -- a way to try to have your cake and eat it, too. You > could even have provide/contract insist that the value be '(), for > "outsiders"... but inside the module the contract is N/A. I actually > did this once upon a time. I changed my mind when I started to write > documentation for the function, got to that parameter, and realized... > yeah, nope. :) > > >> On Sat, Sep 6, 2014 at 9:55 PM, Kevin Forchione <[email protected]> wrote: >> Hi guys, >> Which is preferable? >> >> (define (foo let … (acc empty)) … (foo (rest let) ... (cons …. acc)) >> >> or >> >> (define (foo lst ...) (let loop ([lst lst] …[acc empty]) … (loop (rest let) >> … (cons …. acc))) >> >> On the one hand we eliminate the named let construct, but on the other hand >> we expose the acc in the function / contract. If the acc is not something >> the caller would ever need to know about, should we hide it inside the >> definition? >> >> -Kevin >> ____________________ >> Racket Users list: >> http://lists.racket-lang.org/users > > ____________________ > Racket Users list: > http://lists.racket-lang.org/users ____________________ Racket Users list: http://lists.racket-lang.org/users
