[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gcl-devel] Re: on incf

From: Paul F. Dietz
Subject: Re: [Gcl-devel] Re: on incf
Date: Sat, 02 Jul 2005 11:57:32 -0500
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050511

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

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]