trying to avoid tons of #+

"Hoehle, Joerg-Cyril" <[email protected]> Thu, 19 Dec 2002 10:09:10 +0100
Newsgroups gmane.lisp.uffi.general
Message-ID <[email protected]>
Hi,

Marcoxa [Marco Antoniotti?] wrote:
>(defun (setf window-title) (handle title)
>  (with-foreign-string (fstring element-count byte-count
>       :encoding #+clisp #<clisp encoding, e.g. UTF-16>
>	           #+lispworks #<lispworks encoding>
>                 ...
>                 #-(or ....) nil
>Seems to me to defeat the purpose.

My idea was more along
:encoding +the-application's-or-library's-required-encoding+

BTW, how do you use uffi:def-function?
(def-function foo
  #+(or Liwpworks CLISP) (:module #+(and lispworks pc) "zlib.dll" #+(and lispworks unix) "zlib.so" #+(and clisp unix (not cygwin)) "zlib.so" #+(and clisp pc (not cygwin)) "zlib.dll" #+(and clisp cygwin) "cygz.so-or-such")
  ; Allegro, CMUCL and others don't require a :module, so people from there don't put it in
  :returning xyz)

I was told that lispworks needs the :module keyword. CLISP would, too, for dynamic libraries (future), but not for modules (present).

My plan, similarly, was for CLISP:
(def-[lib]-call-out foo
  (:module/library *zlib-module*)
  (:return-type xyz))
where the form behind :module would be evaluated. At first, it could be a foreign library object or pointer (typically hold in a variable), later it could be a string (given aliasing support).
If it would start with a string (like "zlib" for Lispworks modules), most users wouldn't even notice it gets evaluated, which is an advantage (for extensibility).

Regards,
	Jorg Hohle.