On Tue, 2009-10-13 at 21:24 -0400, John Cowan wrote:
> I'm doing a bad job of explaining. The idea is not that there are
> Good-Module and Fallback-Module, but that there is a single module with
> good and fallback implementations, and you use expand-time conditionals
> to decide which you can use. The idea is that an application needs
> whatever Scheme API it needs, but it can choose which implementation of
> that API to use based on external circumstances.
>
> Here's another example: A Posix module exports some list of identifiers.
> There might be three implementations: one for actual Posix systems, one
> for Windows systems with some of the function stubbed out, and one for
> embedded systems with everything stubbed out. There's only a single module
> file, but based on the presence or absence of "on-posix" and "on-windows"
> cond-expand flags, it can decide which implementation to incorporate
> using INCLUDE.
So your recommendation is that in the application that uses
the functionality do something like
(import "posix") ;; best effort at posix compliance
(import "dblibrary") ;; which we utterly won't need if posix
;; isn't the stub implementation
(import "fileio") ;; which we will need only if posix is the
;; windows version or the stub version.
(cond-expand ;; depending on which posix impl we got
((on-posix)
(begin
.... implementation using posix primitives to,
eg, communicate with a database ....
))
((on-windows)
(begin
.... implementation using the windows-faked version
of posix for some things but dropping database
transactions to a file where some other system will
reap them and process them out-of-band ....
))
(else
(begin
.... posix functions are all stubs, there is no
external database, so do all the database
stuff yourself instead of using them ....
))
and then inside the scheme source that defines module "posix" we
have
(cond-expand
;; interfaces with a real posix implementation
((on-posix) (include "posix.native.scm"))
;; with some stuff faked and some stubbed out
((on-windows) (include "posix.windows.scm"))
;; for toasters and thermostats
(else (include "posix.stubs.scm")))
My problem with this plan is that I can't express that I
*DON'T NEED* the other two modules if I can get full POSIX.
Why should I make the system occupy space and time importing
stuff it will never use?
Also, the multiple use of cond-expand here seems terribly
redundant to me.
Bear
_______________________________________________
r6rs-discuss mailing list
[email protected]
http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
