Hello from a Lisp neophyte:
I'm wondering if generic functions or some other means can make
writing code for multiple implementations more definitional.
The whole approach to multiple implementations is somewhat odd.
Usually, Lisp is about using macros to rewrite forms at compile time.
But then there is this #+ and #- business to do the same thing.
On Feb 7, 4:38 pm, "metaperl.com" <········@gmail.com> wrote:
> I'm wondering if generic functions or some other means can make
> writing code for multiple implementations more definitional.
I'm not sure what you mean by that.
> The whole approach to multiple implementations is somewhat odd.
Not really, unless you consider old CPP's #ifdef the same.
> Usually, Lisp is about using macros to rewrite forms at compile time.
> But then there is this #+ and #- business to do the same thing.
Those two *are* macros, so-called read macros.
See, for example, http://www.bookshelf.jp/texi/onlisp/onlisp_18.html
or the spec at http://www.lisp.org/HyperSpec/Body/sec_2-4.html
They are evaluated at read time.
Leslie
From: Thomas A. Russ
Subject: Re: programmatic handling of multiple implementations
Date:
Message-ID: <ymibq6s1t6e.fsf@blackcat.isi.edu>
"metaperl.com" <········@gmail.com> writes:
> Usually, Lisp is about using macros to rewrite forms at compile time.
> But then there is this #+ and #- business to do the same thing.
Well, it isn't quite the same thing, and sometimes the differences
happen to be crucial.
Macros rewrite forms at macro-expansion time, which occurs during
compilation or evaluation. The #+ and #- forms affect what is seen at
read time, long before a macro would even get to see the forms.
It is sometimes important to be able to handle conditionalization at
read time, because that allows one to shield certain forms from even
being seen by other implementations. This can be important when the
conditional code refers to packages that are present in one
implementation and not another. Trying to read a symbol in a
non-existent package will cause the reader to signal an error.
So this isn't something that a macro can take care of, because just
attempting to read the code will cause the error, well before the macro
gets control of the situation.
--
Thomas A. Russ, USC/Information Sciences Institute
"metaperl.com" <········@gmail.com> writes:
> Hello from a Lisp neophyte:
>
> I'm wondering if generic functions or some other means can make
> writing code for multiple implementations more definitional.
In a way.
What are you thinking of exactly?
Generic functions dispatching on the implementation would not be
needed in general, when you don't need to handle different
implementations at the same (run) time. Things like:
(defgeneric some-interface (target)
(:method ((target (eql :clisp)))
(do-something clisp-specific))
(:method ((target (eql :sbcl)))
(do-something sbcl-specific))
...)
There's no need to load the code of the other implementations in the
current one.
> The whole approach to multiple implementations is somewhat odd.
> Usually, Lisp is about using macros to rewrite forms at compile time.
That's what cffi does, mostly.
> But then there is this #+ and #- business to do the same thing.
That's what clocc does, for example (see gc, quit, ... in
http://clocc.cvs.sourceforge.net/*checkout*/clocc/clocc/src/port/ext.lisp
). I don't like abusing #+ and #- like this, but when you have just an
occasional function that has specific forms, it's an easy way to do
it.
And you forget the normal way to handle it, that is to define an
interface, and various implementations (in different files) for the
various targets. This is the cleanest way IMO, you just load the
right file for your implementation. Some portability layers like
closer-mop or swank (in slime) do that. Of course, in this case, you
can use #+ to select which file to load (like closer-mop.asd does), or
select the right file to load from (lisp-implementation-type).
Of course, the definition of an interface can be done thru the
definition of generic functions, and the implementations thru the
definition of specific methods for these generic function. But you
could as well "specify" a normal function, and give different
implementations of it in the different implementation specific files.
--
__Pascal Bourguignon__
On Feb 7, 5:07 pm, ····@anevia.com (Pascal J. Bourguignon) wrote:
> "metaperl.com" <········@gmail.com> writes:
> > Hello from a Lisp neophyte:
>
> > I'm wondering if generic functions or some other means can make
> > writing code for multiple implementations more definitional.
>
> In a way.
>
> What are you thinking of exactly?
>
> Generic functions dispatching on the implementation would not be
> needed in general, when you don't need to handle different
> implementations at the same (run) time. Things like:
> (defgeneric some-interface (target)
> (:method ((target (eql :clisp)))
> (do-something clisp-specific))
> (:method ((target (eql :sbcl)))
> (do-something sbcl-specific))
> ...)
> There's no need to load the code of the other implementations in the
> current one.
>
That is what I use with my CL-ENVIRONMENT package (which is available
in the CLOCC as well). However, I have a better version on my laptop
at this point.
Cheers
--
Marco