Re: [grt-talk] Picking targets. Was: Some suggestions. (fwd)

[Nikodemus Siivola]

> 1) Repetative code patterns are *the* source of errors, especialy typos.
> With centralized facility like the infamous op* macro, you have just one
> place to check out and fix.

Do you have extensive experience in maintaining large bodies of code? I do
that for living. The problem with op3 is that every time there is a bug the
code expansions from op* need to be checked, and op* usage needs to be
checked -- untill everyone trusts it and knows it's being used correctly.
OP* is obfuscations: it may make for shorter, but not better code, in my
opinion at least.

You are mixing issues here:

 * repetitive control patterns

 * similar functionality patterns

The first should be abstracted into a macroes, yes. The latter should use a
common base-abstraction (eg. make colors and vectors use a common triplet
implementation).

Then you could write a macros like:

 (defmacro elementwise-triplet (op a b)
    `(triplet (funcall ,op (triplet-0 ,a) (triplet-0 ,b))
              (funcall ,op (triplet-1 ,a) (triplet-1 ,b))
              (funcall ,op (triplet-2 ,a) (triplet-2 ,b))))

and

 (defun triplet+ (a b)
   `(elementwise-triplet #'+ a b))

And even here you *may* run into the problem of writing 20 lines of code to
save 2, which is bad.

Paul Graham is right in saying that abstractions are good, but shorter code
is not always the same as more abstract code -- and not all abstractions
make sense.

> 2) Future development. For example, let's imagine we'll be smart enough
> (?) to add 3DNow!/SSE2 code to speed up vector math. This stuff seems to
> be scheduled for SBCL at least, BTW. Does the habit of writing vector
> math "by hand" simplify its integration (*conditional* integration)? I
> think, it doesn't. The same thing applies to possible loop unrolls,
> cache optimization, threading and so on. Good degree of abstraction
> makes things simplier. I think that op* macro is quite dumb and easy to
> understand while it does good job with vector math.

Now *that's* what I call premature optimization: optimizing for a future
implementation of a single compiler. I think it might be more profitable to
write our own vector VOP's for CMUCL and SBCL, but even that's not the
issue for now.

>>We'll just have to disagree on this one. Lisps in general are much better
>>unboxing things inside structs that vectors, and vector match with float
>>boxing is just unacceptable.

> Why???

Why which? The first has to do with the way UPGRADED-ARRAY-ELEMENT-TYPE is
defined in ANSI CL, I think (not sure). The latter is an efficiency issue:
getting good numerical efficiency out of lisp is basically a question of
getting the numbers unboxed. This is somehting that make a difference of an
order of magnitude for small things, and somethimes a difference of an
order of severa magnituded (due to memory spend on number consing).

> For usage of specialized utilites, read in "On lisp", there is a good
> point.

It's too specialized for my taste. It shortens the code in two simple
modules, but does not empower me in other things. The point also made by
graham in On Lisp and his other books is to watch out for gratuitious use
of macroes.

Code becomed good "by letting it spring to it's natural shape", and the
natural shape for vector math is what?

>Pattern projection, along with texture matrix is obviously nescessary

But what do you mean by it? Please, I have trouble understanding you.
Imagine I know nothing at all about graphics and you need to explain to me
what pattern projection is.

Cheers,

 -- Nikodemus