[erlang-questions] Style wars: junk comments

[Fred Hebert]

I was agreeing with you, just showing an alternative form from the one 
you showed. I don't know what you're trying to convince me of there.

On Wed Sep 12 22:38:23 2012, Richard O'Keefe wrote:
>
> On 13/09/2012, at 1:38 PM, Fred Hebert wrote:
>
>> Some Schemes also allow things like:
>>
>> (define (fib x)
>>    (define (fib-rec n a b)
>>       (cond [(= n 0) b]
>>             [true (fib-rec (- n 1) b (+ a b))]))
>>    (fib-rec x 0 1))
>>
>> which can be called as(fib 4).
>
> I think you missed the point.  Except for the use of square brackets,
> this is absolutely standard RnRS Scheme for at least n = 2..5.  It is
> also trivial and in this context unhelpful, because a helper function
> defined this way is necessarily private to its client.  You can do
> _this_ much in practically every functional language but Erlang.
>
> Defining one function inside another is just plain not interesting;
> we've been able to do _that_ since 1960.  Only languages in the
> BCPL->C->C++->Java lineage think there is anything unusual or
> tricky about *that*.  (Even Fortran and COBOL let you defined
> nested procedures.)
>
> Heck, even in Erlang you can do
>
> fib(X) ->
>      F = fun (_, 0, _, B) -> B
>            ; (G, N, A, B) -> G(G, N-1, B, A+B)
>          end,
>      F(F, X, 0, 1).
>
>
>> This allows to define private or helper functions within the context of their main function, without needing destructive assignment or whatever, and then later on executing it.
>
> Even Scheme doesn't _really_ need destructive assignment;
> you can manage without it by introducing an auxiliary name:
>
> (define add-and-del
>    (letrec ((rebalance (lambda (t) ...))
>      (list (lambda (k v t) ...)) ;add
>            (lambda (k t) ...)))) ;del
> (define add (car  add-and-del))
> (define del (cadr add-and-del))
>
> Common Lisp lets you get the multiple-private-helpers-
> shared-by-multiple-clients effect by bending the
> scope rules rather horribly:
>
>    (labels ((rebalance (t) ...))
>      (defun add (k v t) ...)
>      (defun del (k t) ...))
>
> DEFUN always "Defines a new function ... in the global environment."
>
> The mechanics are of no great interest,
> what is of interest is the ability by _some_ mechanism
> to have one or more helper functions that are
> *outside* their clients (so they do *not* have access to
> the clients' internal data) and are accessible to one or
> *more* clients without being accessible to _all_ the
> top-level functions in the module.
>
> Defining a function inside another function does NOT allow
>   - private helper functions used by two or more functions
>     (which was the point of what I was talking about)
>   - private helper functions used in more than one clause
>     of the same function, a very important issue in Erlang.
>
>> Python allows something similar:
>>
>> def fib(x):
>>     def fib_rec(x, a, b):
>>         if x == 0:
>>             return b
>>         else:
>>             return fib_rec(x-1, b, a+b)
>>     return fib_rec(x, 0, 1)
>
> Yawn.  So Python has caught up with 1960.  This *still* cannot
> handle the non-trivial case of a helper function shared by more
> than one function.
>>
>> You can separate one-use helpers from module-wide helpers that way, too.
>
> Yes, that's been pretty much obvious since 1960.
> The issue is helpers that are NEITHER one-use NOR module-wide.
>
> Non-functional languages usually go for nested modules for that.
> Like I said, I don't care about the mechanics.
>>
>> Nothing would keep us from doing something similar in Erlang iff anonymous functions were not so anonymous (and if self-recursion in anonymous function wasn't that annoying to read).
>
> I don't see anything *annoying* in
>      F = fun (_, 0, _, B) -> B
>            ; (G, N, A, B) -> G(G, N-1, B, A+B)
>          end,
> Mildly irritating, yes; annoying, no.
> I seem to recall suggesting a small syntax
> extension where
>
>     fun F(X, Y, Z) -> ... F(...) ...
>       ; F(...) ... F ...
>     end
>
> would turn into
>
>     F = (fun (G) -> fun (X, Y, Z) -> G(G, X, Y, Z) end end)
>         (fun (F, X, Y, Z) -> ... F(F,...) ...
>            ; (F, ...) ... fun (X, Y, Z) -> G(G, X, Y, Z) end ...
>          end)
>
> but on the whole, perhaps not.
>