Re: Core foundation of Common Lisp (not pure Lisp)

From: Duane Rettig (duane_at_franz.com)
Date: 01/06/05 

Date: 06 Jan 2005 12:58:00 -0800

"John Thingstad" <john.thingstad@chello.no> writes:

> On 06 Jan 2005 08:47:08 -0800, Duane Rettig <duane@franz.com> wrote:
>
> > Actually, not :-)
> >
> > Barry alluded to the why in terms of why the technique is not a
> > Bad Thing, but not why the technique is in fact a Good Thing and
> > thus why an implementor would want to proliferate the technique ...
> >
> > This is actually the cleanest way to implement a definition; there
> > needs to be functionality for the definition of not, and also for
> > its compilation. If this functionality is spread between both
> > functional code and compiler inlining, the knowledge of NOT is
> > harder to maintain, because it is in two different places. However,
> > if the functional definition is done as above, with the intelligence
> > about the real definition in the compiler, then the functionality
> > resides in one place and becomes very easy to maintain. Not that
> > NOT needs maintaining, but there are other more complex functions
> > that have this attribute...
> >
>
> I can see how this makes sense from a implementor perspective.
> It's the thought of having a function tested and debugged
> and considered finished only to discover that it no longer
> works when I compile it that bothers me.

I don't understand this. Such a self-descriptive function
will _only_ work when you compile it...

> Still if I had followed the suggestions given both by
> the compiler and evaluator not to redefine the function
> in the first place I suspect there would be no problem.

If you're talking about package locking deterring one from
redefining CL functions, then yes; implementors have ways
to get around these things. But as for never redefining a
function in the first place, consider the maxims that state
that large percentages (I usually hear 80%) of programming
effort is spent in maintenance, and not in writing new code,
so if that effort were not required, most programmers would
then be out of a job... 

-- 
Duane Rettig    duane@franz.com    Franz Inc.  http://www.franz.com/
555 12th St., Suite 1450               http://www.555citycenter.com/
Oakland, Ca. 94607        Phone: (510) 452-2000; Fax: (510) 452-0182

Relevant Pages

  • Re: Optimization (was Re: C portability is a myth)
    ... A modern compiler can use a technique ... Rather I assume that you've discovered some bottleneck in your ... yet you know *FOR SURE* that there is no real performance gain from ...
    (comp.lang.c)
  • Re: 32-bit CRC table generation at compile time in C, was Re: The IMMEDIATE mess
    ... This would work with GCC, but as I don't often use GCC, I'd have to try it to be sure. ... The entire technique is suspect and to me doesn't have any real advantage over simply including a table of magic constants. ... I'm not suggesting this as a usual technique because it runs the risk of not working (by blowing past compiler implementation limits) and because it doesn't really give the programmer anything. ... Only that the C preprocessor (and the constant folding of the compiler) do allow some compile-time constructs that some may think aren't possible. ...
    (comp.lang.forth)
  • Re: duffs device / loop unriolling
    ... > With a modern, optimising compiler, it's bad idea. ... > Compilers can do unrolling for you. ... the loop body that is being unrolled is ... The technique of incrementing i by 8, and using 'i+0', etc, ...
    (comp.lang.c)
  • Re: How many lines of code per programmer-hour?
    ... >that, refine your technique. ... the compiler for the shaders). ... In many cases i find ive dug myself into a bad trench, ...
    (borland.public.delphi.non-technical)
  • Re: [EGN] Numerical Accuracy
    ... The advice worked because in fact the Microsoft compiler had a bug. ... The capabilities of the optimizer are not so ... The language standard itself says ... of "programming" as a nonprofession. ...
    (comp.programming)