>>>>> "David" == David Rush <xxxxxx@bellsouth.net> writes:

David> xxxxxx@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes:
>> >>>>> "David" == David Rush <xxxxxx@bellsouth.net> writes:
David> I just don't see how forcing them all to use a single name in 'exec'
David> space will help anything.

David> And I still don't. Say I've already installed Scsh 0.6, which comes
David> with the brand new SRFI-22 support and poerted my GWZ application to
David> take advantage of the SRFI-22 compliant installation
David> capabilities. I've wrapped eveything up in cond-expands, and I'm
David> pretty confident that it's "portable".

David> Joe Bloggs now D/Ls GWZ and installs it on his SRFI-22 system, which
David> is Gambit. How likely is it to work? Well, if I have *really* done my
David> homework, maybe pretty good. A more likely scenario is that I haven't
David> actually run it under Gambit because there are too many
David> implementations to have covered all of them in my testing. Whoops!
David> there is an incompatibility.  So I have to go and put the Scheme
David> implementation specific stuff back into my configure.in, and I have
David> gained nothing out of the SRFI-22 exercise except the standard
David> parameter passing.

I got your point.  However, as long as the feature sets supported by
scsh and Gambit are as divergent as they are now, there's nothing I
can think of which will solve the problem.  Neither will autoconf:
it'll just give up on GWZ if the Scheme implementation at hand won't
provide what you need.

On the other hand, I conjecture SRFI 7 *does* provide you with the
ability to do what you might otherwise do with autoconf.

David> none of R5RS, SRFI-0, or SRFI-7 provides
David> enough functionality to do significant scripting.
>>
>> I disagree with that from practical experience.

David> To be fair, you *can* write highly portable code with just SRFI-0, I
David> can't speak to SRFI-7, I don't use it and I haven't seen
David> widespread support for it

SRFI 7 does much better with this since it doesn't require
implementations to preload all the functionality conceivable required
by an autoconf script.

I do agree that it's not easy to choose a single Scheme implementation
for, say, scm-srfi-7, as long as there isn't a total order among the
SRFI sets supported by implementations.  But, once again, I don't
think there's anything you can do about that.  I do hope that we'll
eventually have Scheme implementations which support reasonably large
numbers of SRFIs, and that will improve the situation considerably.

Much the same problem exists with other languages with multiple
implementations and feature sets which vary among them.

--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla