From: Marco Baringer
Subject: writing compatability layers
Date:
Message-ID: <m2y98a45mu.fsf@bese.it>
while maintaing a program which should run on clisp, cmucl and mcl i
went looking for a "compatability layer definition system," and found
none. i was looking for a way to seperate the requirements of the
compatability layer (ie what implementation specific functionality i
needed) from the multiple implementations providing the functionality.
my main gripes with the conditional read macros (#+ and #-) are: 1)
they usually end up spread all over the code, making it hard to find
them and therefore hard to add new implementations. 2) it's very
difficult to understand what is needed since you only see how it is
provided. 3) bolean compbinations of *features* is not always enough
to determine if a piece of code should be read or not.
i realize that something like this may very well exist and i've just
missed it, if that is the case i'd appreciate any pointers. i also
realize that this may simply be a non-problem for most people, or at
least not enough of a problem to merit the time/effort required for a
cleaner solution, in which case forget i ever brought it up.
thanks,
--
-Marco
Ring the bells that still can ring.
Forget your perfect offering.
There is a crack in everything.
That's how the light gets in.
-Leonard Cohen
Marco Baringer <····@bese.it> writes:
> while maintaing a program which should run on clisp, cmucl and mcl i
> went looking for a "compatability layer definition system," and found
> none. i was looking for a way to seperate the requirements of the
> compatability layer (ie what implementation specific functionality i
> needed) from the multiple implementations providing the functionality.
>
> my main gripes with the conditional read macros (#+ and #-) are: 1)
> they usually end up spread all over the code, making it hard to find
> them and therefore hard to add new implementations. 2) it's very
> difficult to understand what is needed since you only see how it is
> provided. 3) bolean compbinations of *features* is not always enough
> to determine if a piece of code should be read or not.
>
> i realize that something like this may very well exist and i've just
> missed it, if that is the case i'd appreciate any pointers. i also
> realize that this may simply be a non-problem for most people, or at
> least not enough of a problem to merit the time/effort required for a
> cleaner solution, in which case forget i ever brought it up.
The PORT part of CLOCC seems to be similar to what you're looking for:
<http://clocc.sourceforge.net/dist/port.html>
Edi.
Edi Weitz <···@agharta.de> writes:
> The PORT part of CLOCC seems to be similar to what you're looking for:
i know about, and have used both PORT and acl-compat[1]. while those
are both usefull libraries they are not helpful when i have my own
application with its own implementation specific parts. What the
library provides (symbols/functions/macros/constants/etc.) should be
seperated from the code which provides it and it should be possibile
to specify which implementation to use based on more than just the
elements of *features*.
here's what i'd like to be able to do:
1) in one place specify what functions, methods, constants and macros
a certain library must provide, default implementations can be
provided as well as documentation.
2) in another place specify the code required to implement the library
for implementations meeting certain conditions (es: (and (member
:clisp *features*) (> 2.28 (read-from-string
(lisp-implementation-version))))).
3) ensure, as much as possibile, that the system specific
implementation in (2) meets the requirements specified in (1). this
would, for example, make sure the proper symbols are fbound or
bound in the right packages, ensure that function and method args
are compatabile, and whatever else is "reasonably" doable.
i currently have the beginnings of such a system, i was hoping someone
else had alreay done it better, but maybe not. if i finish what i have
i'll publish it and see what happens.
[1] - many thanks to the authors of both PORT and acl-compat, the code
has proven very useful. i want it to be clear that i have nothing
against with these libraries, i just want to implement things
differently in my own code.
--
-Marco
Ring the bells that still can ring.
Forget your perfect offering.
There is a crack in everything.
That's how the light gets in.
-Leonard Cohen
Marco Baringer <····@bese.it> writes:
> while maintaing a program which should run on clisp, cmucl and mcl i
> went looking for a "compatability layer definition system," and found
> none. i was looking for a way to seperate the requirements of the
> compatability layer (ie what implementation specific functionality i
> needed) from the multiple implementations providing the functionality.
>
> my main gripes with the conditional read macros (#+ and #-) are: 1)
> they usually end up spread all over the code, making it hard to find
> them and therefore hard to add new implementations. 2) it's very
> difficult to understand what is needed since you only see how it is
> provided. 3) bolean compbinations of *features* is not always enough
> to determine if a piece of code should be read or not.
>
> i realize that something like this may very well exist and i've just
> missed it, if that is the case i'd appreciate any pointers. i also
> realize that this may simply be a non-problem for most people, or at
> least not enough of a problem to merit the time/effort required for a
> cleaner solution, in which case forget i ever brought it up.
If you check out CL-ENVIRONMENT in the CLOCC you will see that it does
provide you with some machinery to avoid the proliferation of #+ and
#- condizionalizations.
Essentially CL-ENVIRONMENT will give you an "objectified" version of
LISP-IMPLEMENTATION-TYPE, MACHINE-TYPE and friends.
With that you can write things like
(defgeneric my-truly-impl-dependent-fun (os-type list-type ...))
and relegate the actual implementation of such things in a separate
file (usually in a `impl-dependent/<lisp instance>' subdirectory.
E.g. in file "impl-dependent/mycl.lisp"
(defmethod my-truly-impl-dependent-fun ((os cl.env:linux)
(os cl.env:mycl))
...)
(defmethod my-truly-impl-dependent-fun ((os cl.env:mswindows)
(os cl.env:mycl))
...)
This allows you to write your DEFSYSTEMs as
(mk:defsystem "FOO"
:components ("definitions"
(:module "impl-dependent"
:components (#+cmu "cmucl"
#+clisp "clisp"
#+ecl "ecl"
...))))
thus concentrating all the reader conditionals in the defsystem form.
Sometimes the above form is an overkill, but IMHO it simplifies your
life in the long run.
Cheers
PS. In MK4 and in ASDF you can say things like
(:file "mycl" :if-feature :cmu)
which will make defsystem forms look better.
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
715 Broadway 10th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
On 04 Nov 2002 00:04:25 +0100, Marco Baringer <····@bese.it> wrote:
> while maintaing a program which should run on clisp, cmucl and mcl i
> went looking for a "compatability layer definition system," and found
> none. i was looking for a way to seperate the requirements of the
> compatability layer (ie what implementation specific functionality i
> needed) from the multiple implementations providing the functionality.
I think this is what Marco Antoniotti's CL-CONFIGURATION is supposed to do.
It's maintained as part of CLOCC:
http://clocc.sourceforge.net
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://www.paoloamoroso.it/ency/README
On Thu, 07 Nov 2002 10:39:25 +0100, Paolo Amoroso <·······@mclink.it>
wrote:
> I think this is what Marco Antoniotti's CL-CONFIGURATION is supposed to do.
> It's maintained as part of CLOCC:
>
> http://clocc.sourceforge.net
Ooops... I meant CL-ENVIRONMENT.
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://www.paoloamoroso.it/ency/README