[r6rs-discuss] Proposed features for small Scheme, part 9: modules
alaric at snell-pym.org.uk
Wed Oct 14 10:33:44 EDT 2009
On 14 Oct 2009, at 3:01 pm, John Cowan wrote:
> Alaric Snell-Pym scripsit:
>>> Hopefully the Posix example makes things clearer. It's not
>>> whether an
>>> OpenGL module is available (it always is) but whether OpenGL
>>> itself is
>>> available, a notion outside the Scheme system.
>> An OpenGL module *is always available*? What other modules is WG1
>> scheme going to mandate as always available?!?
> Not at all. I'm saying that *you*, the developer, can have an OpenGL
> module that is present on the user's system whether or not OpenGL
> is present, and works (for sufficiently small values of "works") both
> with and without OpenGL.
I see two problems with that.
1) You're saying that the only way one can do conditional imports is
to have a swap-in module that provides exactly the same bindings as
the one that might not be present, to act in place of it; but what if
that's not what I want? If I want to support OpenGL, DirectX, or
Phigs, do I need 'software implementation' replacements for all three
graphics APIs? Or do I provide software replacements that just signal
a not-implemented condition, and have a run-time check that tries each
in turn until one succeeds, or continues to a software implementation
if none do?
2) I still don't see how you're supposed to tell the implementation
"This is my software implementation of opengl, if there isn't an
opengl module already installed for me to use", in order to actually
select this software implementation of opengl. Do I have to put it on
some kind of search path, after system-wide installed modules, so any
existing opengl module gets found first?
But either way, this sounds like a terribly complex way of going about
it. And I sitll think we're talking at cross purposes. No matter how I
try and explain the problem, you seem to keep suggesting solutions to
different problems... I think you're asking how I'd write a module
that *provides* OpenGL access by wrapping a C FFI, falling back to a
software implementation of OpenGL; that's not it at all!
Why can't we just have my *portable* graph-drawing library do
something like this:
(define (draw-image (graph)
....draw graph with opengl and return pixmap...)
...draw graph with directx and return pixmap...)
...draw graph with phigs and return pixmap...)
...make a pixmap and hand-draw the graph into it...)))
Sure, if we're not allowed imports in such nested scopes we need to
mess it up a little by putting the entire (define (draw-image
(graph) ... ) inside the cond-expand on each arm, but you get the idea.
More information about the r6rs-discuss