Re: never use `eval'

[Emanuel Berg]

"Pascal J. Bourguignon" <pjb@informatimago.com>
writes:

> It should not be a problem, at that time, or
> nowadays. In the old days, car and cdr were quite
> the optimized instructions: they corresponded to
> 7090 machine instructions, or to lisp machine
> instructions, so calling (car x) several times was
> probably faster than storing the result in
> a variable or even a register (because of the
> possible register spilling) and calling it up again.
>
> And nowadays, with honest compilers performing some
> common subexpression elimination optimization, it
> should compile to exactly the same.

Yeah, it is more a question of the code not looking
good and being difficult to work with, say for example
if the data item that once was (car l) changes - you
have to change all them places. You can do
search-and-replace but then you better catch them all
and since it is such a common thing you might catch
some unwanted fish in the bargain/net as well.

I don't really care about speed as such, but of course
I want to write efficient code. Still computers have
always been always fast enough for me, and I have used
old computers (5-10 years) all my "career". What I do
don't require speed it would seem and besides I don't
think I'm that slow just because I don't disassemble
code to compare which is preferable. I'm on the human
side of the equation. I can't even say how many cache
levels my architecture has. OK, 'lscpu' tells me
three, but you know what I'm saying.

> In the case of ccl, the code is quite similar, but
> indeed (car x) (car x) will hit the (cache) memory
> each time, recomputing the offset (assumedly in the
> pipeline so at zero cost) each time, while using
> a temporary variable saves it in a register.

"ccl" I don't know.

> But in the case of sbcl, it compiles to the exact
> same instructions (the only difference being in the
> procedure entry, probably allocating some space on
> the stack that is left unused in the let case).

Steel Bank Common Lisp!

    (defvar inferior-lisp-program)
    (setq inferior-lisp-program "/usr/bin/sbcl --noinform")

Did the US steel industry have a bank, which had its
own a dialect of LISP? Crazy times... Probably a lot
of job opportunities for real programmers in
those days.

> Again, if you have tail call optimization, then
> there's no recursion occuring, and efficiency is
> equivalent to iteration (because in effect, the
> compiler generates an iteration).

I do like some recursion which uses one function
(itself) and do recursion there. This recursion
pattern is cool:

    * empty list - nil
    * not empty list - do something with car
                     - do it again with cdr

The recursion I don't like is recursion which relies
on helper functions and "accumulator" variables and
the like - them arguments should be input data, not
"persistent variables" to carry state
between invocations.

Some recursion can be with an infix operator and then
do recursion divide-and-conquer both ways down
searching a tree, then leading up to the operands of
the function. It looks cool to be sure.

But the coolest search algorithm I've seen is
"candidate elimination" which searches search space
two ways, from the general to the specific, and
simultaneously, form the specific to the general, and
where they meet is the answer (no nodes left to go to
but to stay put).

This reminds me of what happened once in the FOSS
world when there was a non-free component of KDE,
namely Qt (pronounced "cute"?) - to counterpunch this,
two projects were launched: GNOME, to replace KDE -
i.e., the general approach; and, Harmony to replace Qt
(the specific). The end of the story is GNOME was
succesful (still not to my liking, but I don't like
the desktop at all); Harmony was dropped (?); and, Qt
turned free. It is just the way of the street. In
100 years the same thing will happen and people will
be angry and creative about it. Then and now and in
the future, the only thing bigger than the grievance
is the mirth.

> Of course, CL implementations and emacs lisp don't
> necessarily implement TCO, so recursion could be
> less efficient. But as long as response times are
> below the 300 ms threshold, it's ok. ;-)

Right. When the carpenter applies sandpaper to a piece
of wood, he doesn't think a person will get stuck by
every single chip he removes. But if he didn't do it
at all, and used the plank to lay a floor, the
shoe-less hippies and their dogs would cry out their
spits and angers...

"If everything can start anew, then everything
must continue."

-- 
underground experts united
http://user.it.uu.se/~embe8573