Re: Using "internal" macros of a CL implementation

In a non-portable way: Check in what packages they are defined, and
access the right symbols in those packages. 'apropos helps to
determine the package. Access to a symbol in a package is made by
package:symbol, or package::symbol if it is not exported (but then
it's also really not advisable to use it). There are more ways to
access symbols in other packages via defpackage.

In a portable way: Create your own package with a low-level API. Make
sure that the API is close to at least one or ore existing low-level
APIs. Then you can provide different implementations depending on each
implementation, and in some implementations simply make the existing
one available through your own package. There exist numerous
compatibility layers that do it like this, like ACL-Compat, LW-Compat,
trivial-garbage, Closer to MOP, and various others. (For example,
CLiki has a page for such compatibility layers.)

Thanks, Pascal; that's exactly what I was asking for, though I
probably wasn't very clear.

I am impressed to see a large number of very skilled persons (Bill,
Ken, Pascal & Pascal - to name just a few) in this group who spend
*significant* amount of their times explaining in great detail
different aspect of the language, often answering similar questions again
and again. I still fail to see why this group is sometimes considered to be
"hostile" to the newcomers.

Best regards,
Victor.
.

Relevant Pages

  • Re: hierarchy of interface/implementations.
    ... public interface MyInterface ... and I want to have several different implementations defined for it, ... package mycom.MyInterface; ... Two-level domain, e.g., lewscanon.com, for a product known as "Killer ...
    (comp.lang.java.programmer)
  • Re: hierarchy of interface/implementations.
    ... I think you mean interface. ... and I want to have several different implementations defined for it, ... You appear to be mixing up the package and class names. ...
    (comp.lang.java.programmer)
  • Re: symbol locking
    ... Rahul> Some implementations provide this capability, ... Thomas> CLISP, ACL, and CMUCL all have package locks. ... The OP is asking for two features, ...
    (comp.lang.lisp)
  • Re: use-package & name conflict: why they are not deferred?
    ... Some low-level changes are required which go beyond flexibility ... Common Lisp comes with a lot of flexibility built in. ... The implementations may provide even more flexibility. ... The package system does not have this flexibility. ...
    (comp.lang.lisp)
  • Re: Disadvantages of Dependency Inversion?
    ... It depends on how many implementations and how many clients ... If there is a single client but multiple ... If the interface is packaged with the trade matching system, ... to the trade matching package. ...
    (comp.object)