Re: [Gcl-devel] Re: on incf

[Paul F. Dietz]

Camm Maguire wrote:

> Its mostly intended to scratch the itch I always feel having to
> remember to add :test 'eq to the end of member for a simple symbol
> lookup, etc.  Hopefully others have the same itch.  GCL even had its
> own si::memq hack to the same effect.  Without this of course one has
> the eql function call inside the loop. 

If you disassemble compiled functions under Allegro, you'll see
that they sometimes do type-based substitutions of faster forms
of MEMBER, ASSOC, etc.  REMOVE(-IF,-IF-NOT) ... :COUNT 1 is also a good
target for optimization.

Optimizing EQL and EQUAL ==> EQ by themselves based on type information
is also useful; do we already do that?

Duane Rettig at Franz had a presentation at ILC 2005 on the first-class
environments they've added.  This or something close to it would be
a good candidate for standardization, I think.  It's relevant to this
thread because it lets you get some type declaration information at macro
(or compiler macro) expansion time, so users can add this kind of
type-based optimization.  You can also do some limited type propagation,
although not as much as can be done after macro expansion.

(I'd like to see an extension to Lisp where some parts of the behavior
of macros can be specified separately from their expansions, just to
get around this problem.)

> Personally I can't ever seem to bring myself to the loop macro, though
> it works in GCL just fine -- programming and English are to me two
> very different things, making loop code actually less readable, IMHO.

I've used LOOP for years, but then I was raised on Interlisp.
De gustibus non est disputandum.


> > On the other hand, in a FIXNUM vs. BIGNUM situation, things are radically
> > different and harder.  It may be that most FIXNUM declarations are simply
> > lies! 

There are at least two ways to address this: (1) have the compiler recognize
situations where the declarations are wrong, and blow up, and (2) in safe code,
treat declarations as asserts and check them at run time.  SBCL takes these
approaches, IIRC.

It also helps to run the code on different implementations.  Of course
testing cannot prove the absence of errors.

My feeling on FIXNUM is that it should *never* be used in declarations, since
you don't know what type it is (except that it's an integer supertype
of (SIGNED-BYTE 16).)  User code should use explicit integer range types.

        Paul