Re: What does "lacks a prefix" mean?

[Rusi]

On Thursday, July 30, 2015 at 7:10:31 AM UTC+5:30, Robert Thorpe wrote:
> I won't talk about this much more because I think it's getting off-topic
> for this list.
> 
> Emanuel Berg writes:
> > This is the exact same tiresome argument that has been
> > put forward several times by now and the argument is
> > still only logical within the framework that is "this
> > is the way people do it". Yes: I know!
> 
> I think that new languages should be written to do this the same way.  I
> think the convention for let and let* used in lisp is useful and I wish
> it were more widespread.  I'm not advocating it just because it's used
> in old code.  My comments about refactoring were separate.
> 
> > In the other framework, where it is natural and
> > *desired* that things depend on each other and happen
> > stepwise - nothing to be afraid of and nothing that
> > must be marked specifically as it is the natural order
> > of things - in that framework it doesn't make
> > sense (surprise, surprise!).
> 
> Certainly there is no point in avoiding dependencies.  They always occur
> in programming.  But, there's no need to make it look as through there
> are dependencies where there aren't.  There's no point removing tools
> that allow use to differentiate one situation from the other easily.
> That's the problem with the approach you're advocating.
> 
> As I said earlier, let's suppose you're reading through function foo
> looking for what happens to variable bar.
> 
> Suppose you have:-
> (let (.....
>       (foo (code ...)))
>   body)
> 
> In this case there's no need to read through any of the other variables
> defined in the let.
> 
> Suppose instead you have:
> (let* (.....
>        (foo (code ...)))
>   body)
> 
> In that case the part I've labeled "code ..." could depend on the other
> local variables.  In the "let" case it's often possible to eval the
> "code ..." part with C-x C-e.  That's often not possible in the let*
> case.  In the let* case you have to read through the rest of the local
> variable definitions.
> 
> In elisp we have the following meanings:
> * let - there aren't dependencies between these variables.
> * let* - there are dependencies between these variables.
> 
> In other languages that only support something like let* it means "there
> may be dependencies between these variables, you have to read all the
> code".

Strongly concur!
Dijkstra made a statement that is as alarming as it is true, viz.
"It takes 100 years for an idea to go from inception to general acceptance"
[dont have exact quote handy...]
Some examples:
Cantor-1880 to New-math-1970 (set theory)
200 years for Leibniz calculus notation to replace the clumsier Newton fluxion 
notation
600 years for Hindu-Arabic (decimal) numerals to replace roman
30 years between Wright brothers flight and first commercial flight

In the same way
Lisp was invented in 1960
For the next 40 years something vague and acdaemic called 'functional 
programming'
was talked of but everyone only really had lisp as an example/exemplar.
Finally it is only this century -- Haskell, Clojure, Scala -- that its become
mainstream

And finally its become abc of programming
ACM curriculum 2013 pg 158 lists what EVERY programmer should know of FP.
Seeing this discussion, I am coming to the conclusion that dependencies (and
their minimization) is something that should be added there.

To be fair the one thing I agree with Emanuel is that let* is a clumsy name.
I'd like best a single let with a 'dependency-fence'
So

Say {e,f} depends on {c,d} depends on {a,b} (no inra-set dependency)

The least-dependency way of writing would be
(let ((a ..)
      (b ..))
  (let ((c ..)
        (d ..))
    (let ((e ..)
          (f ..))
      body)))

The sloppy way would be just one let*

Neither is quite satisfactory -- one is over-dependent; the other is over-nested

What I'd like

(newlet  ((a ..)
          (b ..)
          :fence
          (c ..)
          (d ..)
          :fence
          (e ..)
          (f ..))
  body)))

The keyword ":fence" can be improved :-)