Re: System specific coding by (excessive?) use of *features*

Edi Weitz <[email protected]> Mon, 18 Apr 2005 13:53:45 +0200
Newsgroups gmane.lisp.plob.general
Message-ID <[email protected]>
Moin!

On Mon, 18 Apr 2005 10:06:10 +0200, Heiko Kirschke <[email protected]> wrote:

> when working on Plob's new version 2.11, I observe that I'm using a
> lot of constructs like:
>
> #-(or :lispworks4 :allegro-v7.0)
> <do something>
> #+(or :lispworks4 :allegro-v7.0)
> <do something else>
>
> I'm not very satisfied with this, since the #- and #+ expressions do
> not express what I want (and, BTW, the code tends to become rather
> ugly by using that construct). My goal is that I want small code
> changes which adapt Plob's code to the different Lisp versions which
> might be in use.  These small changes have the nature that it does
> not make sense to introduce a new API for them (hiding the system
> specific implementation details) or it is even not possible to make
> an API for that (e.g., system specific (declare ...)
> statements). So I often face the problem that I want something like
> ,,use this piece of code for that Lisp system version x and probably
> later''.  In Allegro, there is the #+(version>= <number>) construct
> which is quite handy, but it is not available for LispWorks, so this
> makes it difficult for using it at all in Plob's code. Is there some
> other portable construct which might solve this problem? Or is there
> maybe some other approach on multi-system Lisp code that I'm not
> aware of?

If the system tends to get complicated I try to factor out what I'm
actually interested in into features which are added at compilation
time.  For example, TBNL has certain code parts which are
conditionalized like

  #+:tbnl-bivalent-streams
  <do something>
  #-:tbnl-bivalent-streams
  <do something else>

while the feature :TBNL-BIVALENT-STREAMS itself is pushed onto
*FEATURES* (or not) at one specific place.

You can, although I haven't done that yet, actually test for the
presence of a specific symbol or a specific ability of the Lisp
implementation instead of relying on tests like #+:LISPWORKS4.4 -
Christophe Rhodes has written a good paper about this:

  <http://www-jcsu.jesus.cam.ac.uk/~csr21/papers/features.pdf>

All this doesn't really address the #+(VERSION>= <number>) question
but, anyway, this is something you can only rely on if your vendor
guarantees perpetual backwards compatibility.

Cheers,
Edi.


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click